2018-07-03 16:04 GMT+03:00 Rich Freeman <ri...@gentoo.org>: > On Tue, Jul 3, 2018 at 8:44 AM gevisz <gev...@gmail.com> wrote: >> >> 2018-07-03 14:47 GMT+03:00 Rich Freeman <ri...@gentoo.org>: >> > On Tue, Jul 3, 2018 at 7:06 AM gevisz <gev...@gmail.com> wrote: >> >> >> >> Why not to put new openpgp-keys-gentoo-release >> >> into the portage tree BEFORE all existing Gentoo >> >> singing keys expire? >> >> >> > >> > My guess is that it was an oversight. >> > >> > I note that emerge --sync seems to update keys from the keyserver >> > automatically, and thus it didn't report any errors syncing for me. >> > On the other hand, I believe it will leave /usr/portage compromised if >> > an error is detected, so if you don't actually catch the error it >> > throws you can still be harmed. I assume webrsync won't do that, but >> > I haven't checked (the repository I use isn't available to webrsync as >> > far as I'm aware). >> >> emerge-webrsync do check gpg Gentoo signitures, if webrsync-gpg >> feature is enabled in /etc/portage/make.conf, but it cannot do so, if >> all Gentoo signitures expired, as it was the case after 1 July 2018. >> > > I know it checks sigs. I was assuming that it won't actually > overwrite a good /usr/portage with a bad one if the verification > fails.
Yes. I think it the only acceptable behavior. > emerge --sync, with git at least, overwrites /usr/portage in place and > so it will leave it in a bad state if verification fails. It sounds really aweful. I did not know this as I always used only emerge-webrsync.
