On domenica 21 luglio 2019 13:22:55 CEST Stefano Crocco wrote: > On domenica 21 luglio 2019 12:44:14 CEST Mick wrote: > > On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote: > > > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > > > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > > > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > > > > Hello to everyone, > > > > > > since yesterday emerge --sync fails because it can't refresh keys. > > > > > > The > > > > > > messages I get are: > > > > > > > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > > > > * Refreshing keys via WKD ... [ !! ] > > > > > > * Refreshing keys from keyserver hkps://keys.gentoo.org > > > > > > ...OpenPGP > > > > > > keyring > > > > > > > > > > > > refresh failed: > > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > > > > > OpenPGP keyring refresh failed: > > > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > > > Perhaps something to do with this? > > > > > > > > > > https://www.bleepingcomputer.com/news/security/public-certificate-po > > > > > is > > > > > on > > > > > in > > > > > g-> > > > > > > > > can-break-some-openpgp-implementations/ > > > > > > > > > Aside: > > > > > I have already switched my personal gpg configuration to use the new > > > > > isolated keyserver. > > > > > > > > Thanks for the answer. I'd heard of this attack and read this [1] > > > > article > > > > on gentoo.org. From what I understand, it said that in theory there > > > > shouldn't be problems when syncing because "The gemato tool used to > > > > verify the Gentoo ebuild repository uses WKD by default. During normal > > > > operation it should not be affected by this vulnerability". Reading > > > > the > > > > article again, I now see it also says that "In the worst case; Gentoo > > > > repository syncs will be slow or hang" which, as you suggest, could > > > > very > > > > well be what's happened on my system. Unfortunately, the article > > > > doesn't > > > > say what to do if this happens. > > > > > > > > Tomorrow I'll try investigating more. > > > > > > > > Stefano > > > > > > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html > > > > > > It seems I found out how to fix the issue. I tried comparing my > > > /usr/share/portage/config/repos.conf with the one which comes with a > > > current stage3 and found out mine had the line > > > > > > sync-openpgp-keyserver = hkps://keys.gentoo.org > > > > > > which was missing in the file from stage3. Removing it (both here and in > > > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I > > > hope > > > this is the correct fix. I don't remember ever writing this line, so I > > > suppose it came with the original stage3 I built my system from or was > > > changed by another update (an update of what, however? According to > > > `equery > > > b`, this file doesn't belong to any package). > > > > > > I hope thing will keep working. > > > > > > Stefano > > > > I grepped two older installations I had immediate access to and there is > > no > > directive containing "openpgp" anywhere within /etc/portage/. > > > > In a new-ish installation there were a number of entries in /etc/portage/ > > > > repos.conf/gentoo.conf, but no keyserver URI: > > $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf > > > > sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc > > sync-openpgp-key-refresh-retry-count = 40 > > sync-openpgp-key-refresh-retry-overall-timeout = 1200 > > sync-openpgp-key-refresh-retry-delay-exp-base = 2 > > sync-openpgp-key-refresh-retry-delay-max = 60 > > sync-openpgp-key-refresh-retry-delay-mult = 4 > > > > Perhaps you had added a keyserver as a fall back when you were configuring > > your system to use WKD? I haven't implemented WKD because there was no > > news item advising us to do so. > > Maybe. I really know nothing about these issues, so I'm sure I wouldn't have > added that line by myself. Maybe I read about them somewhere and I forgot > about it. > > Stefano
If anyone is interested, I've found out a bit more about this issue. The mysterious line sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc is the default in portage since version 2.3.69 (~arch). This means that the problem suddenly reappeared the first time portage got updated. By chance, I'd just bought a new laptop and had finished installing Gentoo on it the day before. I tried syncing from it... and it worked. I was getting angry: on my desktop and my old laptop emerge --sync didn't work; on my new laptop it did. Of course, the three machines were configured almost in the same way, so I couldn't understand what could be causing the difference. Searching again on Google, I somehow found out the bug report [1], which says that in the past gnupg --refresh-keys could fail if ipv6 was disabled. The bug report is marked as resolved with the release of gnupg-2.2.4-r2 last year; however, I knew that on my new laptop I had left ipv6 enabled while on the other two machines I had disabled it (I can't remember why, but disabling ipv6 is usually one of the first things I do on a new system). Could this be a coincidence? I immediately rebuilt the kernel on my desktop PC with ipv6 enabled, rebooted, tried to sync, and it worked. Just to be sure, I disabled it again, and it stopped working. At this point, I think I'll file a bug report and see what they say. Stefano [1] https://bugs.gentoo.org/646194
