I agree with everything in the previous comment. Just hoping for simple, robust UI like gpg 1.x that works over an SSH connection (no GUI) for ordinary file decryption on the command line.

@dkg I use gnupg 1.x for a very, very long time. I like the way it works. And most, I like that the terminal is not hidden from me when I type a password and that the characters in password does not appear on terminal as "*". Sometime the text in terminal is important to me. pinentry-tty have more or less the same behavior as gnupg 1.x. With pinentry-curses the terminal is hidden and there are '*' for each character in password that I type. Also, there is not GUI on my servers so no pinentry-(qt|gtk|anything else).

Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).

CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.

We will run into all kind of problems after 2038 on 32 bit boxes. 2106 is nothing to care about.

pinentry-tty is pretty fragile, and designed to be handled in a particular way. I strongly recommend a different workflow if you're using gpg secret key operations in a regular process. either:

@maiden_taiwan Thank you. Nice trick. Works fine for for one file and covers almost all of my issues.
Still, for example, when used together with rpmsign and I have to sign multiple rpms files, is inconvenient to type ctrl-D for each rpm file (for whatever reason I want to stop the signing process) . ctrl-c just stop the process.
This worked fine with gpg 1.x. Not so much with gpg2.

Thank you.

I uploaded the certificate files. For a test please do the following:

@gv: I am another user (not the developer), but here is a workaround I found. Type ctrl-D instead of ctrl-C to terminate pinentry-tty.

I'm sorry, this issue is far from fixed.

Regression due to a faulty backport. Fixed in repo; patch is F1052802
Thanks for reporting.

Okay, I can replicate that on gnupg 2.2; it works correct on master.

Sorry, a fix didn't made it into 2.2.18.

This is actually unused code and it will never be called with ERR == 0. Will fix it in master anway.

No bug.

The LDAP code is actually in very bad shape because @neal added it without utilizing the ldap wrapper and thus a timeout won't work reliable.

See T4760.

[ Please do not post each compiler warning as a single report. That is just just too much overhead and we do see such messages ourselves if you would provide a bit more information. ]

The manual states that --standard-resolver is mostly for debugging. The reason you get an "not enabled" is that we can't allow direct DNS queries in Tor mode which would happen with the system (standard) DNS resolver.

In T4726#130765, @werner wrote:

Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example).
[...]
To answer your question: With the exception of case two this is desired behaviour also in the future,

Please no bug reports for the development branch. You need to have a recent libgpg-error. We do not update the requirements checked by configure for master immediately. It is better to report this to gnupg-devel if you are sure that you have the latest versions of all libraries.

This will be in 2.2.18, closing.

In my own opinion, it will be good when desktop environments support GnuPG as one of first class citizens, to protect user's data.
For example, currently, libscret stores secret data (such as WiFi shared secret, etc.) by its own cipher preference and method (and it is symmetric cipher by user's password). I don't think it is secure enough.
For me, it will be good if it is protected by user's gpg key using asymmetric crypto.

UserIDs are mandatory and do not see any reason to change this except maybe by specialized application in the embedded field.

Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example). The risk of a regression in that case is pretty low.

it is just that we won't fix that for gpg 1.4.

Wow thanks for the great explanation! I've always wondered what is the relationship between gnupg and other secrets services. Personally, although Gnome's / KDE's secrets services offer better UX out of the box, I've always preferred gpg's agent because I can control it better from the command line and hence customize it's behavior. The only use I have for gnome-secrets service is for a few passwords I always want them to be cached (because I obtain them in systemd timers+services). Do you think Gnome / KDE will ever plan to _use_ gpg-agent, instead of reimplementing it?

Sorry in advance for long explanation. :-) Well, let me show my stand point at first (to avoid confusion): I don't like the concept of "desktop integration" when it makes difficult for a user to control his environment.

Works! I still wonder though: How come my system / gpg agent has all of a sudden started using the external cache? Is this a new feature of gpg-agent? And what is the meaning of this message:

Could you try to put no-allow-external-cache in your gpg-agent.conf?
If it changes the behavior, it is your desktop environment which caches your input, I suppose.

I thought I close this after the release of 2.2.18.
Anway, it's done, so, closing.

We use "error ..." and "failed to ..." interchangable. The German translation even uses the same term for both.
Thus I think it would be better to keep the old diagnostic but show it only in --verbose mode.

I did not want to move the fingerprint verification process more prominent with an entry field or something like that.

With the new version we get an even more extensive rework of the certify dialog. We now also have support for search tags.

It's probably a wrong encoding in the italian translation. Will be fixed with updating our build system to buster and NSIS-3

Is this resolved?

I tuned down the error message. I don't think there is a problem here anymore.

See also D475.

BTW, since I start my X session with startx, these are the relevant parts I have in my .xinitrc:

So my gpg-agent.conf file looks like this now:

Please add

In T4726#130609, @werner wrote:

-r  STRING

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup.

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup. This was implemented in this way to be as much as possible backward compatible.

DETAILS says:

*** PLAINTEXT_LENGTH <length>
    This indicates the length of the plaintext that is about to be
    written.  Note that if the plaintext packet has partial length
    encoding it is not possible to know the length ahead of time.  In
    that case, this status tag does not appear.

Sorry, we can't replicate this with the current pinentry version.

I always select both files and click to verify, I thought that was the way
it was supposed to be done, that I should provide the file and the
signature to the program.

Just downloaded the file and signature and there is only one signature. Just verifying the signature also does not result in duplicated results.

"PLAINTEXT 75 ..." means UTF-8 encoding (u) which is not not binary (b) or MIME ('m') and thus on Unix the line endings are converted from CR,LF to LF. On Windows you should see a different length. See plaintext.c#handle_plaintext()

Thanks for the report. I'm only giving it low priority because while it is ugly it is no loss of functionality.

Thanks for the report. I fixed this for the next 2.2 release and put a not in the source file to not translate the keyword.