Re: [gentoo-user] Re: emerge --sync: problem refreshing keys

[Mick]

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-poison
> > > 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.
-- 
Regards,

Mick