[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1077599: marked as done (apt: use sopv for OpenPGP signature verification)

Your message dated Mon, 6 Jan 2025 18:41:09 +0100
with message-id <sbgcvdf6nkpsr5zat4jnpue7a5oo5rw5tcmafmwnmtoeyyubup@v4bbiog6ogpt>
and subject line Re: Bug#1077599: apt: use sopv for OpenPGP signature verification
has caused the Debian Bug report #1077599,
regarding apt: use sopv for OpenPGP signature verification
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1077599: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077599
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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


--- End Message ---
--- Begin Message --- 
Version: 2.9.19

For better or worse:

| apt (2.9.19) unstable; urgency=medium
[…]
|  * Replace GnuPG with Sequoia on supported Debian platforms
[…]
| -- Julian Andres Klode <jak@debian.org>  Mon, 23 Dec 2024 12:16:19 +0100

So this kinda implements the requested feature although certain
aspects are different and some aspects were "clearly" agreed to
disagree on (from the PoV of an fsvo 'onlooker')

Anyways, probably better to deal with any follow ups in dedicated
bug reports than to keep this catch-all open just because not all
i's have dots and all t's are properly crossed yet.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: