On 07/08/2018 02:59 PM, Zac Medico wrote: > 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.
Actually GLEP 42 news items can be used for this, with a header like: Display-If-Installed: <app-crypt/openpgp-keys-gentoo-release-20180706 -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
