On 07/08/2018 02:50 PM, Aaron W. Swenson wrote: > On July 8, 2018 5:38:48 PM EDT, Zac Medico <zmed...@gentoo.org> wrote: > > On 07/08/2018 02:18 PM, Michał Górny wrote: > > W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico > napisał: > > On 07/08/2018 01:18 PM, Zac Medico wrote: > > On 07/08/2018 01:08 PM, Michał Górny wrote: > > W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, > użytkownik Zac Medico > napisał: > > On 07/08/2018 11:42 AM, Michał Górny wrote: > > W dniu nie, 08.07.2018 o godzinie 11∶04 > -0700, użytkownik Zac Medico > napisał: > > On 07/08/2018 06:56 AM, Michał Górny wrote: > > W dniu nie, 08.07.2018 o godzinie > 15∶02 +0200, użytkownik Kristian > Fiskerstrand napisał: > > On 07/08/2018 08:53 AM, Michał > Górny wrote: > > Is safe git syncing > implemented already? If not, > maybe finish it first and > cover both with a single > news item. Git is going to > be more efficient here, so > people may want to learn > they have an alternative. > > > Why complicate things, and > increase wait for something that > benefits > most users, just to give > alternatives to a few using > non-default sync > mechanism. Securing git > distribution is a whole > different ballpark. > > > > Let me rephrase. Let's say I'm using > rsync. This new feature is > something positive but it breaks my > use case (for one of the listed > reasons -- overlayfs, inode use, > small fs cache). After reading this > news item, I learn that my only > option is to disable the new feature. > > Now, I would appreciate being told > that there's an alternate sync method > that handles secure updates without > having all those drawbacks. > > > The thing is, the normal git tree > doesn't even provide pre-generated > metadata, and I see then gentoo-mirror > repo that provides metadata does > not have commits signed with an release key: > > > https://github.com/gentoo-mirror/gentoo/commits/stable > > So I'm really not comfortable > recommending git to anyone at this point. > > > Wrong twice. > > Firstly, the canonical URL is: > > > https://anongit.gentoo.org/git/repo/sync/gentoo.git > (https://gitweb.gentoo.org/repo/sync/gentoo.git) > > Secondly, the merge commits (i.e. top > commits that are verified > by Portage) are signed by dedicated key that > is part of the infra key > set. In other words, it works out of the box. > > > Is there any documentation that shows users how > to migrate to git, and > what the pros and cons might be? Maybe its > worthy of its own news item. > > > Maybe. I don't really know, and don't think it's a > good idea to show 30 > news item of things users might like on every new > Gentoo install. > > > Well if instructions for setting up git sync and > associated pros/cons > are not documented anywhere then I won't advise anyone > to use it. > > > I've attempted to configure it for myself, and this is what > it does: > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > * Refreshing keys from keyserver ... > [ ok ] > * No valid signature found: unable to verify signature > (missing key?) > > > > Please report a bug and attach your configuration along with keyring > version. > > > It works after upgrading to openpgp-keys-gentoo-release-20180706 from > openpgp-keys-gentoo-release-20180323. > > > Does Portage not call attention to critical updates?
No, but that might be a nice feature. We'd have to introduce some kind of standard mechanism via PMS or a GLEP. > It used to make a special statement for a new stable Portage and > strongly recommended that it be emerged first. It should probably do the > same for openpgp-keys-gentoo-release. Sure, but it this case we have a chicken-and-egg problem, because I needed the latest openpgp-keys-gentoo-release installed but in order to do that I had to sync, but then verification failed because I didn't have the latest openpgp-keys-gentoo-release. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
