Package: gpgv-from-sq Version: 0.8.0-5 Control: affects -1 + apt Control: forwarded -1 + https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/68
As of 50e3fee26ae843a812b1c9ec8531946931773fd3, apt 2.7.13 started trying to use --assert-pubkey-algo, which appears to have been hastily added to GnuPG in 2.4.5 in response to https://dev.gnupg.org/T6946 (itself an outgrowth of https://bugs.debian.org/1042391) It strikes me that a better approach would have been to simply have GnuPG improve the default policy about what signatures are acceptable, and bring them into alignment with the upcoming requirements for the replacement of rfc 4880 (https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/). Anyway, the way that apt is testing for the presence of this option is quite brittle: it first tests whether the option is there or not, by trying to use it and inspecting the format of the string emitted on stderr. while gpgv-sq doesn't currently accept the option, its error messages aren't the same as g10code's implementation of gpgv. The result is that when gpgv-from-sq is installed, apt complains about each configured repository: Unknown response from gpgv to --assert-pubkey-algo check: gpgv: error: Error parsing command-line arguments" So one of three things should happen: - gpgv-sq could implement --assert-pubkey-algo, which afaict is fairly ill-defined. - gpgv-sq could adjust its error messages to match the regex that apt is using during its test. - apt should relax its test for --assert-pubkey-algo so that it is less brittle. Even better, apt could adopt the `sopv` interface, which has a more structured, simple, and formal definition, and then depend by default on a sopv implementation that is already known to support the reasonable policies described here. --dkg
signature.asc
Description: PGP signature
