[gentoo-dev] Git braindump: 1 of N: merging & git signing

[gentoo-dev] Git braindump: 1 of N: merging & git signing

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 4497 bytes --]

This is one of several braindumps I've got, getting what are potentially
very important details about the Git stuff out of my head, so that it
doesn't matter if I become hit by a bus. Apologies if this mail seems a bit
scrambled, per -core, my brain is rather scrambled lately.

TL;DR:
------
I propose:
- merges are explicitly allowed, even non-fast-forwards
- all commits MUST be signed
- if you include a commit from a user:
  author := non-@gentoo
  committer := @gentoo
  signer := $committer

Merging:
--------
The thread I started about allowing merges, I want to explain a bit of
history behind it, because it came about as a result of a change in HOW Git
upstream is doing signatures for now.

There are two things to record:
1. who really made a commit
2. who pushed the commit to the repo

They don't need to be the same person.
- Signed commits will prove #1
- Signed pushes will prove #2

Git upstream will ultimately support BOTH forms of signature, but for now, only
signed commits are available.

Good page covering Git signatures, if you don't want to read the rest of my
description below, but this page is much longer, and covers some of the related
features and checking in much more detail:
http://mikegerwitz.com/docs/git-horror-story.html

Git signed pushes:
------------------
We were originally looking for a model of signing the actual push
action, and having that recorded in Git. This was important as it
allowed the author/committer/pusher to differ, while still being
securely recorded (the signature was on the actual push action, as a
certification). This is what we had at length discussions with the Git
upstream about this:
http://git.661346.n2.nabble.com/Signed-push-progress-td6839255.html.

Git signed commits:
-------------------
Signed pushed were delayed in favour of more immediate work on allowing
the direct signature of the contents of a commit. These had the direct
advantage of always being included in the Git data directly.
They were built to stack cleanly on top of the fact that the existing
git repo objects were based on SHA1 hashes of other objects (see
http://eagain.net/articles/git-for-computer-scientists/
for the DAG of a commit).

Format of the signed Git commit 
-------------------------------
If you look at the output of:
git cat-file commit $commitid
You'll see this output like this:
===
tree ee314a31b622b027c10981acaed7903a3607dbd4
parent 7edca69c39a58b9d08d7145cdfa797ec27049e78
author Robin H. Johnson <robbat2@gentoo.org> 1338710866 +0000
committer Robin H. Johnson <robbat2@gentoo.org> 1338710866 +0000

commit message goes here.
===

That's the COMPLETE commit object.

It is also EXACTLY what gets signed.

If you look the above output (exact same command), for a signed commit:
=====
tree 8a6685fdf45e426a0bce32ac18aa21da9aa8a60e
parent f203a90b7ee239f8cf4df652d94120798c68f7e5
author Robin H. Johnson <robbat2@gentoo.org> 1338710330 +0000
committer Robin H. Johnson <robbat2@gentoo.org> 1338710330 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iQIcBAABAgAGBQJPyxk6AAoJEK5yKHg3xZ9fgJAP/0mEzW0K+GKNPpaDbS+PtI8T
 QSVNEK0nA5PSf7F/iNjPm3YlUjovndo4LHpd8+0CRAy9HtCWMUpeXRWK7TKimwWJ
 4x5jsnMH6ktawsFNvNjGfuLKi+eqJJtv3J0n7KwqsCeGP5FtBZIEhRnJ2BDDQF7L
 mZvdSHZlqVAkzXyAWgt+7uiZcR9LvT+xuziDVHVhZZqWDWEvPLXVkphwChvqIbA9
 u8kQgxawcl5p8WXUzknqUaMOf2L4eXryyTpMoXSbOSxS8Z7OADG6YV/phDD5EjV0
 03bOCJzeDfV03rJWlkZa11Kjj1ni47KgROtA6ywdXGZswtgAbLNvg/c2icDJLAm6
 TmuhJ0qw2FWsIllnEKfwegYtT5ei/YJhxnlVQ20JuEyhLbMun4t1Y01OOsub5DU1
 vilAsItpY+1mXzhC92/16GwqHgjGstAwL5GmGz2lGBSvPc356DtGcRF4TSfs2iMH
 WkZytJGSYPOu5Nm3a3ws1Ific3Cwhv1sOD0PEP0PboQ4bLmWk0l+Ivw52d6J0GBL
 +uzhe1rGhEQfkirWNKUPsmnfyJu4DzEjdQOeQsLLjdlc+EytqCr2cBB+AAXq0EXI
 Rq5Fp5GkPap5H9CFJdDoc6Caq6SRcze8l9w1PZ5OutygkyfU3GzRQ7GiWVXMFm9M
 PgZnISs7Hcp00n4yeMJR
 =BR/z
 -----END PGP SIGNATURE-----

.
=====

You can trivially remove the gpgsig header (the indented lines are continuations, up until the \n\n).

If you want to verify a commit, you can do:
# git show --show-signature $commitid

Or you can use cat-file, move gpgsig header to a seperate file, removing leading whitespace and the gpgsig bit, and run this yourself:
# gpg --verify commit.sig commit.no-gpgsig

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 330 bytes --]

[gentoo-dev] Re: Git braindump: 1 of N: merging & git signing

[Duncan]

Robin H. Johnson posted on Sun, 03 Jun 2012 08:18:24 +0000 as excerpted:

> This is one of several braindumps I've got, getting what are potentially
> very important details about the Git stuff out of my head, so that it
> doesn't matter if I become hit by a bus.

Thanks.  Along with the bus factor, that clarifies things and helps get 
people at least discussing the same thing.  Looking forward to more in 
the series! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06/03/2012 09:18 AM, Robin H. Johnson wrote:
> This is one of several braindumps I've got, getting what are
> potentially very important details about the Git stuff out of my
> head, so that it doesn't matter if I become hit by a bus. Apologies
> if this mail seems a bit scrambled, per -core, my brain is rather
> scrambled lately.
> 
> TL;DR: ------ I propose: - merges are explicitly allowed, even
> non-fast-forwards - all commits MUST be signed - if you include a
> commit from a user: author := non-@gentoo committer := @gentoo 
> signer := $committer
> 
What you said makes perfectly sense to me. We are a big project with a
high commit rate so forcing everyone to rebase (especially non-dev
people) their patches would be too much pain. I don't believe linear
history is critical in our case.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPyzpKAAoJEPqDWhW0r/LCX9kP/iesS2Gcxw189eifXuH/OH1o
f5YzpUi1lKpg8mqVZ/oVDv+LKIfeC7FiWoZTZRIa/yUOcFkjl5DIlzFxF3PASmfF
3DlJsk3btCP6I8BeZx9pMRVmtjO7n0H9w3Locf0f8THQfvl8ZwEOS7gtGTkrBWIs
uXYPO2Je59QW4uP0TAWWQQCXBd2Job9j+0T43z60+uIPOopl28UwffdInvSmh7+K
WZIPomtsd/JNZzBQcO+KRqCgDeLTlGFe4SnNJX571fWwmGUr/334QcOtRn+VgemH
9rwJtdAiXI16y3uoIa4ztMuN1/vG+NCZbuHwzYzNV5t8T14n1hVHMqnbPj8tPDk6
WiboF+YCP9mSOYBsJqh9XPPso1BhhXeGZ7V30tQxjCAAlEso2lUcYgRSWexifSvi
3u9ofaavtt0wbANaVghNAKK5b6AXGKey1alsKJB5Uvhqq1JIKbFt1DinrYUgBgMS
v/tSq4pL4iEYA3p3dYUwt1Db+/o1dCSwc2itZFgluTQXa3t6c5E2vsgMP/t/QnJY
6IMzPdXoraG5XeZT0FavzBjDSIgvPxFNs/bYdvTaQwxzZTxT0N30ZjEJreVpz81g
rfzmSDyuzo8rgzGK5AVKx8aNlaebja2QhO7uCuVvjoPpmnF2PAnfQ8fsybl3T8bq
3+g6gNF2loBFLA9Jczgy
=/o+N
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1158 bytes --]

Am Sonntag 03 Juni 2012, 10:18:24 schrieb Robin H. Johnson:
> I propose:
> - merges are explicitly allowed, even non-fast-forwards
> - all commits MUST be signed
> - if you include a commit from a user:
>   author := non-@gentoo
>   committer := @gentoo
>   signer := $committer
> 

Sounds reasonable given the current state of git. Let's just be clear about 
the following consequence (I hope I understand this correctly):

* User makes signed improvements in gentoo-x86 clone
* Developer pulls from user and >merges<
* Developer's history contains commits by user, which cannot be pushed to 
gentoo-x86

Which means in the end "all merges are explicitly allowed, as long as they 
only contain developer commits; commits pulled from users must be rebased".

This is something that (IMHO) we could certainly live with; the only thing I 
am worried about is, how do we automatize it so a developer who is not end-of-
the-line git guru and ends up with some user-signed commits in his history can 
clean up his local tree again.


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Sounds reasonable given the current state of git. Let's just be clear about
> the following consequence (I hope I understand this correctly):
>
> * User makes signed improvements in gentoo-x86 clone
> * Developer pulls from user and >merges<
> * Developer's history contains commits by user, which cannot be pushed to
> gentoo-x86
>
> Which means in the end "all merges are explicitly allowed, as long as they
> only contain developer commits; commits pulled from users must be rebased".

I don't think so. IMO pushing commits by a user should be a fine, as
long as they're merged in a non-fast-forward, signed merge commit.

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1344 bytes --]

Am Sonntag 03 Juni 2012, 18:01:04 schrieb Dirkjan Ochtman:
> On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel
> 
> <dilfridge@gentoo.org> wrote:
> > Sounds reasonable given the current state of git. Let's just be clear
> > about the following consequence (I hope I understand this correctly):
> > 
> > * User makes signed improvements in gentoo-x86 clone
> > * Developer pulls from user and >merges<
> > * Developer's history contains commits by user, which cannot be pushed to
> > gentoo-x86
> > 
> > Which means in the end "all merges are explicitly allowed, as long as
> > they only contain developer commits; commits pulled from users must be
> > rebased".
> 
> I don't think so. IMO pushing commits by a user should be a fine, as
> long as they're merged in a non-fast-forward, signed merge commit.

Can probably be done, but this must be finetuned in whatever script enforces 
the rule upon push to the developer. 

However, then the "committer" of the contributed commits before the merge is 
then the user, I guess?

(The rule meaning as suggested by Robin
> - if you include a commit from a user:
>   author := non-@gentoo
>   committer := @gentoo
>   signer := $committer 
)

Cheers, 
Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> However, then the "committer" of the contributed commits before the merge is
> then the user, I guess?
>
> (The rule meaning as suggested by Robin
>> - if you include a commit from a user:
>>   author := non-@gentoo
>>   committer := @gentoo
>>   signer := $committer

I guess, I'm not sure how the committer thing works in git.

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>> However, then the "committer" of the contributed commits before the merge is
>> then the user, I guess?
>>
>> (The rule meaning as suggested by Robin
>>> - if you include a commit from a user:
>>>   author := non-@gentoo
>>>   committer := @gentoo
>>>   signer := $committer
>
> I guess, I'm not sure how the committer thing works in git.
>

Well, only Robin can explain exactly what he meant, but it sounds like
we don't want the committer field to ever have a non-gentoo email in
it, and signatures should be gentoo as well.  So, if a dev just
applies a patch to their tree/etc then there is no issue (just set
author).  If a dev wants to actually pull in a commit they'd need to
edit the fields accordingly and re-sign it.  Not sure offhand how to
best do that (I assume it is possible - probably with some variation
on rebase or something rebase calls).

I don't think the intent is to snub non-devs.  The issue is what is
the purpose of the signatures and committers field in the first place.
 The signature verifies that the commit is intact, and you can only do
that if you have a key to check it with, and you can trust that key.
If the signer is a dev then we already have policy that the keys need
to be published, and we have a list of key IDs on our website.  I'm
sure that could be improved on.  If we stick non-dev signatures in the
tree then that becomes more of a problem (though it clearly is
possible - maybe something to think about).  I assume the committer
denotes a layer of accountability, and having a dev in that spot makes
sense (devs who are proxies are accountable for oversight at some
level - though I'd personally give them the benefit of the doubt since
we want to encourage the proxy role).

I think the key with git is to not let the perfect be the enemy of the
good.  We don't have an unbroken signature chain on our current
portage tree, so I don't think we need one to move to git.  As long as
git is at least as good as what we have now, then we should accept it.
 We should of course strive to improve, but let's not keep the almost
completely unsigned cvs around for another 10 years while we argue
about signatures.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 2:34 PM, Rich Freeman <rich0@gentoo.org> wrote:
> Well, only Robin can explain exactly what he meant, but it sounds like
> we don't want the committer field to ever have a non-gentoo email in
> it, and signatures should be gentoo as well.  So, if a dev just
> applies a patch to their tree/etc then there is no issue (just set
> author).  If a dev wants to actually pull in a commit they'd need to
> edit the fields accordingly and re-sign it.  Not sure offhand how to
> best do that (I assume it is possible - probably with some variation
> on rebase or something rebase calls).

Well, it doesn't seem like a big deal IF there's an explicit merge
commit that's signed by a dev.

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 8:45 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>
> Well, it doesn't seem like a big deal IF there's an explicit merge
> commit that's signed by a dev.

I'm not sure about that.  If you were verifying a tree, how would you
identify which commits were merged in by what dev, using an automated
algorithm?

The only thing the merge commit contains is a list of two parents, and
a tree.  It doesn't say which one is which, unless we can rely on
their order.  Now, all those intermediate commits were never actually
published via rsync, so their integrity isn't a direct issue.
However, I'm not sure how easy automated verification would be.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 3:40 PM, Rich Freeman <rich0@gentoo.org> wrote:
> The only thing the merge commit contains is a list of two parents, and
> a tree.  It doesn't say which one is which, unless we can rely on
> their order.

You simply walk the tree from root to tip. When you encounter an
unsigned changeset, the nearest signed descendant is responsible for
merging that changeset.

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

On 06/04/2012 07:34 AM, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>>> However, then the "committer" of the contributed commits before the merge is
>>> then the user, I guess?
>>>
>>> (The rule meaning as suggested by Robin
>>>> - if you include a commit from a user:
>>>>   author := non-@gentoo
>>>>   committer := @gentoo
>>>>   signer := $committer
>>
>> I guess, I'm not sure how the committer thing works in git.
>>
> 
> Well, only Robin can explain exactly what he meant, but it sounds like
> we don't want the committer field to ever have a non-gentoo email in
> it, and signatures should be gentoo as well.  So, if a dev just
> applies a patch to their tree/etc then there is no issue (just set
> author).  If a dev wants to actually pull in a commit they'd need to
> edit the fields accordingly and re-sign it.  Not sure offhand how to
> best do that (I assume it is possible - probably with some variation
> on rebase or something rebase calls).
> 
> I don't think the intent is to snub non-devs.  The issue is what is
> the purpose of the signatures and committers field in the first place.
>  The signature verifies that the commit is intact, and you can only do
> that if you have a key to check it with, and you can trust that key.
> If the signer is a dev then we already have policy that the keys need
> to be published, and we have a list of key IDs on our website.  I'm
> sure that could be improved on.  If we stick non-dev signatures in the
> tree then that becomes more of a problem (though it clearly is
> possible - maybe something to think about).  I assume the committer
> denotes a layer of accountability, and having a dev in that spot makes
> sense (devs who are proxies are accountable for oversight at some
> level - though I'd personally give them the benefit of the doubt since
> we want to encourage the proxy role).
> 
> I think the key with git is to not let the perfect be the enemy of the
> good.  We don't have an unbroken signature chain on our current
> portage tree, so I don't think we need one to move to git.  As long as
> git is at least as good as what we have now, then we should accept it.
>  We should of course strive to improve, but let's not keep the almost
> completely unsigned cvs around for another 10 years while we argue
> about signatures.
> 
> Rich
> 
I think the intent is to only have commits and signoffs come from
@gentoo, but we need a way to give attribution to users who send stuff
in that gets committed.

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 9:48 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>
> You simply walk the tree from root to tip. When you encounter an
> unsigned changeset, the nearest signed descendant is responsible for
> merging that changeset.
>

How do you KNOW that the nearest signed descendant actually merged it?

How do you know it wasn't added by a hacker?

Also, when walking the tree keep in mind that there isn't just one
path in it (with merge commits), and the links are from any particular
HEAD going back.  I'm not convinced that this is impossible, but it
isn't as trivial as it might seem at first glance.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman <rich0@gentoo.org> wrote:
> How do you KNOW that the nearest signed descendant actually merged it?
>
> How do you know it wasn't added by a hacker?

Because then the signature for the nearest signed descendant wouldn't
check out (unless it got hacked before he signed it, of course, but in
that case hopefully he wouldn't sign it...).

> Also, when walking the tree keep in mind that there isn't just one
> path in it (with merge commits), and the links are from any particular
> HEAD going back.  I'm not convinced that this is impossible, but it
> isn't as trivial as it might seem at first glance.

Well, this only means there might potentially be multiple nearest
signed descendants, but I don't think that's a problem. Feel free to
shoot holes in it, but I think this checks out.

Of course, we'd have to make sure the tip of whatever is pushed is
always signed, but the hook for that should be trivial.

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 10:26 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> How do you KNOW that the nearest signed descendant actually merged it?
>>
>> How do you know it wasn't added by a hacker?
>
> Because then the signature for the nearest signed descendant wouldn't
> check out (unless it got hacked before he signed it, of course, but in
> that case hopefully he wouldn't sign it...).

When I do a cvs commit, I don't check the logs to make sure the last
25 commits all look valid.  So, why would I expect others to do any
differently in git.  I make my changes, I run a git pull (bringing in
the hacked commit on gentoo-x86 master), and then merge/rebase in my
changes, signing my commit (which indicates that what _I_ just
commited is good, not that everything before is good).  I am not the
one commiting in hacked files - they were there before I got there.

>
> Of course, we'd have to make sure the tip of whatever is pushed is
> always signed, but the hook for that should be trivial.

Yup, but the hacker wouldn't run the hook.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 4:48 PM, Rich Freeman <rich0@gentoo.org> wrote:
> When I do a cvs commit, I don't check the logs to make sure the last
> 25 commits all look valid.  So, why would I expect others to do any
> differently in git.  I make my changes, I run a git pull (bringing in
> the hacked commit on gentoo-x86 master), and then merge/rebase in my
> changes, signing my commit (which indicates that what _I_ just
> commited is good, not that everything before is good).  I am not the
> one commiting in hacked files - they were there before I got there.

If the tree was bad before you pushed, then it's not your fault the
tree is bad. You're only responsible for the commits you bring into
the tree, so if you're merging contributor's unsigned changesets, you
merge them with a signature of your own.

>> Of course, we'd have to make sure the tip of whatever is pushed is
>> always signed, but the hook for that should be trivial.
>
> Yup, but the hacker wouldn't run the hook.

If the hacker has unfettered access to the server where the repository
lives, we probably have bigger problems, as they can get whatever
rsynced to all our users. I guess we could have rsync process check
that the cset it's about to push out to mirrors is signed?

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 11:02 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> If the tree was bad before you pushed, then it's not your fault the
> tree is bad. You're only responsible for the commits you bring into
> the tree, so if you're merging contributor's unsigned changesets, you
> merge them with a signature of your own.

Yup, but the fact that the tree is bad is still a problem, even if it
isn't my fault.

> If the hacker has unfettered access to the server where the repository
> lives, we probably have bigger problems, as they can get whatever
> rsynced to all our users. I guess we could have rsync process check
> that the cset it's about to push out to mirrors is signed?

So, the whole point of signing is that it lets you prove that the
repository is uncompromised.  If we're going to assume that the server
is secure, then we don't need signatures - whatever is on the server
is by definition correct.

A robust security infrastructure is already spelled out in a GLEP
(though that one is dated).  Ideally it should be verifiable from end
to end, so that when you run emerge if a package has been tampered
with it will just refuse to install it.  Since we don't distribute the
whole git repository the git commits only get us part of the way
there.  However, if every step of the distribution assumes that the
previous step could have been compromised that would be a good start.

Again, we don't need to be there 100% to go live.  However, I think
that was the whole point of signing commits.  If we aren't going to
add any assurance at all with our signing practices, then there isn't
much point in having them.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 6:06 PM, Rich Freeman <rich0@gentoo.org> wrote:
> Again, we don't need to be there 100% to go live.  However, I think
> that was the whole point of signing commits.  If we aren't going to
> add any assurance at all with our signing practices, then there isn't
> much point in having them.

True. However, I still think my idea of security (the tip of tree must
always be signed by a gentoo.org committer) and your idea of security
(every cset must be signed by a gentoo.org committer) give similar
security guarantees in the end. Any user will rely on the last
committer to have faithfully signed for an uncompromised tree. Any
committer will rely on the previous committer to have faithfully
signed for an uncompromised tree. So to prevent your scenario, we'd
have to get everyone to check the signature of the tip of tree they
pulled before committing/merging. Having every cset signed is
something that might make verification slightly easier, but having all
previous tips signed (i.e. merges) should be sufficient (if we can
rely on committers to review changesets from other committers they
pull from).

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 12:19 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> So to prevent your scenario, we'd
> have to get everyone to check the signature of the tip of tree they
> pulled before committing/merging.

How can we be sure this has happened?

This is the problem with signed manifests today.  I can sign a
manifest, but I didn't actually check all the files inside it, and the
file might or might not have been signed before I modified it, and
most likely I didn't even check the signature even if it was there.

Anything we do has to be automated to be of any real value.  Ideally
if something goes wrong it should be as detectable as possible.

Warts and all the current system hasn't broken down yet.  However, if
we ever did find out about an intrusion in our cvs repository, we'd
essentially have to do a 100% code review to be sure it was OK, and
that includes checking all tarballs on mirrors.

With signed commits we could verify that the tree was intact, and if
anything bad was found we could pinpoint exactly whose key was
compromised and do a focused check on their commits.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman <rich0@gentoo.org> wrote:
> Anything we do has to be automated to be of any real value.  Ideally
> if something goes wrong it should be as detectable as possible.

Yeah, but you'd have to part of that at every developer's box.

Can we just agree that having the tip of the main tree always signed
will be enough for now, and postpone the rest of the discussion until
later?

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Brian Harring]

On Mon, Jun 04, 2012 at 08:45:42PM +0200, Dirkjan Ochtman wrote:
> On Mon, Jun 4, 2012 at 7:25 PM, Rich Freeman <rich0@gentoo.org> wrote:
> > Anything we do has to be automated to be of any real value. ??Ideally
> > if something goes wrong it should be as detectable as possible.
> 
> Yeah, but you'd have to part of that at every developer's box.
> 
> Can we just agree that having the tip of the main tree always signed
> will be enough for now, and postpone the rest of the discussion until
> later?

ToT is always going to be signed.  If it *isn't* signed, either the 
infra machinery is broken and not rejecting commits that it should 
reject, or someone is trojaning the repo (either via an infra 
compromise, local compromise, or via man in the middle).

One thing people need to keep in mind here is that when you sign the 
commit, you're signing off on the history implicitly.  Directly 
addressing freeman's comment about "people sign the manifest but don't 
look at what they're signing", when it comes to git signage, bluntly, 
people doing that shouldn't have access- if they can't be arsed to 
validate what they're signing, then trusting them w/ the tree is 
probably questionable.

Harsh, but frankly, sane people don't sign enforcable contracts w/out 
verifying what they're signing (note the 'enforcable' bit, stated to 
head off the EULA rathole discussion); this isn't any different 
frankly.

~harring

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring <ferringb@gmail.com> wrote:
> One thing people need to keep in mind here is that when you sign the
> commit, you're signing off on the history implicitly.  Directly
> addressing freeman's comment about "people sign the manifest but don't
> look at what they're signing", when it comes to git signage, bluntly,
> people doing that shouldn't have access- if they can't be arsed to
> validate what they're signing, then trusting them w/ the tree is
> probably questionable.

I suspect that you're missing my point.  The argument was made that as
long as merge commits are signed you know that unsigned commits
referenced by them are OK.  However, some of those commits might have
been already in gentoo-x86 and I doubt that anybody is going to check
those.  If I have a perfect commit, I do a git pull and a git push and
the result is a merge that references whatever was in gentoo-x86
before, whether placed there by dev, or hacker, or whatever.  Unless I
go back and review the existing gentoo-x86 history (and likely have to
repeat the process when somebody else does a push before I do), I
can't vouch for what was in there already - just what I'm adding.

The reason I mentioned maifests is that they have the same issue.  If
I keyword an arch on foo-1.4.5, I sign the manifest.  That doesn't
mean that I checked every file in the package's directory tree for
issues.  At most I checked foo-1.4.5, but I can't sign off on just
1.4.5 - I have to sign off on everything.  Also, when I sign off on
1.4.5, I'm really just signing off for the keyword change, not the
piece of buggy code I didn't write on line 37 of the ebuild.

Of course when merging a pile of commits into the tree you should
check all of them to make sure they're fine (or rather that the end
result of them is fine - no absolute need to squash together bug
introductions and fixes even if that is nicer).  However, I'm not sure
I'd extend that to checking commits ALREADY in gentoo-x86 made by some
other dev.

The general principle is that if you change something in the tree, you
should be responsible for what you changed, and that makes sense.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Brian Harring]

On Mon, Jun 04, 2012 at 03:27:03PM -0400, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring <ferringb@gmail.com> wrote:
> > One thing people need to keep in mind here is that when you sign the
> > commit, you're signing off on the history implicitly. ?Directly
> > addressing freeman's comment about "people sign the manifest but don't
> > look at what they're signing", when it comes to git signage, bluntly,
> > people doing that shouldn't have access- if they can't be arsed to
> > validate what they're signing, then trusting them w/ the tree is
> > probably questionable.
> 
> I suspect that you're missing my point.  The argument was made that as
> long as merge commits are signed you know that unsigned commits
> referenced by them are OK.  However, some of those commits might have
> been already in gentoo-x86 and I doubt that anybody is going to check
> those.

Going over the details on the offchance you're misunderstanding part 
of it:

A signed commit is a signing of the git metadata; tree hash 
(literally, the state of the tree), committer, author, message, and 
parent sha1.  Each git commit includes it's parent sha1 in it; this 
gives a locked history for a given commit sha1 (unless someone 
preimages sha1).  What matters is that the leaf node, the final point 
in the graph, is signed- that's a dev sign off on effectively that 
they created that particular locked history.  Realistically signing of 
each node is preferable, but the leaf is the minimal required.

The dev, prior to signing that, should be verifying what they're 
adding (moreso, what exists between last signed rev and theirs), they 
agree to and know of.  Specifically, they're asserting their addition.

When the dev resync's, part of the process *should* be validating that 
the new remote ToT is actually signed by a trusted key; aka, another 
dev.  For merge commits, the same applies here- due to the rather 
nice sha1 hack of git, signing the merge commit has the same angle, 
the dev signs off on the new addition effectively (for merge commits, 
moreso that the resultant integration is what they intended).

Now to pick at your statement; "the dev is signing off on commits 
already in x86"; think through this scheme; each dev signs off as they 
go on their specific changes, validating backwards is doable- meaning 
you can validate that all commits in the vcs were signed off by 
trusted folk (ie, dev's).  Your argument is either based on 
misunderstanding how this works (potentially just ignoring the pull 
validation devs have to do), or assuming that the dev is responsible 
for signing off on *everything* in the tree's proceeding history just 
because they're signing a specific history/tree sha.  As indicated 
above, they're signing off essentially on each gap between signing, 
the delta.


> If I have a perfect commit, I do a git pull and a git push and
> the result is a merge that references whatever was in gentoo-x86
> before, whether placed there by dev, or hacker, or whatever.  Unless I
> go back and review the existing gentoo-x86 history (and likely have to
> repeat the process when somebody else does a push before I do), I
> can't vouch for what was in there already - just what I'm adding.

For someone to inject something into the history requires basically a 
sha1 preimage attack, or the dev to be hit by an injection attack, 
along w/ the dev *skipping* validation of the pull to current ToT.

If we require every commit to be signed, that blocks the potential for 
a careless dev skipping the valdation to sign off on things that were 
injected.  This is a bit honerous, and is why signed pushes were the 
preference (and is a bit of an abuse what we're doing now).


> The reason I mentioned maifests is that they have the same issue.  If
> I keyword an arch on foo-1.4.5, I sign the manifest.  That doesn't
> mean that I checked every file in the package's directory tree for
> issues.  At most I checked foo-1.4.5, but I can't sign off on just
> 1.4.5 - I have to sign off on everything.  Also, when I sign off on
> 1.4.5, I'm really just signing off for the keyword change, not the
> piece of buggy code I didn't write on line 37 of the ebuild.

Manifests aren't particularly comparable, nor is it worth trying to do 
so.  Technically w/ CVS manifests you can isolate down just the delta, 
and infer that the signage was for that, but the tools don't 
particularly exist for it, nor is it worth it; cvs just isn't designed 
sanely to allow for this.

With git however, since the signing can be integrated directly into 
the revs themselves, you *are* directly signing the deltas; as said, 
w/ cvs technically you are (even if you're signing all of the 
results).

An additional note btw; to be clear, the only manifest file that 
exists in a git tree is a thin manifest holding checksums for the 
distilfes involved.

If you're thinking of rsync distributed trees (which aren't thin 
manifests), the plan was to enhance the existing rsync snapshot 
generation scripts so that they do validation of the history 
(comparing against the dev keyring), and generate signed manifests 
for rsync distribution.  Any failure in validation == no update to the 
snapshot.

If that doesn't answer your question/concerns, be more explicit 
please.
~harring

Re: Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

> A signed commit is a signing of the git metadata; tree hash
> (literally, the state of the tree), committer, author, message, and
> parent sha1.  Each git commit includes it's parent sha1 in it; this
> gives a locked history for a given commit sha1 (unless someone
> preimages sha1).  What matters is that the leaf node, the final point
> in the graph, is signed- that's a dev sign off on effectively that
> they created that particular locked history.  Realistically signing of
> each node is preferable, but the leaf is the minimal required.

No. What is signed is the "new data" plus the parent hash(es).

No such thing as a "tree hash".

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Mon, Jun 4, 2012 at 4:41 PM, Brian Harring <ferringb@gmail.com> wrote:
>
> If that doesn't answer your question/concerns, be more explicit
> please.

How about a scenario:

1.  Gentoo dev commits a bunch of stuff to the tree.  Top of tree is signed.
2.  Hacker commits something to the tree.  Top of tree is not signed.
No need for preimage attacks or whatever on sha1 - they just log into
the server and do a git commit or whatever right into the tree.
3.  Gentoo dev commits a bunch of stuff to the tree.  Top of tree is signed.
4.  Rsync mirror update happens - top of tree is signed, so update
proceeds normally.

If you go back and look at the tree you see a bunch of signed and
unsigned commits.  How do you easily detect how the unsigned ones got
there (via a dev with a merge commit, or via other means)?  Either way
they'll be parents of merge commits - since merge commits have two
parents - the pre-commit gentoo-x86 tree, and the incoming commits.

Andreas - I'm pretty sure a merge commit still includes a tree.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

On Mon, 04 Jun 2012 22:52:25 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> No. What is signed is the "new data" plus the parent hash(es).
> 
> No such thing as a "tree hash".

http://eagain.net/articles/git-for-computer-scientists/

Might clear things up a bit.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 10:41 PM, Brian Harring <ferringb@gmail.com> wrote:
> The dev, prior to signing that, should be verifying what they're
> adding (moreso, what exists between last signed rev and theirs), they
> agree to and know of.  Specifically, they're asserting their addition.

What Rich is arguing (and which I think makes some sense) is that
people will probably not be inclined to verify the signature of the
tree they just pulled from gentoo-x86. We can't really force them too,
since it happens on their own machine.

Still, I think we should drop this discussion for now.

Cheers,

Dirkjan

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

On Mon, 4 Jun 2012 16:57:42 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> If you go back and look at the tree you see a bunch of signed and
> unsigned commits.  How do you easily detect how the unsigned ones got
> there (via a dev with a merge commit, or via other means)?

Well, that's not a very good solution but the server-side hooks could
also verify the tree state before applying new commits.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Tue, Jun 5, 2012 at 2:50 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Mon, 4 Jun 2012 16:57:42 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> If you go back and look at the tree you see a bunch of signed and
>> unsigned commits.  How do you easily detect how the unsigned ones got
>> there (via a dev with a merge commit, or via other means)?
>
> Well, that's not a very good solution but the server-side hooks could
> also verify the tree state before applying new commits.

The obvious problem with this is that it makes the git server a single
point of failure - if it is compromised the hooks will not help.
Hooks should nevertheless be there to eliminate mistakes.

Note that in no way are any of these git flaws any worse than the
status quo.  I just want to avoid any false sense of security.  I
think these are flaws that are worth fixing, and I think that was why
many have labored to get the signing enabled in git in the first
place.

My suggestion is to keep working on this, but it shouldn't be
considered a blocker for adoption, since these are not new security
flaws, and if anything despite its holes git is an improvement.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

On Mon, Jun 04, 2012 at 04:57:42PM -0400, Rich Freeman wrote:
> 2.  Hacker commits something to the tree.  Top of tree is not signed.
> No need for preimage attacks or whatever on sha1 - they just log into
> the server and do a git commit or whatever right into the tree.
> 3.  Gentoo dev commits a bunch of stuff to the tree.  Top of tree is signed.

When the breach is discovered, you can then isolate the dev (or devs)
who implicitly signed the hack (2) by pulling the ToT without checking
for a valid signature (3).  Then you yell at them for sloppy security,
and tell them to install your signature-checking post-receive hook.

Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Rich Freeman]

On Fri, Jun 8, 2012 at 7:01 AM, W. Trevor King <wking@tremily.us> wrote:
> When the breach is discovered, you can then isolate the dev (or devs)
> who implicitly signed the hack (2) by pulling the ToT without checking
> for a valid signature (3).  Then you yell at them for sloppy security,
> and tell them to install your signature-checking post-receive hook.

Well, if devs are supposed to do this, we should probably write this
down as a policy somewhere.  Probably wouldn't hurt if the
post-receive hook actually existed, and it was designed to only work
on the official tree otherwise everybody will just uninstall it since
people don't just pull from the official tree.

I doubt any dev checks the signatures on manifest files before they
overwrite them with a new signature.  If they did it wouldn't matter
since those signatures aren't even mandatory anyway.  Certainly it
isn't intuitive to me that when I perform a signature on changes I
make that I'm also vouching for work committed by somebody else before
me.

Process can be as effective as technology in achieving security, but
only if those processes are clear, and unintrusive enough to ensure
they are followed.  I wouldn't count on being able to yell at
developers - first it does nothing to solve the mess that you'd be in
at that point, and second you can only yell at volunteers so much.

Rich

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/08/2012 01:36 PM, Rich Freeman wrote:

> I doubt any dev checks the signatures on manifest files before
> they overwrite them with a new signature.  If they did it wouldn't
> matter since those signatures aren't even mandatory anyway.
> Certainly it isn't intuitive to me that when I perform a signature
> on changes I make that I'm also vouching for work committed by
> somebody else before me.

I'm trying to do this,

but first we need an keyring with all dev gpg keys - securely
distributed - to verify the signatures.

We (amost all) have gentoogpg key-ids in ldap, most have fingerprints
in gentoofingerprint in ldap, but we have to download these keys from
public keyservers. And its not mandatory to either sign at all or sign
with keys mentioned in ldap.

Someone pointed me on tove's list of gpg keys used for signing [1].

I'd suggest to generate an tarball (containing an keyring) to sign by
an master key (member of trustee/council/..) to be deployed on all
systems (like it's done on archlinux and debian).

But the current vulnerability is exporting/importhing these keys to
pgp.mit.edu et al.

Suggestions?

   Michael

[1] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/keys_in_use.txt

- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/SAOkACgkQknrdDGLu8JBWywD/e4kT9jUt3CFFMZgMla14zdwT
dmZZs4R5to9CikKAFqwA/1dcXV9/8H/qrW0q8yO7pEIdCdr8RD2d0mochceEeyxd
=+k9D
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

On Fri, Jun 08, 2012 at 03:40:57PM +0200, Michael Weber wrote:
> I'd suggest to generate an tarball (containing an keyring) to sign by
> an master key (member of trustee/council/..) to be deployed on all
> systems (like it's done on archlinux and debian).
> 
> But the current vulnerability is exporting/importhing these keys to
> pgp.mit.edu et al.

If you just want to check for valid signatures, you can blindly
download the keys from a keyserver.  If you want to verify that those
signing keys belong to Gentoo devs, you'll need a web of trust, just
like any other PGP situation.  The problem is distributing the trust,
not the distributing the keys [1].

If you want a central policy for trusting Gentoo devs, you've already
got an authentication scheme set up to log into the Gentoo servers.
If you trust that scheme, and trust those servers against privilege
escalation and the like, then if a dev can log into the server and
configure their preferred key fingerprint, that seems like a
sufficiently rigorous proof for the Gentoo infra folks to conclude
that the dev in question owns the key in question.

The fact that the Gentoo infra folks might trust the dev's key enough
to publish snapshots signed by that key has no bearing on whether I,
as a non Gentoo dev who knows none of the infra folks, can trust the
key.  I've got to establish my own web of trust to make that happen,
and it's not something that I expect Gentoo to help me with.

[1]:
  http://www.gnupg.org/gph/en/manual.html#AEN533
  http://www.gnupg.org/gph/en/manual.html#AEN554

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]