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-pois > > > > 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
