- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 4 2020
That is just one bit different - Shouldn't we better have a wrapper as we used to do for other things?
The inotify thing is only used to detect a deleted homedir and stop the agent. AFAIU your problem is that a migration is triggered again. The migration status is a file ~/.gnupg/.gpg-v21-migrated - are you sure that you have extracted it again?
Applying following SOS-handling, the key can be handled.
diff --git a/g10/parse-packet.c b/g10/parse-packet.c index 9cb254e24..be7fc6d67 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -188,6 +188,76 @@ mpi_read (iobuf_t inp, unsigned int *ret_nread, int secure) }
Note that there is no problem for encrypted key, because it is handled by opaque MPI.
Nov 3 2020
The whole TOFU stuff hash not yet been fully translated because there are conceptional problems with the way the code works.
FWIW, --enforce-passphrase-constraints does already work for symmetric-only encryption since 2.2.21 (rGae8b88c635424ef3). Thus this bug is actually a feature request to have a separate set of passphrase constraints option for symmetric-only mode.
Nov 2 2020
The next version will fix the wrong warning and also allow for an empty value.
No, overlapped I/O is not used. OVL is just a zeroed out memory area and thus hHandle is NULL. Errors are of course checked.
Note: menu_backsign can be enhanced to detect such a case in the same way it detects missing backsigs.
Setting to resolved as discussed with Werner
We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.
Nov 1 2020
Oct 30 2020
One bug is fixed in rGdd4fb1c8f668: gpg: Fix first zero-byte case for SOS handling..
Fixed in 2.2 branch.
Also, I found another issue of libgcrypt master, which is fixed in rC361a0588489c: ecc: Handle removed zeros at the beginning for Ed25519..
Further, I found different issue, and created T5116: GnuPG master shows an error when importing Ed25519 keys generated.
I think that it may occur with eddsa secret keys generated with 2.2, too. (In the 50% probability)
Oct 29 2020
Indeed we need to fix/enhance this to make testing of --quick-revoke-sig easier. See over at T5093
I recall that I had the same bug during development. Must have slipped in again - Good catch.
I have added support for this to gpgme (and gpgme++/qgpgme). See T5094.
By the way, --quick-sign-key after --quick-revoke-sig refuses to recertify the key. -> T4584
There is another problem: Even if the first certification was revoked, trying to add a new certification with --quick-sign-key fails because '"user id" was already signed by key ...'
I found a bug. To reproduce generate a new key, then sign it with another key and then try to quick-revoke the signatures. This fails with "Not signed by you."
I forgot that we have LOCK and UNLOCK commands in scdaemon. This was implemented around 2005 but there are no more users in gpg meanwhile.
On purpose. We actually allow user ids and gpg should somehow reflect this. As requested by you I changed it in the man page to what is suggested.
I've noticed an inconsistency between the command arguments in the man page and in the usage/error message.
In short eddsa secret keys generated with current 2.3 can't be imported with 2.2, right? That will lead to a compatibility problem, so we need to fix that in 2.2.
IIUC, it is an issue of GnuPG 2.2.
The condition is where the secret 'd' starts by the first bit = 1 (that is, >= 0x80).
I located the bug in agent/cvt-openpgp.c. The function do_unprotect calls convert_secret_key with skey[1] as usual MPI (not opaque),
and gcry_sexp_build with "(d%m)" will put additional 0x00 at the beginning, which results 33-byte secret in R_KEY. Then, when gcry_pk_testkey is called with R_KEY, when it checks, because 32-byte is expected, it returns GPG_ERR_INV_OBJ. Then, do_unprotect returns GPG_ERR_BAD_PASSPHRASE.
With Debian's GnuPG 2.2.12, I got an error:
With bata1449, I cannot reproduce it.
I can import by gpg --import key-uids-sec.pgp
I tested with Debian's libgcrypt, as well as libgcrypt master (4a50c6b8).
Oct 28 2020
The backend part is ready. Someone(tm) now needs to add it to gpgme. Extending the sign key API might be the best solution.
I was already considering this. I bet some people will view it as a bug if it is possible to add something other than a fingerprint. I'll change it in the man page.
Minor remark: I would change this (in the documentation) to
gpg --quick-revoke-sig fpr fpr-of-signing-key [names]
as for --quick-sign-key, --quick-add-key, and --quick-set-expire, even if USER IDs can be used instead of fingerprints. We shouldn't advertise the usage of USER IDs, if we prefer the users to use the fingerprints. I suggest to also change user-id to fpr in the documentation of --quick-add-uid and --quick-revoke-uid. Using USER IDs for identifying keys is ambiguous and errorprone (e.g. if non-ASCII characters get involved, which, incidentally, is the reason why I started to work on KMail).