Package: apt
Severity: wishlist
Hi Julian, all--
We had some discussion over on
https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/84
about how apt might use sopv instead of gpgv to validate OpenPGP
signatures. I thought i'd move the discussion to an apt-specific forum,
here in the BTS, since it's not really relevant for the chameleon.
Feel free to move it somewhere more appropriate if you prefer!
I had written over there:
> I think a reasonable way forward would be for apt to depend on the sopv
> interface (of which there are already several implementations available,
> more than just the sequoia one), and to not have apt try to second-guess
> the sopv implementation. sopv is defined such that it is a bug to accept
> a weak signature. You can see, for example, the interoperability test
> suite's review of acceptable RSA signature sizes, which tests against
> the guidance in the upcoming RFC.
>
> If by default apt wants to require a stricter sopv implementation it
> uses, it can just constrain the choice of sopv it selects (e.g. accept
> sqop or dkg-sop (no relation😛) or pgpainless-cli or gosop 3+ or rpgpie
> or gpgv-sq, but reject rnp-sop or sopgpy or gpgv; or, just pick one that
> has reasonable policy and acceptable licensing, and require it). And if
> some local admin wants a weaker algorithm policy because they're
> dependent on some legacy repository, they can point to a different sopv
> in the apt configuration.
>
> The only interface apt needs to worry about under this proposal is just
> using sopv, which is deliberately simple. And OpenPGP algorithm
> upgrades, cleartext signature framework decoding, wireformat revisions,
> expiration dates, subkey cross-signatures, etc, can all be handled by
> the OpenPGP implementation. Apt just needs to run:
>
> sopv inline-verify /usr/share/keyrings/repoA.pgp /usr/share/keyrings/repoB.pgp < InRelease
>
> and consume its output as the validated Release file.
>
> (if you want sopv to defend against repository rollback too, it's only
> marginally more complex to confirm that the new signature is older than
> the last signature)
>
> If you're interested in this approach, i'd be happy to make a concrete
> proposal for apt that would let it use some form of sopv, and you can
> just pick the sopv implementation you like. Let me know if that would be
> helpful.
Julian followed up with:
> What's missing from sopv are mechanisms for specifying crypto
> policies, such as allowed hashes, allowed crypto algorithms, and
> allowed key sizes. I'm not sure if there's stuff I'm missing.
>
> What we found out here is that verifying the key algorithm and size
> during signature verification is a bit annoying, they only work with
> errors.
>
> Imagine you have two keys, one weak and one strong. You never get a
> warning about the weak key until you see a signature from it.
>
> That's suboptimal because it means only errors really add security, as
> otherwise an attacker may replace the data with one signed with a
> compromised weak key and if an update runs in the background you might
> not even notice.
>
> We also need status communicated:
>
> fingerprints of keys that are unknown
> uids and fingerprints of expired keys such that we can display them
>
> etc pp.
I'm happy to respond to these thoughts in a later message in this
thread.
Regards,
--dkg
Attachment:
signature.asc
Description: PGP signature