emerge: WARNING:urllib3.connection:Certificate did not match

Eggplants · n00b Joined: 22 Oct 2011 Posts: 20

I'm seeing this when I do an emerge --sync:

greyhare · n00b Joined: 05 Jun 2014 Posts: 7

Getting the same thing here for a couple days. It looks like the mirror doesn’t have Gentoo’s certificate, so the hosting provider is substituting their own, but I can’t be sure.

soundrolf · Posted: Fri Feb 03, 2023 10:33 am Post subject:

Same result today

mmogilvi · n00b Joined: 13 May 2011 Posts: 62

I see the same thing, but only sometimes. Probably based on which DNS response (mirror) it happens to try first, each time.

I suspect it would be safe to follow a procedure:

Control-C cancel the sync if you see that error.
Re-start the sync
When/if a sync doesn't give that message, let it finish, and then continue to update using with the result.

If you've already let it finish with the error, don't try to do anything that might partially execute ebuilds (possibly not even "emerge -p"), until you can follow the above procedure successfully (and watch out for the way emerge --sync typically aborts the sync if it detects that a timestamp file hasn't changed - that isn't a full sync). Or: If this is the "first" machine, and other machines on your LAN are set to sync to your first machine, you could try the procedure on those other machines (assuming they still get the keys from the external key servers), and if they work, then the "first" machine should also be OK.

It might be fairly safe to proceed with the update anyway, depending on exactly why emerge --sync decided to proceed with the sync despite the key update error.
FUTURE: If it were to explain its reasoning with a message like "key update failed; proceeding using previous keys", then I would be more confident that what it was doing was reasonably safe. (Or even better: fail, but have (and mention in the error message) a command-line option that could allow it to proceed using previous keys.) (However, I could still imagine an attack scenario where the old keys were leaked and replaced, and an attacker spoofs a key server that always fails (to prevent you from getting the new keys), and also spoofs a sync server with malware ebuilds/package manifests signed using the now-leaked old keys... (glossing over the plublic vs private parts of keys))

Eggplants · n00b Joined: 22 Oct 2011 Posts: 20

Looks like a bug has been filed on this:

https://bugs.gentoo.org/892976