ial in this e-mail is strictly forbidden.
> From: Garance A Drosehn [mailto:dro...@rpi.edu]
> Sent: Thursday, March 02, 2017 7:32 PM
> To: Daniel Shahaf
> Cc: Subversion Development
> Subject: Re: Files with identical SHA1 breaks the repo
>
> On 2 Mar 2017, at 6:37, Daniel Shahaf
On 2 Mar 2017, at 6:37, Daniel Shahaf wrote:
Garance A Drosehn wrote on Wed, Mar 01, 2017 at 14:48:07 -0500:
I do not see how this extended-sha1 would be easier to
break than the current sha1, because it includes the
current sha1, unchanged.
Regarding "easier to break", you were probably thi
Garance A Drosehn wrote on Wed, Mar 01, 2017 at 14:48:07 -0500:
> On 1 Mar 2017, at 7:18, Daniel Shahaf wrote:
>
> > Stefan Sperling wrote on Wed, Mar 01, 2017 at 11:01:40 +0100:
> >> On Tue, Feb 28, 2017 at 10:17:34PM -0600, Greg Stein wrote:
> >>> I really like this idea.
> >>>
> >>> And we coul
On 1 Mar 2017, at 7:18, Daniel Shahaf wrote:
> Stefan Sperling wrote on Wed, Mar 01, 2017 at 11:01:40 +0100:
>> On Tue, Feb 28, 2017 at 10:17:34PM -0600, Greg Stein wrote:
>>> I really like this idea.
>>>
>>> And we could take a copy of APR's sha1 code, and rejigger
>>> it to perform *both* hashes
Stefan Sperling wrote on Wed, Mar 01, 2017 at 11:01:40 +0100:
> On Tue, Feb 28, 2017 at 10:17:34PM -0600, Greg Stein wrote:
> > I really like this idea.
> >
> > And we could take a copy of APR's sha1 code, and rejigger it to perform
> > *both* hashes during the same scan of the raw bytes. I would
On Tue, Feb 28, 2017 at 10:17:34PM -0600, Greg Stein wrote:
> I really like this idea.
>
> And we could take a copy of APR's sha1 code, and rejigger it to perform
> *both* hashes during the same scan of the raw bytes. I would expect the
> time taken to extend by (say) 1.1X rather than a full 2X. T
I really like this idea.
And we could take a copy of APR's sha1 code, and rejigger it to perform
*both* hashes during the same scan of the raw bytes. I would expect the
time taken to extend by (say) 1.1X rather than a full 2X. The inner loop
might cost a bit more, but we'd only scan the bytes once
On 2/26/2017 11:22 PM, Stefan wrote:
My personal opinion here is that given the timeframe I see SVN servers
are in production use nowadays (even up to 10 years), I think it'd be
reasonable to better have something ready now, then be sorry later.
Of cause this should read: "My personal opinion
On 2/25/2017 08:51, b...@qqmail.nl wrote:
>
> I remember some experiments in early development of WC-NG where we
> measured which checksums worked vs which ones were too expensive.
> Going to the SHA1 family was at least 5 times more expensive or so…
>
>
>
> We determined back then SHA1 was good
On Sun, Feb 26, 2017 at 07:29:30PM +0100, Branko Čibej wrote:
> On 26.02.2017 18:26, Paul Hammant wrote:
> > Why don't y'all take the same tactic as Git does - SHA1 the contents of the
> > file *and a prepended a type/length field* ?.
>
> And when the hash-colliding files happen to have the same t
On 26.02.2017 18:26, Paul Hammant wrote:
> Why don't y'all take the same tactic as Git does - SHA1 the contents of the
> file *and a prepended a type/length field* ?.
And when the hash-colliding files happen to have the same type and
length, as in the published collision...
Ah, of course, Git is
Why don't y'all take the same tactic as Git does - SHA1 the contents of the
file *and a prepended a type/length field* ?.
That and a tool to back convert SHA1s for existing repos.
Linus weighed in again:
https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL
Svn is more likely to be used as a s
On 24 Feb 2017, at 15:46, Stefan Sperling wrote:
>
> I believe we should prepare a new working format for 1.10.0
> which addresses this problem. I don't see a good way of fixing
> it without a format bump. The bright side of this is that it
> gives us a good reason to get 1.10.0 ready ASAP.
>
> We
On Sat, Feb 25, 2017 at 08:56:33AM +0100, b...@qqmail.nl wrote:
> That there is a collision now doesn’t change that we always assumed
> there would be collisions, and designed the current behavior with that
> in mind.
Yes, that is right. My line of thinking there was not meant to be the
one we use
. Holm; Subversion Development
Subject: Re: Files with identical SHA1 breaks the repo
On Fri, Feb 24, 2017 at 01:03:09PM -0500, Mark Phippard wrote:
> Note that while this does fix the error, but because of the sha1 storage
> sharing in the working copy you actually do not get the correct files.
with identical SHA1 breaks the repo
On Fri, Feb 24, 2017 at 04:17:44PM +0100, Andreas Stieger wrote:
> Hi,
>
> "Stefan Hett" wrote:
> > On 2/23/2017 9:02 PM, Øyvind A. Holm wrote:
> > > This is the only known SHA-1 collision at the moment, but Google will
> >
Andreas Stieger wrote on Fri, Feb 24, 2017 at 16:17:44 +0100:
> Hi,
>
> "Stefan Hett" wrote:
> > On 2/23/2017 9:02 PM, Øyvind A. Holm wrote:
> > > This is the only known SHA-1 collision at the moment, but Google will
> > > release the collision code in 90 days, so we can expect this not to last
>
Hi,
This hook script can prevent further corruptions through files based on
the known two 320 bytes prefixes.
https://svn.apache.org/r1784336
Andreas
On Fri, Feb 24, 2017 at 01:03:09PM -0500, Mark Phippard wrote:
> Note that while this does fix the error, but because of the sha1 storage
> sharing in the working copy you actually do not get the correct files.
> Both PDF's wind up being the same file, I imagine whichever one you receive
> first is
On Fri, Feb 24, 2017 at 5:51 AM, Stefan Sperling wrote:
> On Thu, Feb 23, 2017 at 09:02:28PM +0100, Řyvind A. Holm wrote:
> > Earlier today, the first known SHA1 collision was presented:
> >
> > https://security.googleblog.com/2017/02/announcing-first-
> sha1-collision.html
> > http://shatter
Surely two files with the same hash was always a posibility, not matter what
the hash function is?
Barry
> On 24 Feb 2017, at 16:55, Mark Phippard wrote:
>
> Someone may want to jump in here:
>
> https://news.ycombinator.com/item?id=13725093
>
> Mark
>
>
>> On Feb 24, 2017, at 5:51 AM, Ste
Someone may want to jump in here:
https://news.ycombinator.com/item?id=13725093
Mark
> On Feb 24, 2017, at 5:51 AM, Stefan Sperling wrote:
>
>> On Thu, Feb 23, 2017 at 09:02:28PM +0100, Øyvind A. Holm wrote:
>> Earlier today, the first known SHA1 collision was presented:
>>
>> https://secur
On Fri, Feb 24, 2017 at 04:17:44PM +0100, Andreas Stieger wrote:
> Hi,
>
> "Stefan Hett" wrote:
> > On 2/23/2017 9:02 PM, Øyvind A. Holm wrote:
> > > This is the only known SHA-1 collision at the moment, but Google will
> > > release the collision code in 90 days, so we can expect this not to last
Hi,
"Stefan Hett" wrote:
> On 2/23/2017 9:02 PM, Øyvind A. Holm wrote:
> > This is the only known SHA-1 collision at the moment, but Google will
> > release the collision code in 90 days, so we can expect this not to last
> > forever.
> Reading up on that in an article on a German magazine [1] cla
On 2/23/2017 9:02 PM, Øyvind A. Holm wrote:
This is the only known SHA-1 collision at the moment, but Google will
release the collision code in 90 days, so we can expect this not to last
forever.
Reading up on that in an article on a German magazine [1] clarifies that
the effort to create that h
On 24.02.2017 14:52, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Feb 24, 2017 at 12:59:16 +0100:
>> On 24.02.2017 12:28, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Fri, Feb 24, 2017 at 12:18:05 +0100:
This is precisely why rep-sharing is disabled by default when the
repository i
Branko Čibej wrote on Fri, Feb 24, 2017 at 12:59:16 +0100:
> On 24.02.2017 12:28, Daniel Shahaf wrote:
> > Branko Čibej wrote on Fri, Feb 24, 2017 at 12:18:05 +0100:
> >> This is precisely why rep-sharing is disabled by default when the
> >> repository is created.
> >
> > It's _enabled_ by default:
On 24.02.2017 13:41, Andreas Stieger wrote:
>> Linus weighs on on Git's use of SHA1 (may be interesting)
>> http://marc.info/?l=git&m=148787047422954&w=2
> It affects svn more due to it's use of sha1 for versioned entities (here:
> files) rather than trees.
Except that content indexing in Subvers
> Linus weighs on on Git's use of SHA1 (may be interesting)
> http://marc.info/?l=git&m=148787047422954&w=2
It affects svn more due to it's use of sha1 for versioned entities (here:
files) rather than trees.
Andreas
Linus weighs on on Git's use of SHA1 (may be interesting)
http://marc.info/?l=git&m=148787047422954&w=2
On 24.02.2017 12:28, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Feb 24, 2017 at 12:18:05 +0100:
>> On 24.02.2017 11:51, Stefan Sperling wrote:
>>> On Thu, Feb 23, 2017 at 09:02:28PM +0100, Øyvind A. Holm wrote:
Earlier today, the first known SHA1 collision was presented:
>>
On 2/24/2017 12:48 PM, Stefan Hett wrote:
On 2/24/2017 12:28 PM, Daniel Shahaf wrote:
Branko Čibej wrote on Fri, Feb 24, 2017 at 12:18:05 +0100:
On 24.02.2017 11:51, Stefan Sperling wrote:
On Thu, Feb 23, 2017 at 09:02:28PM +0100, Øyvind A. Holm wrote:
Earlier today, the first known SHA1 coll
On 2/24/2017 12:28 PM, Daniel Shahaf wrote:
Branko Čibej wrote on Fri, Feb 24, 2017 at 12:18:05 +0100:
On 24.02.2017 11:51, Stefan Sperling wrote:
On Thu, Feb 23, 2017 at 09:02:28PM +0100, Øyvind A. Holm wrote:
Earlier today, the first known SHA1 collision was presented:
https://security.g
Branko Čibej wrote on Fri, Feb 24, 2017 at 12:18:05 +0100:
> On 24.02.2017 11:51, Stefan Sperling wrote:
> > On Thu, Feb 23, 2017 at 09:02:28PM +0100, Øyvind A. Holm wrote:
> >> Earlier today, the first known SHA1 collision was presented:
> >>
> >>
> >> https://security.googleblog.com/2017/02/an
On 24.02.2017 11:51, Stefan Sperling wrote:
> On Thu, Feb 23, 2017 at 09:02:28PM +0100, Øyvind A. Holm wrote:
>> Earlier today, the first known SHA1 collision was presented:
>>
>>
>> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
>> http://shattered.io/
>>
>> It t
On Thu, Feb 23, 2017 at 09:02:28PM +0100, Øyvind A. Holm wrote:
> Earlier today, the first known SHA1 collision was presented:
>
> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
> http://shattered.io/
>
> It turns out that adding these two PDF files to a svn repo
36 matches
Mail list logo
