| 1 |
On Wed, May 11, 2016 at 10:34 AM, Kent Fredric <kentfredric@×××××.com> wrote: |
| 2 |
> |
| 3 |
> There's an added security measure that exists /outside/ the gentoo |
| 4 |
> source control. |
| 5 |
> |
| 6 |
|
| 7 |
It also fails differently. |
| 8 |
|
| 9 |
If I find out that somebody compromised ssh in some way, doubt is cast |
| 10 |
on any commit during the period in which the ssh server was |
| 11 |
vulnerable, and that could go back quite a ways. |
| 12 |
|
| 13 |
If I find out that somebody's gpg key was compromised, then at most |
| 14 |
that one developer's commits are tainted. |
| 15 |
|
| 16 |
Obviously an ssh breach could be limited to a single account as well, |
| 17 |
but it has a server-wide component for which a parallel in git doesn't |
| 18 |
really exist. |
| 19 |
|
| 20 |
In any case, nobody has proposed getting rid of the requirement that a |
| 21 |
known key be used to sign all direct commits to the tree. That direct |
| 22 |
commit could have a parent that is not signed with a key known to |
| 23 |
Gentoo. |
| 24 |
|
| 25 |
My sense is that most here would agree that most of our routine |
| 26 |
commits should just be rebased, but merge commits have a legitimate |
| 27 |
place, and it wouldn't hurt to better document what we consider best |
| 28 |
practices (which seem to include rebasing merge commits when |
| 29 |
practical). I suspect that improvement is ultimately going to come |
| 30 |
down to volunteer interest in creating that documentation, as with |
| 31 |
much of the rest of our workflow. |
| 32 |
|
| 33 |
-- |
| 34 |
Rich |
Archives