Re: [gentoo-dev] Re: git security (SHA-1)

[Rich Freeman]

On Sat, Sep 20, 2014 at 2:09 PM, Ulrich Mueller <ulm@g.o> wrote:
>>>>>> On Wed, 17 Sep 2014, Aaron W. Swenson wrote:
>
>> My argument is Git using SHA-1 for checksumming is not the weakest
>> part of our security model.
>
> I had always assumed that robbat2's series of GLEPs (57 to 61) would
> be implemented at some point. So security from the developer to the
> master repository would be ensured by using a secure channel for
> commits, and distribution from the repository to users would use
> secure hashes (SHA-256 or better) and gpg signatures.
>
> I didn't see any mention of this in the discussion, though. Have these
> plans been abandoned, and are we now planning to distribute the tree
> to users via Git, where everything goes through the bottleneck of a
> SHA-1 sum, which was never intended as a security feature? [1]
>
> If this is so, why don't we abandon all those fancy SHA-512s and
> WHIRLPOOLs in our Manifest files, and replace them by a single SHA-1?
> Altogether, this would save about 50 MB of space in the tree. :)

The issue is that we have lots of devs with lots of plans, and nothing
official whatsoever.  There is no formal plan to ever adopt those
GLEPs (I'm not saying it isn't likely to happen - just that there
isn't some kind of roadmap to actually implementing them).  There is
no plan to ever move to git, or not move to git.  There is no plan for
how any of this stuff is supposed to work a few years from now.

Gentoo isn't terribly big on planning - whether this is a good or bad
thing is perhaps debatable.  Typically whoever implements something
first tends to decide how it gets implemented.

It seems like most people involved in the git migration have planned
on moving to signed commits and thin manifests.  This would mean that
the chain of security would include dependence on sha1, since that is
the only thing that binds a singed commit to the data which was
committed (including the thin manifest file itself).

Then you get all the pile-on arguments that basically question whether
we care about the tree being signed anyway.

If this were some kind of corporation where we could make whatever
plans we wanted to make and pay people to make them happen whether
they liked the plans or not, then I would suggest the way we should go
about this is:
1.  Decide whether we really care about tree signing.
2.  If yes, no more arguing about whether we need tree signing.  Next
step is to decide what threat models we want to protect against.
3.  Then design something that actually provides security against the
targeted threat models.

The issue here is that we're basically starting at #3, with people all
over the map about #1-2, and thus it should be entirely unsurprising
that we invest in things like signed commits with nothing more than
sha1 to bind those signatures to files.

I'm personally in the camp that I'd rather see ANY git migration
happen sooner rather than later and I'd rather migrate first and then
fix any signature issues later.  Simple gpg signed commits secured
only with sha1 seems good enough to start with.

--
Rich