Mailing List Archive: Gentoo: Dev

Git braindump: 1 of N: merging & git signing

1 2

View All

Index | Next | Previous | View Threaded

ciaran.mccreesh at googlemail

Jun 4, 2012, 1:58 PM

Post #26 of 33 (135 views)
Permalink

Re: Git braindump: 1 of N: merging & git signing [In reply to]

On Mon, 04 Jun 2012 22:52:25 +0200
"Andreas K. Huettel" <dilfridge [at] gentoo> 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

Attachments:

signature.asc (0.19 KB)

djc at gentoo

Jun 4, 2012, 10:25 PM

Post #27 of 33 (139 views)
Permalink

Re: Git braindump: 1 of N: merging & git signing [In reply to]

On Mon, Jun 4, 2012 at 10:41 PM, Brian Harring <ferringb [at] gmail> 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

mgorny at gentoo

Jun 4, 2012, 11:50 PM

Post #28 of 33 (134 views)
Permalink

Re: Git braindump: 1 of N: merging & git signing [In reply to]

On Mon, 4 Jun 2012 16:57:42 -0400
Rich Freeman <rich0 [at] gentoo> 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

Attachments:

signature.asc (0.31 KB)

rich0 at gentoo

Jun 5, 2012, 7:15 AM

Post #29 of 33 (134 views)
Permalink

Re: Git braindump: 1 of N: merging & git signing [In reply to]

On Tue, Jun 5, 2012 at 2:50 AM, Michał Górny <mgorny [at] gentoo> wrote:
> On Mon, 4 Jun 2012 16:57:42 -0400
> Rich Freeman <rich0 [at] gentoo> 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

wking at tremily

Jun 8, 2012, 4:01 AM

Post #30 of 33 (134 views)
Permalink

Re: Git braindump: 1 of N: merging & git signing [In reply to]

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

Attachments:

signature.asc (0.82 KB)

rich0 at gentoo

Jun 8, 2012, 4:36 AM

Post #31 of 33 (135 views)
Permalink

Re: Git braindump: 1 of N: merging & git signing [In reply to]

On Fri, Jun 8, 2012 at 7:01 AM, W. Trevor King <wking [at] tremily> 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

xmw at gentoo

Jun 8, 2012, 6:40 AM

Post #32 of 33 (139 views)
Permalink

Re: Git braindump: 1 of N: merging & git signing [In reply to]

-----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-----

wking at tremily

Jun 8, 2012, 11:08 AM

Post #33 of 33 (134 views)
Permalink

Re: Git braindump: 1 of N: merging & git signing [In reply to]

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

Attachments:

signature.asc (0.82 KB)

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads