User Details
- User Since
- Mar 27 2017, 4:48 PM (485 w, 1 d)
- Roles
- Administrator
- Availability
- Busy Busy until Sep 9 2030.
Today
Restoring an encryption subkey is now easy if you have an sk_KEYID.gpg backup:
Please see the rGf103eaee63f702278824967365de16b9757ecc83 for detailed comment on the (solved) problem.
Yesterday
Mon, Jul 13
Here is how we use the passphrase error codes:
Fri, Jul 10
Thu, Jul 9
underscores usual I'd say. There is no semantic in the format of the file name.
Wouldn't it be an idea to use a short delay and a retry count limit?
Wed, Jul 8
A comment in gpgsm shows the problem:
Thu, Jul 2
Wed, Jul 1
Released with pinentry 1.3.3
GPGME was released mid-May this year and the gpg fix is also long released.
Tue, Jun 30
Noteworthy changes in version 2.1.2 (2026-06-30)
Mon, Jun 29
You are right. I forgot that for composite keys (i.e. Kyber) we already use a GnuPG specific export mode which does not need require that gpg-agent knows about *PGP formats. Thanks for bringing this up again.
Thu, Jun 25
I can't see any commits pertaining to gpg betweem 2.5.19 and .20 which could cause this. I would say, we need to bisect this but w/o a reliable reproducer this will take too long.
Wed, Jun 24
Tue, Jun 23
An OOB-Read in dirmngr is not very critical. dirmngr has no confidential data which can be leaked except maybe for an LDAP password in memory. Thus I lower the priority.
Mon, Jun 22
Thu, Jun 18
Wed, Jun 17
Jun 11 2026
Jun 10 2026
Jun 9 2026
Jun 8 2026
Noteworthy changes in Version 5.0.2 (2026-03-16)