| 1 |
2018-07-03 16:04 GMT+03:00 Rich Freeman <rich0@g.o>: |
| 2 |
> On Tue, Jul 3, 2018 at 8:44 AM gevisz <gevisz@×××××.com> wrote: |
| 3 |
>> |
| 4 |
>> 2018-07-03 14:47 GMT+03:00 Rich Freeman <rich0@g.o>: |
| 5 |
>> > On Tue, Jul 3, 2018 at 7:06 AM gevisz <gevisz@×××××.com> wrote: |
| 6 |
>> >> |
| 7 |
>> >> Why not to put new openpgp-keys-gentoo-release |
| 8 |
>> >> into the portage tree BEFORE all existing Gentoo |
| 9 |
>> >> singing keys expire? |
| 10 |
>> >> |
| 11 |
>> > |
| 12 |
>> > My guess is that it was an oversight. |
| 13 |
>> > |
| 14 |
>> > I note that emerge --sync seems to update keys from the keyserver |
| 15 |
>> > automatically, and thus it didn't report any errors syncing for me. |
| 16 |
>> > On the other hand, I believe it will leave /usr/portage compromised if |
| 17 |
>> > an error is detected, so if you don't actually catch the error it |
| 18 |
>> > throws you can still be harmed. I assume webrsync won't do that, but |
| 19 |
>> > I haven't checked (the repository I use isn't available to webrsync as |
| 20 |
>> > far as I'm aware). |
| 21 |
>> |
| 22 |
>> emerge-webrsync do check gpg Gentoo signitures, if webrsync-gpg |
| 23 |
>> feature is enabled in /etc/portage/make.conf, but it cannot do so, if |
| 24 |
>> all Gentoo signitures expired, as it was the case after 1 July 2018. |
| 25 |
>> |
| 26 |
> |
| 27 |
> I know it checks sigs. I was assuming that it won't actually |
| 28 |
> overwrite a good /usr/portage with a bad one if the verification |
| 29 |
> fails. |
| 30 |
|
| 31 |
Yes. I think it the only acceptable behavior. |
| 32 |
|
| 33 |
> emerge --sync, with git at least, overwrites /usr/portage in place and |
| 34 |
> so it will leave it in a bad state if verification fails. |
| 35 |
|
| 36 |
It sounds really aweful. |
| 37 |
I did not know this as I always used only emerge-webrsync. |
Archives