The details are in bug 597800, but I covered this extensively in the commits which fixed this because of how confusing the situation was/is (https://gitweb.gentoo.org/proj/portage.git/commit/?id=28cd240fb23d880b8641a058831c6762db71c3e2). Quoting it: """ commit 28cd240fb23d880b8641a058831c6762db71c3e2 Author: Sam James <sam@gentoo.org> Date: Wed Mar 29 23:34:37 2023 +0100 emerge-webrsync: support PGP verification via gemato Introduce PGP verification of the webrsync snapshot tarballs using app-portage/gemato - which is already a dependency of Portage for verifying normal rsync. This is the same method Portage uses (see below). Technical changes before we dive into the rationale: - Use gemato for PGP verification just like Portage does for sync-type=webrsync, sync-type=rsync (although that uses a metamanifest), and sync-type=git (although that uses gemato for gpg-wrap, so works differently). - Use gentoo-functions automagically if available for better output functions. - Be more verbose about verification and various other operations, while also respecting --quiet if passed for misc. existing & new messages. - Make --verbose a no-op. There weren't enough output messages to justify three states (--quiet, normal, --verbose). - Bail out more aggressively in the event of errors or "warnings". - Use modern terminology for repository, etc (avoid overloading the "portage" term.) - Allow disabling PGP verification with --no-pgp-verify. Technically, the fix is very straightforward, but getting to the fix was the slightly painful bit. What I've concluded happened is: - Portage starts getting reworked to gain proper sync module support; - Someone gets the idea of implementing emerge-webrsync fully in Python as a Portage sync module (which is a not-unreasonable idea); [This ultimately hasn't gone anywhere, and in fact, while working on this bug, I ended up finding a bunch of typos that meant you couldn't even test it. But it's a stub anyway.] - The idea of deprecating emerge-webrsync is floated around. The idea being Portage should call it via its new sync module with sync-type=webrsync. This is presumably with the ultimate goal of it transparently one day using the aforementioned (yet-non-existent) Python implementation as its backend, and not the shell script. [To this day, Portage's webrsync implementation shells out to the emerge-webrsync shell script, but it has the abstraction to switch that out, in theory.] - At the time, PGP verification in general of the Gentoo repository is an active topic, especially now we'd migrated to git which makes it way easier, unlike CVS. - A bug is filed for PGP verification in emerge-webrsync. People decide it doesn't matter too much, because Portage is going to Real Soon Now (TM) have its own backend (replacing the shell script) and/or Portage's sync module support obsoletes emerge-webrsync entirely. The idea here, I think, being that nobody should call emerge-webrsync and everyone should just call emerge (or emaint) to sync as appropriate. [This isn't a terrible idea in a sense, but it needs a better basis: we should probably make emerge-webrsync a wrapper which creates a temporary repo config to forcefully webrsync a repository if the user asks us to. This is what people expect from emerge-webrsync with the default sync-type=rsync in repos.conf for ::gentoo. I actually started implementing this before I realised that emerge was shelling out to emerge-webrsync, so have postponed it.] - Then nothing happens with the "replacement" ideas and the good ol' trusty emerge-webrsync ends up with the same problems sitting there because nobody saw the point in working on it if it was to be replaced soon. But that didn't happen. The fix overall for this is pretty small, but the commit is larger than I'd like because I had to rework a few things to sensibly allow disabling PGP verification as well as follow the flow. (I did start splitting up this commit but ultimately it needs -w for best review even without the output tweaks in this commit and deconstructing this for atomic commits would end up being more brittle as I couldn't be as confident in the result.) Bug: https://bugs.gentoo.org/597800 Signed-off-by: Sam James <sam@gentoo.org> """
Summary being: - emerge-webrsync, as a standalone command, would not verify PGP signatures (even though it fetched them). - Portage calls emerge-webrsync when configured with sync-type='webrsync' in repos.conf, but is not affected because it does validation afterwards. - Fixed in portage-3.0.47 but with a fairly significant rewrite of how emerge-webrsync works.
I cannot verify it right now... but I ended up here because I couldn't make emerge-webrsync... it was apparently downloading the files but later thinking it couldn't retrieve them and going back and back just the latest old used snapshot. I think that could be due to me not having gemato on those systems and probably the new code not auto-disabling verification if not found
Thanks, could you file a new bug please?
Not stable yet.
I would say either A3 or A4?
Agreed
Cleanup done in commit f02e131e19d855d7823d9a94e943f616d0bdc303 Author: Sam James <sam@gentoo.org> Date: Sun Dec 3 08:00:20 2023 +0000 sys-apps/portage: drop 3.0.52, 3.0.53, 3.0.54-r1, 3.0.55 Signed-off-by: Sam James <sam@gentoo.org> I think we do want to GLSA this, and we do need to request a CVE.
CVE requested.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glsa.git/commit/?id=230d731718c558194c0f0f4db0db15fa3d590f43 commit 230d731718c558194c0f0f4db0db15fa3d590f43 Author: GLSAMaker <glsamaker@gentoo.org> AuthorDate: 2024-09-22 05:36:27 +0000 Commit: Hans de Graaff <graaff@gentoo.org> CommitDate: 2024-09-22 05:37:27 +0000 [ GLSA 202409-01 ] Portage: Unverified PGP Signatures Bug: https://bugs.gentoo.org/905356 Signed-off-by: GLSAMaker <glsamaker@gentoo.org> Signed-off-by: Hans de Graaff <graaff@gentoo.org> glsa-202409-01.xml | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+)
