T4298: 'make check' with uninstalled library, which is building now (even if rpath doesn't work well) handles related issue, which was fixed for libgcrypt-1.9. Since this issue is for other libraries (libgpg-error, specifically), we could do something similar, but, it may be detecting LD_LIBRARY_PATH to fail with "Please remove LD_LIBRARY_PATH".

It seems it's Ubuntu specific: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1796563

I think that all that we can do is to improve documentation.

yes. that's why i wrote it in '['-brackets.
but usually, in info-documents a synopsis is written about it.
I think that it's not self-evident, that "you can either give a file or let the tool read from stdin or output to stdout" and therefore should be written explicitly.

Could you say, on which platforms exactly it should work?

no-grab does only work on certain platforms. Thus this is no bug.

"partially" means it doesn't allow to input elsewhere, but in case of focus loose input will go nowhere

At least it MUST NOT grub input with no-grab option. But it doesn't allow to input elsewhere in any case.

We know that. And pinentry-gtk does like that.

It's possibe to do via gtk3 directly:
https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-device-grab-add

Yes. It's up to GCR library in GNOME.

@werner Given you filed it as low priority and documentation - could you give feedback on whether that is expected behaviour or not?

The “this” is used so that we don't have too many strings to translate.
I added a call to print_further_info which will in --verbose mode explain it.

Will be in 2.2.10

I need to know which of the processes segv: mkdefsinc, cat or the subshell. And a backtrace would also be very helpful.

We didn't found the time to organize it. There will be a OpenPGP summit this fall organized by Patrick, though

I wonder if there's potential for engaging users remotely? Also, in addition to a workshop, maybe a user interface study of how users learn and interact with the tool? I feel like doing that with people who are relatively light/new users of gpg (like me, currently struggling as I wade thru a mix of docs, some of it outdated) could be beneficial. See also: https://arxiv.org/abs/1510.08555

Hint from @gniibe: gpg --with-colons --list-config curve is a workaround.
So it still should be documented and made accessible from a non-esoteric, non-internal way. ;)

In T3751#110422, @cipherpunks wrote:

What's in daily use for 15 yrs? GPGME? I thought GPGME was new,

Thanks for the report. The broken sentence came from an unterminated hyperlink. I fixed the spelling and the link.

I changed the wording to suggest the use of proper transport security.

What's in daily use for 15 yrs? GPGME? I thought GPGME was new, but in any case it's broken in the cases mentioned in that thread.

Originally dirmngr was designed to be a system service for the reason that CRLs are not user specific. However, the majority of systems today are used by a single user and thus we dropped that feature when integrating dirmngr into gnupg.

Come on, it is in daily use for 15 years. MUA which can't handle MIME at all but PGP are still able to decrypt PGP/MIME. That is why ME specified PGP/MIME this way.

Thanks for noticing. I've changed it and clarified that GpgOL is for Windows only and not for the Outlook Web App / Android or Mac.

Ah well, no rules without exception.

We could signal an error. However, that would break existing behaviour and can only be done for 2.3.

Thanks. I added you to the wiki page.

thanks for the links to documents.
we've setup submisson-address and policy links.

oh ... I see thanks. I am thinking now about an analogy between the place where I live in real life and the unix home directory, (also called a login directory). Very interesting indeed ...

Did just that in master and 2.2.

article 13 states the inviolability of the home ;-)

I do like to read about historical facts, motivations, etc ... as far as I know 'g10' is related to artikel 10 grundgesetz...

OK, I changed my own purpose. I don't touch internal representations.

I'm fine with (and i totally understand) wanting nothing but UTC in the machine interface and internal representations.

[copied from gnupg-devel@]

I think any existing script that assumes UTC should add an explicit Z suffix. (that is, i don't think the breakage is a big deal, and anyone writing scripts that needs this kind of precision will be more likely be thankful that we have a sensible, normalized interface).

It is pretty much confusing. When a user specify in YYYY-MM-DD format with no hh:mm:ss, it is interpreted as local time (noon of that day).
When a user adding Thh:mm:ss, it is UTC.

While I confirmed that GnuPG interprets YYYY-MM-DDThh:mm:ss in UTC (which should be interpret as local time according to ISO-8601), I don't know how we can fix this.
If I change the interpretation of GnuPG (possibly supporting the format with Z suffix and timezone), it may break existing script which assumes UTC.

Bug confirmed in rGa766a37290cf: Print keyid in gpg --list-packets..

fwiw, i agree that GnuPG should interpret these as ISO-8601 strings. At the very least:

I guess for older releases it is less relevant to have very accurate version information. From now on this is more a regular maintenance task than a unit of work, so I am closing it.

Gave it a head-start.