Acknowledgement sent
to Simon Josefsson <[email protected]>:
New Bug report received and forwarded. Copy sent to APT Development Team <[email protected]>.
(Fri, 26 Jan 2024 10:42:04 GMT) (full text, mbox, link).
Package: apt
Severity: wishlist
I believe it would be nice if apt could verify signatures from Sigstore
cosign and/or verify Sigsum proofs, to augment the current PGP-based
signature verification.
While this can be handled outside of apt's awareness, it would also be
possible for apt to support improved signature verification in-band.
I'm interested in exploring any approach that leads to improved
signature verification offering similar functionality as
Sigstore/Sigsum, and offer to help work on this.
To get the design process started on the in-band approach: one proposal
is to extend the InRelease and Release.gpg file formats with additional
information needed for Sigstore and Sigsum.
After the PGP signature in InRelease and Release.gpg, you could include
additional sections. For Sigstore cosign:
-----BEGIN SIGSTORE COSIGN-----
MEUCIQDz6ggeNw3FXj6TRZajQYUaVce6Wbw5++Pl+fLuwChejwIgJ0ZUbS+Gtyd/PTlLu5Yw7mI7EJtFbmGJ2ucKTjeEA+M=
-----END SIGSTORE COSIGN-----
For Sigsum proofs:
-----BEGIN SIGSUM PROOF-----
version=1
log=5955bfe2150ee2e667c4e418228f9ee89835d6990248aad9b39c0e2120c1b022
leaf=7244
4f313845ab7b7bc4592e437869e838fcccef45b402bd970f8aa2628ec17ef5cf
e1f43026d9bf03ee21bb87db59f34593ec8c5f5a32abbbdeab23c24083f6078f5cc731e2a44ac66ac251640e850d69a94b1810012ca062b760a9cdf477e68a0a
size=21
root_hash=40574f3463b822fddaeed6cd6fd286b2c1229eb6059e27f127488b9625e299b7
signature=d9c19494a30c20c390967d8c8de452876a82559a26ee159d18d35081b701b610b6fb614ccb59644ba01e70bacd3a5ae6dad420235a30d7f5119857d68306fb02
cosignature=70b861a010f25030de6ff6a5267e0b951e70c04b20ba4a3ce41e7fba7b9b7dfc
1705693592
e51006f8f8d5415add21d24c4f5f2e1f6231030c70ba7a78f69aebaf2162c16627dbd6c461f8b71351281475d1ffc4cd8ff110df62cdc349a99faf0558de3705
leaf_index=20
node_hash=ee51a73cedb8d27e4b50359dad5be1f76f667134fef55b9d80c63fb80bbdb95e
node_hash=7b7f715c37c43a50164f585ba31c111e409074cc8a8dc8f51415587efff3dc57
-----END SIGSUM PROOF-----
The parser needs to understand each format, and pass it to the
respectively verifier somehow, and it has to ignore unknown data.
The outcome of the verifier should be possible to configure to print a
warning message or to refuse to use the file completely.
Managing trust settings can be done by putting Sigsum cosign keys under
/etc/apt/trusted.sigstore.d/ and putting Sigsum policy files under
/etc/apt/trusted.sigsum.d/.
Verifiers for Sigstore and Sigsum brings in additional packages
dependencies, so I don't think this should be added to the default 'apt'
package. There could be a separate package 'apt-sigstore' that Depends:
on the required dependencies, and enable verification behaviour, and a
'apt-sigsum' package that would work the same way. The normal 'apt'
package could Suggest or Recommends these packages.
Thoughts?
/Simon
Acknowledgement sent
to Julian Andres Klode <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 26 Jan 2024 11:21:05 GMT) (full text, mbox, link).
On Fri, Jan 26, 2024 at 11:39:03AM +0100, Simon Josefsson wrote:
> Package: apt
> Severity: wishlist
>
> I believe it would be nice if apt could verify signatures from Sigstore
> cosign and/or verify Sigsum proofs, to augment the current PGP-based
> signature verification.
>
> While this can be handled outside of apt's awareness, it would also be
> possible for apt to support improved signature verification in-band.
>
> I'm interested in exploring any approach that leads to improved
> signature verification offering similar functionality as
> Sigstore/Sigsum, and offer to help work on this.
>
> To get the design process started on the in-band approach: one proposal
> is to extend the InRelease and Release.gpg file formats with additional
> information needed for Sigstore and Sigsum.
>
> After the PGP signature in InRelease and Release.gpg, you could include
> additional sections. For Sigstore cosign:
>
> -----BEGIN SIGSTORE COSIGN-----
> MEUCIQDz6ggeNw3FXj6TRZajQYUaVce6Wbw5++Pl+fLuwChejwIgJ0ZUbS+Gtyd/PTlLu5Yw7mI7EJtFbmGJ2ucKTjeEA+M=
> -----END SIGSTORE COSIGN-----
>
> For Sigsum proofs:
>
> -----BEGIN SIGSUM PROOF-----
> version=1
> log=5955bfe2150ee2e667c4e418228f9ee89835d6990248aad9b39c0e2120c1b022
> leaf=7244
> 4f313845ab7b7bc4592e437869e838fcccef45b402bd970f8aa2628ec17ef5cf
> e1f43026d9bf03ee21bb87db59f34593ec8c5f5a32abbbdeab23c24083f6078f5cc731e2a44ac66ac251640e850d69a94b1810012ca062b760a9cdf477e68a0a
>
> size=21
> root_hash=40574f3463b822fddaeed6cd6fd286b2c1229eb6059e27f127488b9625e299b7
> signature=d9c19494a30c20c390967d8c8de452876a82559a26ee159d18d35081b701b610b6fb614ccb59644ba01e70bacd3a5ae6dad420235a30d7f5119857d68306fb02
> cosignature=70b861a010f25030de6ff6a5267e0b951e70c04b20ba4a3ce41e7fba7b9b7dfc
> 1705693592
> e51006f8f8d5415add21d24c4f5f2e1f6231030c70ba7a78f69aebaf2162c16627dbd6c461f8b71351281475d1ffc4cd8ff110df62cdc349a99faf0558de3705
>
> leaf_index=20
> node_hash=ee51a73cedb8d27e4b50359dad5be1f76f667134fef55b9d80c63fb80bbdb95e
> node_hash=7b7f715c37c43a50164f585ba31c111e409074cc8a8dc8f51415587efff3dc57
> -----END SIGSUM PROOF-----
I'm strongly opposed to add support for these off-the-shelve solutions.
We need end-to-end control of all aspects of signing.
What we learned with OpenPGP is that we don't want to be tied to third
party off-the-shelve solutions as we cannot control the cryptography and
are subject to the whims of their developers.
Hence we're still stuck with 1024-bit RSA keys in freaking 2024.
I have started apt-sign to get rid of the horrors of OpenPGP and get
a sensible format. I still have to make some changes to it, but if
we want to have a solution it essentially will boil down to adding
this to the Signatures field which will have lines of the form:
<algorithm> <base64-blob>
where <algorithm> currently is apt-ed448 or apt-ed25519.
It's entirely possible to require signatures from multiple keys
and implement co-signing that way rather than bolt on off-the-shelve
crap that we cannot control.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Acknowledgement sent
to Simon Josefsson <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 26 Jan 2024 12:00:04 GMT) (full text, mbox, link).
Julian Andres Klode <[email protected]> writes:
> I'm strongly opposed to add support for these off-the-shelve solutions.
> We need end-to-end control of all aspects of signing.
>
> What we learned with OpenPGP is that we don't want to be tied to third
> party off-the-shelve solutions as we cannot control the cryptography and
> are subject to the whims of their developers.
>
> Hence we're still stuck with 1024-bit RSA keys in freaking 2024.
>
> I have started apt-sign to get rid of the horrors of OpenPGP and get
> a sensible format. I still have to make some changes to it, but if
> we want to have a solution it essentially will boil down to adding
> this to the Signatures field which will have lines of the form:
>
> <algorithm> <base64-blob>
>
> where <algorithm> currently is apt-ed448 or apt-ed25519.
>
> It's entirely possible to require signatures from multiple keys
> and implement co-signing that way rather than bolt on off-the-shelve
> crap that we cannot control.
That seems interesting, where can we find this implementation? I can't
find a branch or merge request.
Where is the Signature: field placed? Inside the (In)Release file?
All the above seems orthogonal to support for key-usage transparency
mechanisms. Do you plan to implement that too? What protocol?
If not, your signature method ought to be extended to support some
key-usage transparency method, in some similar way to what I proposed
how to extend our current PGP-based verification with key-usage
transparency support. Sigstore and sigsum are two methods that I am
aware of, but there may be others.
Or, finally, if there will be no built-in key-usage transparency method
in apt, and no support for extensions to add support, this will be
supported externally to apt by those who care about it.
/Simon