Perl would be okay for maintainer mode but not for regular builds. The reason is that perl is already used by autotools but a build shall still be possible w/o perl.

I spent a lot of time trying to figure out how to automate the interface between my preferred password store (gnome-keyring, via libsecret), but with the loopback pinentry mode changes in gpg 2.1, it is much harder (if not impossible) to do. Having passphrase caching is the only thing preventing me from choosing a weaker passphrase on my gpg keyring.

Disallowing passphrase caching is likely to have the unintended consequence of users choosing weaker passphrases that are more easily memorized and/or typed. Caching should be permitted, IMO. This puts more decisions about passphrase management into the control of the user.

I'm looking into doing a pretty epic hack of using the switch_endian syscall to speed this up.

And yet, that interface is already being used by the agent-transfer utility in monkeysphere. The interface exists, it is not marked in any way as unusable or deprecated or off-limits, so it is used.

I don't know. That would make it a relatively easy transplant. We've also used the Cryptogams code as a reference for Golang enhancements, if that helps. I'd welcome guidance on the matter from a maintainer.

Would the maintainers accept having perl in the repository? Linux does it.[1]

Closing this as the moving problem was fixed.

That is on purpose. Exporting of a secret key should in theory not be possible at all via gpg. In practice we need a way to export a key, but that should be the exception and thus we do not want any caches for passphrases to have an effect.

trigger what command? i'm pretty sure gpgconf --reload gpg-agent does not trigger updatestartuptty. And it should not do so, afaict -- if you think it should, i'd be interested in hearing the rationale for it.

When having a backup media, I'd recommend completely different one (for example, on paper using paperkey to be stored in a locker in basement), which requires different method for recovering. Brains may be easily confused when same private key material exists in multiple similar devices.

Does gpgconf --reload gpg-agent trigger that command? that's the ExecReload setting in the systemd service unit I'm looking at.

Thanks for this @gniibe. I have long been frustrated by trying to save the correct "stubs" to have my keyring point at two different smartcards. It was common and even advocated in my former community to place one's master key on a separate smartcard (certify capability), with a different one designated for daily usage.

Thanks Gniibe San for explanation.

This doesn't sound systemd-specific to me, fwiw, though i don't understand how to reproduce the problem from the given description here.

FWIW, I disabled @aa7356 because he again started to troll.

Snap question regards to the clock;

Sorry, I can't parse that. For development question please use gnupg-devel at gnupg.org.

Fix will go into 2.2.16 to be release this month.

At the time the verification is done some output has already been written to the file 'signed'. When checking whether the deprecated abbreviated format

There will be no full solution for this. However, the next release should in general work due to a 400ms delay we use after spawning the viewer. This is configurable; see rG7e5847da0f3d715cb59d05adcd9107b460b6411b.

I guess you are the only person who does it. But yeah. I agree that it should be fixed.

I agree with @dkg here.

I can't see any bug here so I will close this bug now.

@blades: This feature will be available in GnuPG 2.3, which is planed to be released this year.
For Debian, Buster will come with GnuPG 2.2.12. After release of GnuPG 2.3, backport might be available (like GnuPG 2.2.x is available as backport for Stretch).

"requires too much changes" i can understand.

Hi Werner,

Please use one of the mailing lists to solve your problem. 2.3 is a development version, so I wonder from where you got this version of GnuPG.

Actually the temp file is created but because the photo viewer is run as a detached process and gpg keeps on running, the temp file has been removed by gpg at the time the photo viewer tries to open it. Ooops. The correct behaviour would be to wait for the photo viewer to be finished. We use

The problem could be narrowed as follows: According to Mailvelope Add-on, GnuPG must be installed for smart card support. Screenshots show that GnuPG is not recognized by Mailvelope. Of course actual versions off all programs were installed. Therefore, e-mails sent out ecrypted with public key work fine, because the public key is stored in Mailvelope. Is the encrypted message arrives and should be decrypted. Mailvelope does not find GnuPG and therefore, no private key. I´ll send some screenshots to you.