OpenPGP verification failed: gpg: Signature made Tue Mar 11 23:17:29 2025 UTC gpg: using RSA key 3F1719DED93071E74A9B66BC1226415D00DD3137 gpg: Can't check signature: No public key * ERROR: media-video/ffmpeg-7.1.1::gentoo failed (unpack phase): * PGP signature verification failed * * Call stack: ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_desktop_gnome-20250421-173411 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-14 * clang version 20.1.3 llvm-config: 20.1.3 Python 3.12.10 Available Ruby profiles: [1] ruby32 (with Rubygems) * Available Rust versions: [1] rust-bin-1.84.1 [2] rust-bin-1.86.0 * HEAD of ::gentoo commit 7932d08beb65ed83e47e72a9b8721f9cae92efba Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Mon Apr 21 19:20:18 2025 +0000 2025-04-21 19:20:17 UTC The tinderbox task was: %emerge -1u /lib*/*.a /usr/lib*/*.a @world emerge -qpvO =media-video/ffmpeg-7.1.1 [ebuild N ] media-video/ffmpeg-7.1.1 USE="X alsa bzip2 codec2 dav1d drm dvd fontconfig gnutls gpl gsm ieee1394 jpeg2k jpegxl lcms libass nvenc opencl opengl openh264 postproc samba sdl soc speex svg theora truetype verify-sig vorbis vulkan x264 xml xvid zeromq zlib -amf -amr -amrenc (-appkit) -bluray -bs2b -cdio -chromaprint -chromium -cuda -doc -fdk -flite -frei0r -fribidi -gcrypt -gme -gmp -iec61883 -jack -kvazaar -ladspa -lame -libaom -libaribb24 -libcaca -libilbc -liblc3 -libplacebo -librtmp -libsoxr -libtesseract -lv2 -lzma -modplug -npp -openal -openmpt -openssl -opus -pulseaudio -qrcode -qsv -quirc -rabbitmq -rav1e -rubberband -shaderc -snappy -sndio -srt -ssh -svt-av1 -twolame -v4l -vaapi -vdpau -vidstab -vmaf -vpx -webp -x265 -zimg -zvbi" ABI_X86="(64) -32 (-x32)"
Created attachment 925683 [details] emerge-info.txt
Created attachment 925684 [details] emerge-history.txt
Created attachment 925685 [details] environment
Created attachment 925686 [details] etc.clang.tar.xz
Created attachment 925687 [details] etc.portage.tar.xz
Created attachment 925688 [details] logs.tar.xz
Created attachment 925689 [details] media-video:ffmpeg-7.1.1:20250422-103320.log
Created attachment 925690 [details] qlist-info.txt
No idea what happened here? Patch verifies fine for me * Verifying ffmpeg-rpi-7.1.1.patch ... INFO File /tmp/portage/media-video/ffmpeg-7.1.1/distdir/ffmpeg-rpi-7.1.1.patch verified successfully against the signature in /tmp/portage/media-video/ffmpeg-7.1.1/distdir/ffmpeg-rpi-7.1.1.patch.asc: INFO - status: OpenPGPSignatureStatus.GOOD INFO - valid: True, trusted: True INFO - primary key: 528DE6BD8691A4391FDA2ED421C632129C6D7DE4 INFO - subkey: 3F1719DED93071E74A9B66BC1226415D00DD3137 INFO - timestamp: 2025-03-11 23:17:29 UTC
...and nothing seems to have changed recently with gnupg/gemato/verify-sig.eclass
Still good here too. Last time I saw something like this, it was because there hadn't been a bump to the keys package since my key had expired and I'd refreshed it. It's still good for another year now though.
Perhaps a victim of bug 949595.
(In reply to Sam James from comment #12) > Perhaps a victim of bug 949595. ``` Checking key=21C632129C6D7DE4, uids=['James Le Cuirot <chewi@aura-online.co.uk>', 'James Le Cuirot <chewi@gentoo.org>', 'James Le Cuirot <jlecuirot@microsoft.com>', 'James Le Cuirot <james.lecuirot@metaswitch.com>'] Dropping key['keyid']='21C632129C6D7DE4', key['uids']=['James Le Cuirot <chewi@aura-online.co.uk>', 'James Le Cuirot <chewi@gentoo.org>', 'James Le Cuirot <jlecuirot@microsoft.com>', 'Ja mes Le Cuirot <james.lecuirot@metaswitch.com>'] because not calculated as fully trusted ```
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5214415276699747bc01ace8f63435ecb31018e commit e5214415276699747bc01ace8f63435ecb31018e Author: Sam James <sam@gentoo.org> AuthorDate: 2025-04-23 12:06:05 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-04-23 12:12:06 +0000 sec-keys/openpgp-keys-gentoo-developers: add 20250421 Closes: https://bugs.gentoo.org/954220 Signed-off-by: Sam James <sam@gentoo.org> sec-keys/openpgp-keys-gentoo-developers/Manifest | 1 + .../openpgp-keys-gentoo-developers-20250421.ebuild | 236 +++++++++++++++++++++ 2 files changed, 237 insertions(+)
I don't really think we need to verify the SOC patch, though. I think it was added just because it otherwise necessitates a src_unpack being added to only verify the main distfile, but we already have a custom one now, so...
(In reply to Sam James from comment #15) > I don't really think we need to verify the SOC patch, though. I think it was > added just because it otherwise necessitates a src_unpack being added to > only verify the main distfile, but we already have a custom one now, so... Agreed, just kept it because it was there but I'd rather the extra verify -- patch manifest is generated by chewi so this doesn't really add any security.
(In reply to Ionen Wolkens from comment #16) > rather the extra verify drop the* I'll go ahead and do this.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ac150adcb9bb36815d80fdf17bce3fad43b1d34c commit ac150adcb9bb36815d80fdf17bce3fad43b1d34c Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2025-04-23 12:30:50 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2025-04-23 12:33:31 +0000 media-video/ffmpeg: drop verify-sig for soc patch The Manifest with the patch is generated and signed in git by the same person, so the extra signature serves no real purpose. Was likely formerly added to avoid having special logic in src_unpack, but we are using such logic either way now. Bug: https://bugs.gentoo.org/954220 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> media-video/ffmpeg/Manifest | 2 -- media-video/ffmpeg/ffmpeg-6.1.2-r1.ebuild | 17 ++--------------- media-video/ffmpeg/ffmpeg-7.1.1.ebuild | 17 ++--------------- media-video/ffmpeg/ffmpeg-9999.ebuild | 17 ++--------------- 4 files changed, 6 insertions(+), 47 deletions(-)
Actually, I was just trying to do what felt like the right thing, but your argument is sound. I still don't understand why it broke though. I'm pretty sure my key was valid on 20250203 and still is now.
