| 1 |
On 11 May 2016 at 22:21, Alexis Ballier <aballier@g.o> wrote: |
| 2 |
> |
| 3 |
> yes, and it was meant to be :) |
| 4 |
> |
| 5 |
> |
| 6 |
> my point was more that if we want signed commits, then better have |
| 7 |
> author sign it, and thus use merge |
| 8 |
|
| 9 |
Eh, I see it more a "signed commits don't really add any value to this |
| 10 |
discussion". |
| 11 |
|
| 12 |
Both signing on master with rebase, and signing on a side branch by |
| 13 |
the author and signed at the merge point "work", they both do what |
| 14 |
they meant to achieve: |
| 15 |
|
| 16 |
That essentially, there is always going to be a gentoo gatekeeper with |
| 17 |
a *known* signature signing a critical part of the chain, ensuring |
| 18 |
referential integrity of |
| 19 |
the chain of custody. |
| 20 |
|
| 21 |
That, imo, results in us discarding this argument, and folding back to |
| 22 |
the "what are the benefits of rebasing/merging on their own merits |
| 23 |
again?" , of which, there are many, even in the absence of signing. |
| 24 |
|
| 25 |
> if we just want committer signature, then I don't really see the |
| 26 |
> point in signing: it isnt more secure than pecker access + ldap |
| 27 |
> password, and infra could simply sign public git trees with a unique |
| 28 |
> gentoo key |
| 29 |
|
| 30 |
There's an added security measure that exists /outside/ the gentoo |
| 31 |
source control. |
| 32 |
|
| 33 |
It means that you can still ascertain some degree of "authority" |
| 34 |
without having to rely on gentoo's centralised control system. |
| 35 |
|
| 36 |
For instance, that Perl branch in the overlay that was pending, you |
| 37 |
can still validate who created it, and how, and who last touched each |
| 38 |
and every commit, |
| 39 |
despite the fact its not yet anywhere near gentoo infrastructure. |
| 40 |
|
| 41 |
And being able to *independently* verify an arbitrary git commit was |
| 42 |
created by the person who claims to have created it, is a good thing. |
| 43 |
|
| 44 |
And that *independent* data can be used as a selection criteria by |
| 45 |
maintainers pulling commits into gentoo. |
| 46 |
|
| 47 |
But that said, none of this really reflects on wether we should use |
| 48 |
merges or rebases. |
| 49 |
|
| 50 |
Those situations are primarily driven by the nature of the work |
| 51 |
itself, not our meta-level security concerns. |
| 52 |
|
| 53 |
|
| 54 |
|
| 55 |
-- |
| 56 |
Kent |
| 57 |
|
| 58 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives