Usability issue when gpg fails

[kc2zgu]

I was trying to run getuto in order to use the official binary package server on a new install and could not get package verification to work.

Long story short, the machine was connected to a corporate network with a firewall blocking the hkps:// keyserver protocol; switching to another network fixed it.

When first running getuto the gpg call to import keys seemed to hang forever; I eventually stopped it and this left the /etc/portage/gnupg directory incomplete and with wrong permissions so portage could not verify anything. Apparently it did update the last run file though, so attempting to run getuto again did nothing (with no output whatsoever - there should be a message like "0 days since last update, Nothing to do") unless the directory is deleted to start over.

[triffid]

Is this what's happening when it hangs seemingly forever after:

 # getuto
 * Initializing /etc/portage/gnupg ...
gpg: Generating Portage local OpenPGP trust key
gpg: done
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: key BB572E0E2D182910: no user ID
gpg: key BB572E0E2D182910: no user ID
gpg: key 9E6438C817072058: no user ID
gpg: key 9E6438C817072058: no user ID
gpg: key DB6B8C1F96D8BF6D: no user ID
gpg: key DB6B8C1F96D8BF6D: no user ID
gpg: key A13D0EF1914E7A72: no user ID
gpg: key A13D0EF1914E7A72: no user ID

with dirmngr using 100% of a CPU core?

Because I'm experiencing this on my home internet - which obviously otherwise works since I'm commenting on this issue…

[thesamesam]

59a86cb should help a bit but it's not the real issue. gpg claims to already have default timeouts. We're discussing what to do there.

gemato seems to suffer from the same issue even though it too sets its own timeouts.

[triffid]

Would it be possible to pre-seed from a cached keystore that can be used straight away, with actually updating it from hkps being something that can happen later?

It did eventually complete for me, but took well over 30 minutes - which is kinda a surprising roadblock for using Gentoo's new binary package repo.

[thesamesam]

Yeah, we can do that (only import from local keys on first-run) although I'm not sure if it's going to be a big UX boost or not, given they may just get a hang when trying to update later. I guess it might make it more obvious that something is wrong. But I suppose it's strictly better as we're hanging less of the time.

What I'd really appreciate is if someone could try nail down why the timeouts don't seem to work at all. It matters for gemato too.

@eli-schwartz would like us to move to an async model where we just fire off gpg and let it do its thing in the background which is probably a good idea, for getuto anyway.

[thesamesam]

See gentoo/gemato#35. I think we need to add a hard timeout via trap.

[triffid]

Problem with hard timeout is that emerge gets quite angry about the binpkg repo if /etc/portage/gnupg/ isn't set up appropriately - what would be in there if the timeout is triggered, and would portage refuse to merge stuff if it's in that state?

If users are getting their stage3 and suchforth without anything strictly checking keysigning, when and how is it actually important to begin enforcing the use of the most recent key information possible?

My suggestion of pulling a static cache initially that can be updated later/conveniently is based on the idea that if someone's grabbing their stage3 and other bits and bobs from an untrusted source that could theoretically compromise the key check anyway, it's not terribly important for keysigning to be strictly checked during initial setup if it's going to be a huge issue for legitimate installs to do so - but a system that was set up a month ago and is now relied upon probably should be checking keys properly, and throw errors if something's wrong.

[thesamesam]

Problem with hard timeout is that emerge gets quite angry about the binpkg repo if /etc/portage/gnupg/ isn't set up appropriately - what would be in there if the timeout is triggered, and would portage refuse to merge stuff if it's in that state?

I meant for getuto invoking gpg, rather than Portage terminating getuto (although perhaps it should have some very high timeout for that too). i.e. if a fetch times out, it carries on to the rest of the script.

My suggestion of pulling a static cache initially that can be updated later/conveniently is based on the idea that if someone's grabbing their stage3

I don't object to this on a trust basis or anything, I'm just saying I'm not sure it's that much of a win if the new user just has their emerge hang on day 2 of their install instead.