On Sat, Jun 18, 2016 at 03:10:27AM +0100, Leo Gaspard wrote:
> First, sorry for not having this message threaded: I'm not subscribed to
> the list and haven't found a way to get a Message-Id from gmane.
Sorry it's taken so long to get back to this. I've been at a
conference.
> So, my questions t
Leo Gaspard wrote:
> First, sorry for not having this message threaded: I'm not subscribed to
> the list and haven't found a way to get a Message-Id from gmane.
Appending "/raw" to the gmane URL will get you the raw message
with full headers:
article.gmane.org/gmane.comp.version-control.git/$N
First, sorry for not having this message threaded: I'm not subscribed to
the list and haven't found a way to get a Message-Id from gmane.
I just wanted to ask, as an end-user highly relying on commit
signatures, a few questions as to the migration away from SHA-1.
SHA-1 already suffers from a fre
On Tue, Apr 12, 2016 at 06:58:10PM -0700, H. Peter Anvin wrote:
> On April 12, 2016 6:51:12 PM PDT, Duy Nguyen wrote:
> >On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote:
> >> OK, I'm going to open this can of worms...
> >>
> >> At what point do we migrate from SHA-1?
> >
> >Brian Carlson ha
On Thu, Apr 14, 2016 at 07:18:53PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > [2] Somewhere in the list archive is my patch to find partial
> > collisions like "git commit --sha1=31337", and I did in fact use
> > that micro-optimization. That, along with multi-threading, made
Jeff King writes:
> [2] Somewhere in the list archive is my patch to find partial
> collisions like "git commit --sha1=31337", and I did in fact use
> that micro-optimization. That, along with multi-threading, made it
> feasible to do 6-8 character prefixes, as I recall.
In our tests
On Thu, Apr 14, 2016 at 06:40:51PM -0400, Theodore Ts'o wrote:
> Also, remember that while we can write programs that look for
> suspicious git objects that have stuff hidden after the null
> terminator (in fact, maybe that would be a good thing to add to git,
> hmmm?)[...]
Detecting the hidden b
On Thu, Apr 14, 2016 at 10:28:50AM -0700, H. Peter Anvin wrote:
>
> Either way, I agree with Ted, that we have enough time to do it
> right, but that is a good reason to do it sooner rather than later
> (see also my note about freezing the cryptographic properties.)
Sure, I think we should do it
On April 14, 2016 10:23:03 AM PDT, David Turner
wrote:
>On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote:
>> On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
>> >
>> > If SHA-1 is broken (in certain ways), someone *can* replace an
>> > arbitrary blob. GPG does not help in thi
On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote:
> On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
> >
> > If SHA-1 is broken (in certain ways), someone *can* replace an
> > arbitrary blob. GPG does not help in this case, because the
> > signature
> > is over the commit objec
Theodore Ts'o wrote:
> OK, so how does this map to git? First of all, from a collision
> perspective, the two blobs have to map into valid C code
Git provides other places to hide the colliding blobs; the best seems to
be as an added header in the commit object, or as trailing data after a \0
in
On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
>
> If SHA-1 is broken (in certain ways), someone *can* replace an
> arbitrary blob. GPG does not help in this case, because the signature
> is over the commit object (which points to a tree, which eventually
> points to the blob), and
On April 12, 2016 6:51:12 PM PDT, Duy Nguyen wrote:
>On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote:
>> OK, I'm going to open this can of worms...
>>
>> At what point do we migrate from SHA-1?
>
>Brian Carlson has been slowly refactoring git code base, abstracting
>SHA-1 away. Once that wo
On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote:
> OK, I'm going to open this can of worms...
>
> At what point do we migrate from SHA-1?
Brian Carlson has been slowly refactoring git code base, abstracting
SHA-1 away. Once that work is done, I think we can talk about moving
away from SHA-1
On 04/12/16 18:03, Junio C Hamano wrote:
and so on. Of course trees don't have any space for this; they have a
fixed-length for the hash part of each record, which is basically:
NUL <20-byte-sha1>
So we'd probably need a "treev2" object type that gives room for an
algorithm byte (or we'd
On Tue, Apr 12, 2016 at 06:03:02PM -0700, Junio C Hamano wrote:
> > So we'd probably need a "treev2" object type that gives room for an
> > algorithm byte (or we'd have to try to shove it into the mode, but since
> > old versions won't know the new algorithm anyway, I don't think it
> > solves tha
Jeff King writes:
> So a slightly nicer thing is to parameterize the algorithm for every
> object name reference. So commits look like:
>
> tree sha256:1234abcd...
> parent sha256:1234abcd...
>
> and so on. Of course trees don't have any space for this; they have a
> fixed-length for the hash
On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
> It would be possible, of course, to GPG-sign the entire commit's
> transitive data (rather than just the SHA1s of same). But as far as I
> know, that is not ever what is done.
There is a project called git-evtag which does this, and
On Tue, Apr 12, 2016 at 03:38:04PM -0700, H. Peter Anvin wrote:
> For existing repositories we will need to have a migration mechanism. Since
> we can't modify objects without completely invalidating the cryptographic
> properties, what I would suggest is that we leave the existing objects as
> is
On Tue, 2016-04-12 at 16:00 -0700, Stefan Beller wrote:
> On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin
> wrote:
> > OK, I'm going to open this can of worms...
> >
> > At what point do we migrate from SHA-1? At this point the
> > cryptoanalysis of
> > SHA-1 is most likely a matter of time.
>
On Tue, Apr 12, 2016 at 04:00:18PM -0700, Stefan Beller wrote:
> On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote:
> > OK, I'm going to open this can of worms...
> >
> > At what point do we migrate from SHA-1? At this point the cryptoanalysis of
> > SHA-1 is most likely a matter of time.
>
On 04/12/16 16:00, Stefan Beller wrote:
On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote:
OK, I'm going to open this can of worms...
At what point do we migrate from SHA-1? At this point the cryptoanalysis of
SHA-1 is most likely a matter of time.
And I thought the cryptographic proper
On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote:
> OK, I'm going to open this can of worms...
>
> At what point do we migrate from SHA-1? At this point the cryptoanalysis of
> SHA-1 is most likely a matter of time.
And I thought the cryptographic properties of SHA1 did not matter for
Gits
OK, I'm going to open this can of worms...
At what point do we migrate from SHA-1? At this point the
cryptoanalysis of SHA-1 is most likely a matter of time.
For existing repositories we will need to have a migration mechanism.
Since we can't modify objects without completely invalidating th
24 matches
Mail list logo