Sorry if I'm dropping in at the wrong point (this is one I'd bookmarked)..
From: "Duy Nguyen"
Sent: Wednesday, July 20, 2016 3:44 PM
On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
wrote:
But that strategy *still* ignores the distributed nature of Git. Just
because *you* make that merg
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 18 Jul 2016, Junio C Hamano wrote:
>
>> "brian m. carlson" writes:
>>
>> > I will say that the pack format will likely require some changes,
>> > because it assumes ... The reason is that we can't have an
>> > unambiguous parse of the current
Hi Brian,
On Mon, 18 Jul 2016, brian m. carlson wrote:
> On Mon, Jul 18, 2016 at 09:00:06AM +0200, Johannes Schindelin wrote:
>
> > FWIW it never crossed my mind to allow different same-sized hash
> > algorithms. So I never thought we'd need a way to distinguish, say,
> > BLAKE2b-256 from SHA-25
Hi Brian,
On Mon, 18 Jul 2016, brian m. carlson wrote:
> On Mon, Jul 18, 2016 at 11:00:35AM -0700, Junio C Hamano wrote:
> > Continuing this thought process, I do not see a good way to allow us
> > to wean ourselves off of the old hash, unless we _break_ the pack
> > stream format so that each ob
Hi Junio,
On Mon, 18 Jul 2016, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > I will say that the pack format will likely require some changes,
> > because it assumes ... The reason is that we can't have an
> > unambiguous parse of the current objects if two hash algorithms are in
>
Stefan Beller writes:
>> to follow the above, in my view, interaction with sha1 repos go
>> through some conversion bridges like what we have with hg and svn. I
>> don't know if we are going this route. It's certainly simpler and
>> people already have experiences (from previous migration) to pre
On Wed, Jul 20, 2016 at 7:44 AM, Duy Nguyen wrote:
> On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
> wrote:
>> But that strategy *still* ignores the distributed nature of Git. Just
>> because *you* make that merge at a certain point does not necessarily mean
>> that I make it at that point
On Tue, Jul 19, 2016 at 8:58 PM, Herczeg Zsolt wrote:
> 2016-07-19 20:04 GMT+02:00 Duy Nguyen :
>> On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote:
>>> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>>>
On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
>
> On Tue, 19 Jul 2016, Duy Nguyen
On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
wrote:
> But that strategy *still* ignores the distributed nature of Git. Just
> because *you* make that merge at a certain point does not necessarily mean
> that I make it at that point, too.
>
> Any approach that tries to have one single point
Hi Duy,
On Tue, 19 Jul 2016, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote:
> > On Tue, 19 Jul 2016, Duy Nguyen wrote:
> >
> >> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
> >>>
> >>> On Tue, 19 Jul 2016, Duy Nguyen wrote:
> >>>
> On Tue, Jul 19, 2016 at 9:18
2016-07-19 20:04 GMT+02:00 Duy Nguyen :
> On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote:
>> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>>
>>> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
On Tue, 19 Jul 2016, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Sc
Duy Nguyen writes:
>> Even though that single operation might be possible, do not go
>> there. A "pathname" identifies a "path", not its contents, and
>> "appending crap after path" breaks the data model badly.
>
> I thought about that but I thought all those operations required
> special treatm
On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote:
> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>
>> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
>>>
>>> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>>>
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
wrote:
>>
>>
>> But we
On Tue, 19 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
On Tue, 19 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
wrote:
But we can recreate SHA-1 from the same content and verify GPG, right?
I know it's super expensive,
On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>
>> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
>> wrote:
But we can recreate SHA-1 from the same content and verify GPG, right?
I know it's super expensive, but it feels safer to
On Tue, 19 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
wrote:
But we can recreate SHA-1 from the same content and verify GPG, right?
I know it's super expensive, but it feels safer to not carry SHA-1
around when it's not secure anymore (I recall something a
On Tue, Jul 19, 2016 at 7:06 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Post-shower thoughts. In a tree object, a submodule entry consists of
>> perm (S_IFGITLINK), hash (which is the external hash) and path. We
>> could fill the "hash" part with all zero (invalid, signature of new
>> su
Duy Nguyen writes:
> Post-shower thoughts. In a tree object, a submodule entry consists of
> perm (S_IFGITLINK), hash (which is the external hash) and path. We
> could fill the "hash" part with all zero (invalid, signature of new
> submodule hash format), then append "/:" to
> the "path" part. Th
On Mon, Jul 18, 2016 at 6:51 PM, Duy Nguyen wrote:
> On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
> wrote:
>> I'm going to end up having to do something similar because of the issue
>> of submodules. Submodules may still be SHA-1, while the main repo may
>> be a newer hash.
>
> Or even the
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
wrote:
>> But we can recreate SHA-1 from the same content and verify GPG, right?
>> I know it's super expensive, but it feels safer to not carry SHA-1
>> around when it's not secure anymore (I recall something about
>> exploiting the weakest lin
On Tue, 19 Jul 2016, Johannes Schindelin wrote:
Hi Duy,
On Mon, 18 Jul 2016, Duy Nguyen wrote:
On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
wrote:
I'm going to end up having to do something similar because of the issue
of submodules. Submodules may still be SHA-1, while the main repo
Hi Duy,
On Mon, 18 Jul 2016, Duy Nguyen wrote:
> On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
> wrote:
> > I'm going to end up having to do something similar because of the issue
> > of submodules. Submodules may still be SHA-1, while the main repo may
> > be a newer hash.
>
> Or even the
Hi Zsolt,
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
> >> My point is not to throw out old hashes and break signatures. My point
> >> is to convert the data storage, and use mapping to resolve problems
> >> with those old hashes and signatures.
> >
> > If you convert the data storage, then the SHA
Hi Duy,
On Mon, 18 Jul 2016, Duy Nguyen wrote:
> On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin
> wrote:
> >
> > On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
> >
> >> >> I think converting is a much better option. Use a single-hash
> >> >> storage, and convert everything to that on import/clo
On Mon, Jul 18, 2016 at 11:00:35AM -0700, Junio C Hamano wrote:
> Continuing this thought process, I do not see a good way to allow us
> to wean ourselves off of the old hash, unless we _break_ the pack
> stream format so that each object in the pack carries not just the
> data but also the hash al
On Mon, Jul 18, 2016 at 09:00:06AM +0200, Johannes Schindelin wrote:
> Hi Brian,
>
> On Sun, 17 Jul 2016, brian m. carlson wrote:
>
> > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote:
> > > Out of curiosity: have you considered something like padding the SHA-1s
> > > with, sa
>> The reality of the current situation is that it's largely mitigated in
>> practice because:
>>
>> a) it's hard to hand someone a crafted blob to begin with for reasons
>> that have nothing to do with SHA-1 (they'll go "wtf is this garbage?")
>>
>> b) even in that case it's *very* hard to come up
Junio C Hamano wrote:
> Continuing this thought process, I do not see a good way to allow us
> to wean ourselves off of the old hash, unless we _break_ the pack
> stream format so that each object in the pack carries not just the
> data but also the hash algorithm to be used to _name_ it, so that
Ævar Arnfjörð Bjarmason writes:
> The reality of the current situation is that it's largely mitigated in
> practice because:
>
> a) it's hard to hand someone a crafted blob to begin with for reasons
> that have nothing to do with SHA-1 (they'll go "wtf is this garbage?")
>
> b) even in that case
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
In particular, as far as I know and as Theodore Ts'o's post describes
better than I could[1], you seem to be confusing preimage attacks with
collision attacks, and then concluding that because SHA1 is vulnerable
to collision attacks that use-cases that w
On Mon, Jul 18, 2016 at 7:48 PM, Herczeg Zsolt wrote:
>> In particular, as far as I know and as Theodore Ts'o's post describes
>> better than I could[1], you seem to be confusing preimage attacks with
>> collision attacks, and then concluding that because SHA1 is vulnerable
>> to collision attacks
"brian m. carlson" writes:
> I will say that the pack format will likely require some changes,
> because it assumes ...
> The reason is that we can't have an unambiguous parse of the current
> objects if two hash algorithms are in use
> So when we look at a new hash, we need to provide an una
> In particular, as far as I know and as Theodore Ts'o's post describes
> better than I could[1], you seem to be confusing preimage attacks with
> collision attacks, and then concluding that because SHA1 is vulnerable
> to collision attacks that use-cases that would need a preimage attack
> to be c
On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
wrote:
> I'm going to end up having to do something similar because of the issue
> of submodules. Submodules may still be SHA-1, while the main repo may
> be a newer hash.
Or even the other way around, main repo is one with sha1 while
submodule i
On Sat, Jul 16, 2016 at 3:48 PM, Herczeg Zsolt wrote:
> I would like to discuss an old topic from 2006. I understand it was
> already discussed. The only reason i'm sending this e-mail is to talk
> about a possible solution which didn't show up on this list before.
You mention the 2006 discussion
Hi Johannes,
>> My point is not to throw out old hashes and break signatures. My point
>> is to convert the data storage, and use mapping to resolve problems
>> with those old hashes and signatures.
>
> If you convert the data storage, then the SHA-1s listed in the commit
> objects will have to be
On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin
wrote:
> Hi Zsolt,
>
> On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
>
>> >> I think converting is a much better option. Use a single-hash
>> >> storage, and convert everything to that on import/clone/pull.
>> >
>> > That ignores two very important
Hi Zsolt,
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
> >> I think converting is a much better option. Use a single-hash
> >> storage, and convert everything to that on import/clone/pull.
> >
> > That ignores two very important issues that I already had mentioned:
>
> That's not true. If you doubl
>> I think converting is a much better option. Use a single-hash storage, and
>> convert everything to that on import/clone/pull.
>
> That ignores two very important issues that I already had mentioned:
That's not true. If you double-check the next part of my message, you
I just showed that an aut
Hi Zsolt,
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
> I think converting is a much better option. Use a single-hash storage, and
> convert everything to that on import/clone/pull.
That ignores two very important issues that I already had mentioned:
- existing references, both in-repository, e.g
Hi Brian,
On Sun, 17 Jul 2016, brian m. carlson wrote:
> On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote:
> > Out of curiosity: have you considered something like padding the SHA-1s
> > with, say 0xa1, to the size of the new hash and using that padding to
> > distinguish betwe
Do you think the multi-hash approach worth the added complexity? It'll
break a lot of things. I mean almost everything. All git algorithms
rely on the "same hash => same content" "same content => same hash"
statements.
I think converting is a much better option. Use a single-hash storage,
and conv
On Sun, Jul 17, 2016 at 12:23:49PM -0400, Theodore Ts'o wrote:
> On Sun, Jul 17, 2016 at 03:42:34PM +, brian m. carlson wrote:
> > As I said, I'm not planning on multiple hash support at first, but it
> > doesn't appear impossible if we go this route. We might still have to
> > rewrite objects
On Sun, Jul 17, 2016 at 03:42:34PM +, brian m. carlson wrote:
> As I said, I'm not planning on multiple hash support at first, but it
> doesn't appear impossible if we go this route. We might still have to
> rewrite objects, but we can verify signatures over the legacy SHA-1
> objects by forci
On Sun, Jul 17, 2016 at 05:19:02PM +0200, Duy Nguyen wrote:
> On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
> wrote:
> > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote:
> >> Out of curiosity: have you considered something like padding the SHA-1s
> >> with, say 0xa1, to the
On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
wrote:
> On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote:
>> Out of curiosity: have you considered something like padding the SHA-1s
>> with, say 0xa1, to the size of the new hash and using that padding to
>> distinguish between
On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote:
> Out of curiosity: have you considered something like padding the SHA-1s
> with, say 0xa1, to the size of the new hash and using that padding to
> distinguish between old vs new hash?
I'm going to end up having to do something s
Hi Brian,
On Sat, 16 Jul 2016, brian m. carlson wrote:
> My current plan is not to implement side-by-side data, for a couple
> reasons.
I am as guilty as the next person to have use the "deafbee(This is my
commit, 2007-08-21)" format to refer to older commits. So I do have
concerns about rewriti
On Sat, Jul 16, 2016 at 11:46:06PM +0200, Herczeg Zsolt wrote:
> Dear Brian,
>
> Thank you for your response. It very good to hear that changing the
> hash is on the git project's list. I haven't found any official
> communication on that topic since 2006.
There's been some recent discussion on t
Dear Brian,
Thank you for your response. It very good to hear that changing the
hash is on the git project's list. I haven't found any official
communication on that topic since 2006.
I'll look into the contributions guide and the source codes, to check
if I can contribute to this transition. If y
On Sat, Jul 16, 2016 at 03:48:49PM +0200, Herczeg Zsolt wrote:
> But - and that's the main idea i'm writing here - changing the storage
> keys does not mean you should drop your old hashes out. If you change
> the git data structure in a way, that it can keep multiple hashes for
> the same "link" i
Dear List Members, Git Developers,
I would like to discuss an old topic from 2006. I understand it was
already discussed. The only reason i'm sending this e-mail is to talk
about a possible solution which didn't show up on this list before.
I think we all understand that SHA-1 is broken. It still
52 matches
Mail list logo
