140677309630272:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:crypto/pkcs7/pk7_smime.c:284:Verify error:certificate has expired * ERROR: net-dns/dnssec-root-20181220-r1::gentoo failed (prepare phase): * OpenSSL S/Mime verify failed * * Call stack: * ebuild.sh, line 127: Called src_prepare * environment, line 512: Called die ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no_multilib_hardened-j4-20211105-190003 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-11.2.0 * clang version 13.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/13/bin /usr/lib/llvm/13 13.0.0 Python 3.9.8 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby27 (with Rubygems) [3] ruby30 (with Rubygems) * Available Rust versions: [1] rust-1.56.1 * The Glorious Glasgow Haskell Compilation System, version 8.10.4 php cli: HEAD of ::gentoo commit aa24e8cb3c7a2f063efc82c84c46758014cb6a06 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Mon Nov 8 03:06:38 2021 +0000 2021-11-08 03:06:34 UTC emerge -qpvO net-dns/dnssec-root [ebuild N ] net-dns/dnssec-root-20181220-r1
Created attachment 749526 [details] emerge-info.txt
Created attachment 749529 [details] emerge-history.txt
Created attachment 749532 [details] environment
Created attachment 749535 [details] etc.portage.tar.bz2
Created attachment 749538 [details] net-dns:dnssec-root-20181220-r1:20211108-034822.log
Created attachment 749541 [details] temp.tar.bz2
Not an OpenSSL 3.0 problem.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1b0c2f134e2582bdb23a1e2f965e865dba1fbe47 commit 1b0c2f134e2582bdb23a1e2f965e865dba1fbe47 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2021-11-08 15:14:43 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2021-11-08 15:14:54 +0000 net-dns/dnssec-root: don't verify signature chain We are only interested in verifying root-anchors.xml itself. We do not care about the signature chain. Closes: https://bugs.gentoo.org/822447 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> net-dns/dnssec-root/dnssec-root-20181220-r1.ebuild | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
For everyone reading this and is now concerned regarding usage of "-noverify": We will still catch file manipulations. I.e. if you change root-anchors.xml in your DISTFILES directory and somehow managed to workaround Manifest verification, we will still be able to catch that manipulation like intended in that check: > >>> Preparing source in /var/tmp/portage/net-dns/dnssec-root-20181220-r1/work/dnssec-root-20181220 ... > * dev-libs/openssl is available, will validate signature of root-anchors.xml > <?xml version="1.0" encoding="UTF-8"?> > <TrustAnchor id="380DC50D-484E-40D0-A3AE-68F2B18F61C7" source="http://data.iana.org/root-anchors/root-anchors.xml"> > <Zone>.</Zone> > <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-11T00:00:00+00:00"> > <KeyTag>19036</KeyTag> > <Algorithm>8</Algorithm> > <DigestType>2</DigestType> > <Digest>49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</Digest> > </KeyDigest> > <KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00"> > <KeyTag>20326</KeyTag> > <Algorithm>8</Algorithm> > <DigestType>2</DigestType> > <Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D</Digest> > </KeyDigest> > <blub /> > </TrustAnchor> > Verification failure > 139675540838208:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:crypto/pkcs7/pk7_doit.c:1011: > 139675540838208:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:crypto/pkcs7/pk7_smime.c:353: (Note: I added a "<blub />" element) We only disabled validation of certificate itself which we do not care about.
Today I am run to the same issue because I am using an older Portage Tree. Instead of disabling the Check, I have simple use the new IANA Certificates, which are available since 2021-09-02 (If your system is online and download this files direct from the IANA, you have no Problems, but I am using a static mirror and there are still the old files). So My Fix is: Update Version to 20210902 Put root-anchors-20210902.xml, root-anchors-20210902.p7s and icannbundle-20210902.pem to my local reposity. Now the check will by OK. Maybe Gentoo can do the same.
(In reply to Kai Dietrich from comment #10) > Today I am run to the same issue because I am using an older Portage Tree. > > Instead of disabling the Check, I have simple use the new IANA Certificates, > which are available since 2021-09-02 (If your system is online and download > this files direct from the IANA, you have no Problems, but I am using a > static mirror and there are still the old files). > So My Fix is: Update Version to 20210902 > Put root-anchors-20210902.xml, root-anchors-20210902.p7s and > icannbundle-20210902.pem to my local reposity. > > Now the check will by OK. > > Maybe Gentoo can do the same. That doesn't really explain the need though. You can file a new bug if you want a bump instead of commenting on a long-closed one, and it's valid to want a newer version, but in terms of the check itself, it's meaningless in the ebuild.
(In reply to Sam James from comment #11) > (In reply to Kai Dietrich from comment #10) > > Today I am run to the same issue because I am using an older Portage Tree. > > > > Instead of disabling the Check, I have simple use the new IANA Certificates, > > which are available since 2021-09-02 (If your system is online and download > > this files direct from the IANA, you have no Problems, but I am using a > > static mirror and there are still the old files). > > So My Fix is: Update Version to 20210902 > > Put root-anchors-20210902.xml, root-anchors-20210902.p7s and > > icannbundle-20210902.pem to my local reposity. > > > > Now the check will by OK. > > > > Maybe Gentoo can do the same. > > That doesn't really explain the need though. You can file a new bug if you > want a bump instead of commenting on a long-closed one, and it's valid to > want a newer version, but in terms of the check itself, it's meaningless in > the ebuild. ... actually, yes, please file a new bug requesting a version bump, as I can't even at a glance see where these are supposed to be.
