On 11 May 2016 at 22:21, Alexis Ballier <aball...@gentoo.org> wrote: > > yes, and it was meant to be :) > > > my point was more that if we want signed commits, then better have > author sign it, and thus use merge
Eh, I see it more a "signed commits don't really add any value to this discussion". Both signing on master with rebase, and signing on a side branch by the author and signed at the merge point "work", they both do what they meant to achieve: That essentially, there is always going to be a gentoo gatekeeper with a *known* signature signing a critical part of the chain, ensuring referential integrity of the chain of custody. That, imo, results in us discarding this argument, and folding back to the "what are the benefits of rebasing/merging on their own merits again?" , of which, there are many, even in the absence of signing. > if we just want committer signature, then I don't really see the > point in signing: it isnt more secure than pecker access + ldap > password, and infra could simply sign public git trees with a unique > gentoo key There's an added security measure that exists /outside/ the gentoo source control. It means that you can still ascertain some degree of "authority" without having to rely on gentoo's centralised control system. For instance, that Perl branch in the overlay that was pending, you can still validate who created it, and how, and who last touched each and every commit, despite the fact its not yet anywhere near gentoo infrastructure. And being able to *independently* verify an arbitrary git commit was created by the person who claims to have created it, is a good thing. And that *independent* data can be used as a selection criteria by maintainers pulling commits into gentoo. But that said, none of this really reflects on wether we should use merges or rebases. Those situations are primarily driven by the nature of the work itself, not our meta-level security concerns. -- Kent KENTNL - https://metacpan.org/author/KENTNL
