This is a practical problem for customers of GnuPG VS-Desktop, where the compliance mode is globally configured.
gpg should not bail out here but verify the signature and print a notice. For script compatibility an extra option might be useful.
This is a practical problem for customers of GnuPG VS-Desktop, where the compliance mode is globally configured.
gpg should not bail out here but verify the signature and print a notice. For script compatibility an extra option might be useful.
rG GnuPG | |||
rGaecebdf7050c gpg: Replace --override-compliance-check by a real fix. | |||
rGd98bf02a0363 gpg: Replace --override-compliance-check by a real fix. | |||
rG773b8fbbe915 gpg: New option --override-compliance-check | |||
rGfb26e144adfd gpg: New option --override-compliance-check |
Wouldn't it be safer to use gpgv for verifying the signature than to add a code path to gpg to circumvent the hard de-vs compliance check?
Yes, but it is more complicated to do because you need to download a binary version of the keys and check that they are authentic. Most users don't known it. Anyway, I meanwhile created a Brainpool release sign key and new VSD releases are signed with that. The override option does not really harm, but we can close this bug due to the new release key.
The introduction of --override-compliance-check actually hid the real
cause for the signature verification problem in de-vs mode for the
Ed25519 key. The real fix is to handle the EdDSA algorithm in
gnupg_pk_is_allowed.
Fixed for 2.2.42 and 2.4.1.