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.

-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to