Running with -v would really be helpful.

Maybe not on Linux but the environment is visible from other processes in the same way as the command line. So I don't see why we should add yet more clumsy passphrase workarounds to gpg. We already have PINENTRY_USER_DATA which can fulfill the same task.

Last week:

• Administrative work
• Fixed some regression in gpgme's "make check"
• Simplified libgpg-error header generation
• gpgme-json work

Please see my comment on T4152.

Please check again with a recent upstream release or report to Debian. The release from Debian is pretty old and has a couple of non-standard patches.

Andre explained that we don't do that anymore on purpose. Duck and read the discussion related to this if you are intereested. A related thing is that no-grab does not work on all platforms because it was designed for standard X but nowdays toolkits have their own ideas what is right and what is wrong.

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

pinentry-qt giving Gtk- warnings? Very strange. Please give an example. You can start pinentry on the command line like

if you start gpg-agent in that deprecated way it sees the envvars. it will even see them if it is as suggested started on-demand by gpg. However, things are different when a gpg-agent is already running; in that case only the listed envvars are conveyed to the pinentry.

We need a way to replicate your problem, a few questions first:

I would call that a feature because it makes sure that the Pinentry always shows up the same regardless of an application selects a different theme.

The background of my earlier comment was that I didn't tested GPGME in this regard.

Okay. So for GPGME should we add --no-keyring if --override-session-key is also enabled? I think this would be better than relying on the fact that gpgme ignores the returned error code.

@dkg does --no-keyring solves the problem for you?

We assume that this has meanwhile been fixed.

Well, the counterpart in gpg-agent is missing.

Actually it fails only when you set TERM to the empty string. Unsetting TERM still works:

Another address does not help as long as we are forced to use a Google account. That is not subject to discussion. sorry.

You may indeed post to gnupg-devel if that helps to raise the attention of the Travis folks. If they need support we would be glad to help.

This has always been the case and the worst thing which can happen is that (64 bit keyid clash) you might not be abale to import the "real" key. Keyserver's never promised to deliver the correct (in whatever sense) key, but are merely an anonymous and distributed stoarage systenms. This is why gpg does not trust a key by default but requires you to validate the key by other means (WoT, second channel, Web Key Directory).

Last week:

• Adminstrative work
• VS-NfD vendor meeting in Bonn
• Minor code work

@catenacyber thanks fo this bug report.

Thanks for your comments, Stephan.

Which is the correct way to handle this. We merely gave the MDC packet a standard packet structure so to help with debugging. Decryption needs to defer the 22 bytes to be able to detect the MDC packet.

Release done with these major news:

• gpg: Refresh expired keys originating from the WKD. [T2917]
• gpg: Use a 256 KiB limit for a WKD imported key.
• gpg: New option --known-notation. [T4060]
• scd: Add support for the Trustica Cryptoucan reader.
• agent: Speed up starting during on-demand launching. [T3490]
• dirmngr: Validate SRV records in WKD queries.

There is no way for us to fix. It is a shell issue.

We won't fix that. If you want to build for Apple iOS make sure to use

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.

@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?

We won't do that. Those with badly encoded user ids should create new keys or meanwhile have done so. The whole charset back and forth encoding adds a lot of complexity for some legacy applications. Frankly I would like to get rid of all code conversions and stick to utf-8.

In T3464 is is described how you can do it. Sure, in your case you want to have a home directory so that the agent and pinentry can work. --no-keyring makes sure that a decryption with a private key can't happen. How we have the cache for symmetric encrypted data which you can disable with --no-symkey-cache.

--verify-files is mostly useful for scripting and and not for manual checking. With scripting etc you always need to use --status-fd and with that you get:

To use encryption and for both purposes: encryption and authentication.

I was already implementing a --no-homedir when I figured that we have --no-keyring. Using that with any homedir fulfills the requested purpose.

Will be in 2.2.10

Will be in 2.2.10

The question is now to model the API for this. For 0x02 it seems to be pretty clear: We assume it is a detached signature on a zero length file and make sure that no signed file is given.

This was actually reported against 2.0.31 which reached EOL 8 months ago.

Backport done for 2.2.10

AFAICS this is now implemented. We have the option --with-key-origin and even support in GPGME.

Done. To be released with 2.2.10.

FWIW, we record the origin of the keys. So you have the information. Use --with-key-origin in a key listing. GPGME also has the info.