csaf_distribution
csaf_distribution copied to clipboard
csaf-poc
Redhat's file signatures fail to verify (because they use OpenPGP signatures with the old signature package V3)
Using csaf_distribution-v2.1.0-gnulinux-amd64: when downloading from redhat.com the signatures do not verify.
curl -L -O https://github.com/csaf-poc/csaf_distribution/releases/download/v2.1.0-gnulinux-amd64.tar.gz
tar -xvmlzf csaf_distribution-v2.1.0-gnulinux-amd64.tar.gz
./csaf_distribution-v2.1.0-gnulinux-amd64/bin-linux-amd64/csaf_downloader --verbose --rate=10 redhat.com
[..]
2023/04/26 09:49:05 [GET]: https://access.redhat.com/security/data/csaf/v2/advisories/2001/rhsa-2001_058.json
[..]
2023/04/26 09:49:06 [GET]: https://access.redhat.com/security/data/csaf/v2/advisories/2001/rhsa-2001_058.json.asc
2023/04/26 09:49:06 Cannot verify signature for https://access.redhat.com/security/data/csaf/v2/advisories/2001/rhsa-2001_058.json
[..]
2023/04/26 09:55:32 Cannot verify signature for https://access.redhat.com/security/data/csaf/v2/advisories/2005/rhsa-2005_586.json
2023/04/26 09:55:32 [GET]: https://access.redhat.com/security/data/csaf/v2/advisories/2005/rhsa-2005_587.json
[..]
Manual checking shows that GnuPG believes in the signature, e.g.:
curl -O https://access.redhat.com/security/data/csaf/v2/advisories/2005/rhsa-2005_586.json
curl -O https://access.redhat.com/security/data/csaf/v2/advisories/2005/rhsa-2005_586.json.asc
gpg --keyserver keyserver2.gnupg.org --recv-keys "77E7 9ABE 9367 3533 ED09 EBE2 DCE3 8235 97F5 EAC4"
gpg -v --verify rhsa-2005_586.json.asc
gpg: armor header: Version: GnuPG v1
gpg: assuming signed data in 'rhsa-2005_586.json'
gpg: Signature made Do 09 Mär 2023 20:57:15 CET
gpg: using RSA key DCE3823597F5EAC4
gpg: using pgp trust model
gpg: Good signature from "Red Hat, Inc. (Product Security) <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 77E7 9ABE 9367 3533 ED09 EBE2 DCE3 8235 97F5 EAC4
gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096
@tschmidtb51 we shall investigate, I assume.
@bernhard-herzog can you add your code, to getare more verbose error message from the failed signature
I checked out main and upgraded the 3rdparty libs with
go get -u -v ./... and rebuilt the checker and it works.
Further digging with a debugger reveals that the signature check fails because the signature (I used rhsa-2001_058.json.asc) uses signature packet format version 3 which is not supported by go-crypto.
The code there even produces an error with that information, but detail is then lost in the openpgp library where a more generic "Invalid signature" is returned instead. The CSAF code also suppresses information because any failure during the signature check is turned into a simple boolean and is the reported as "Cannot verify signature ...", so details on why the check failed are lost.
I checked out main and upgraded the 3rdparty libs with
go get -u -v ./...and rebuilt the checker and it works.
It still doesn't work for me. The code in question that rejects packet version 3 hasn't changed, so I don't think it could work for the signatures I observed the problem with. All of those are in the 2001 subdirectory, I haven't checked any others.
I checked out main and upgraded the 3rdparty libs with
go get -u -v ./...and rebuilt the checker and it works.
Argh! I used the checker and not the downloader. I can confirm that updating the libs does not help.
@s-l-teichmann does signature validation work with the checker, though? ;)
Seems to be https://github.com/ProtonMail/go-crypto/issues/164 which is biting a few people already.
gpg -vv --verify rhsa-2005_586.json.ascgpg: armor: BEGIN PGP SIGNATURE
gpg: armor header: Version: GnuPG v1
# off=0 ctb=89 tag=2 hlen=3 plen=533
:signature packet: algo 1, keyid DCE3823597F5EAC4
version 3, created 1678391835, md5len 5, sigclass 0x00
digest algo 8, begin of digest 5a d6
data: [4095 bits]
gpg: assuming signed data in 'rhsa-2005_586.json'
gpg: Signature made Do 09 Mär 2023 20:57:15 CET
gpg: using RSA key DCE3823597F5EAC4
[..]
Note that https://www.rfc-editor.org/rfc/rfc4880#section-5.2 reads
Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures.
(Note that Implementation in the quote refers to implementing OpenPGP itself, not our implementation of the downloader.)
The SHOULD means that Redhat would need to have valid reasons in particular circumstances to create v3 signatures here. Given that their signature has Version: GnuPG v1, they probably should not have created it in 2023. Unless there are special circumstances I'd say that CSAF should mandate at least V4 signatures, because CSAF is a new application and can thus set a modern requirement here.
@bernhard-herzog can you put in better diagnostic reporting and then assign it to @tschmidtb51 ?
@bernhardreiter
>
@s-l-teichmann does signature validation work with the checker, though? ;)
Obviously not. But the failure is noted in the report and not on STDERR where i had looked for the message.
PR #363 added a flag ignoresigcheck to ignore the results of the signature checks in the downloader.
Without this the downloads would fail entirely.
There is a soft fork of go-crypto at https://github.com/pgpkeys-eu/go-crypto that restores V3 support.
Add the following to go.mod to try it out:
replace github.com/ProtonMail/go-crypto => github.com/pgpkeys-eu/go-crypto v0.0.0-20230506215654-16de0cc09494
@andrewgdotcom thanks for the hint.
(We are not sure yet, if it wouldn't be better to mandate v4 or higher signatures in the CSAF standard directly. At least V4 SHOULD already be used unless we know the reasoning of Redhat.)
RedHat didn't have any reasoning, they just forgot about it:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6496
RedHat didn't have any reasoning, they just forgot about it: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6496
That is packaging, I mean fresh CSAF publications (see beginning of this issue). :)
I've just send an email to Redhat, asking if they could change the signature. Got the contact address from https://www.redhat.com/en/blog/csaf-vex-documents-now-generally-available , the CSAF providermetadata file and https://access.redhat.com/security/team/contact/ .
There is a new issue https://issues.redhat.com/browse/SECDATA-300 which will lead to new signatures on the files. However, so far it does not say something about the signature packet format, which is the problem here.
We shall stop working on the issue, until we see what Redhat does here.
(We have ignoresigcheck and a better diagnostic message in place already, if I remember correctly.)
There is a new issue https://issues.redhat.com/browse/SECDATA-300 which will lead to new signatures on the files. However, so far it does not say something about the signature packet format, which is the problem here.
I'll asked Redhat about it.
Redhat has responded and gave me a new issue, they will address: https://issues.redhat.com/browse/SECDATA-304
Redhat has made some improvements, so there are now files which have an OpenPGP signature format version 4, which is fine. However not all files have been resigned yet.
A file that works: https://access.redhat.com/security/data/csaf/v2/advisories/2001/rhsa-2001_164.json
Some that do not:
https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_251.json
https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_259.json
https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_270.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_271.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_287.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_288.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_289.json https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_290.json
https://issues.redhat.com/browse/SECDATA-304 has been closed, but
curl -O https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_290.json
curl -O https://access.redhat.com/security/data/csaf/v2/advisories/2002/rhsa-2002_290.json.asc
gpg -vv --verify rhsa-2002_290.json.asc
:signature packet: algo 1, keyid DCE3823597F5EAC4
version 3, created 1675238242, md5len 5, sigclass 0x00
digest algo 8, begin of digest 40 b6
data: [4093 bits]
gpg: assuming signed data in 'rhsa-2002_290.json'
gpg: Signature made Mi 01 Feb 2023 08:57:22 CET
gpg: using RSA key DCE3823597F5EAC4
So it is still broken (which can be seen from the version 3 and the time (before June 2023).