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. >-- >Thanks, >Zac
Does Portage not call attention to critical updates? 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
signature.asc
Description: PGP signature
