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.

Last week:

• GnuPG 2.2 bug fixing

Last week:

trigger what command? i'm pretty sure it 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.

Last week (major decision for TTXS, and minor fixes for GnuPG):

• TTXS: decision to use libccidtwin.so for host deriver
• gpg:
  • Add a feature to allow same key on different cards (no matter SERIALNO in the stub): T2898: Option to ignore card serial number (to be able to use backup tokens containing same subkeys), T4301: Handling multiple subkeys on two SmartCards
  • Fix T4494: UBsan finding "armor.c:1159:11: runtime error: member access within null pointer...", T4504: Asan findings in iconv configure test causing config failure
• nPth:
  • Fix T4491: Compile error in nPth's t-fork.c on Solaris 11.3 i86pc
• libgpg-error
  • Fix T4498: Asan findings in tests/t-logging.c
• Chopstx: version 1.15 release

This week:

• TTXS: implement and build test environment for CCID on serial (GemPC Twin smart card reader protocol)
• (FYI) FST-01SZ shipment to Free Software Foundation, for its online shop.

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 used 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.