RE: Files with identical SHA1 breaks the repo

s 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 wrote: > >

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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*

Fast alternative hash (was: Files with identical SHA1 breaks the repo)

On 01.03.2017 05:17, 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. The inner loop might cost

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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.

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

RE: Files with identical SHA1 breaks the repo

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

RE: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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 >

Re: Files with identical SHA1 breaks the repo

Hi, This hook script can prevent further corruptions through files based on the known two 320 bytes prefixes. https://svn.apache.org/r1784336 Andreas

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. > Both PDF's wind up being the same file, I imagine whichever one you receive > first

Re: Files with identical SHA1 breaks the repo

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 >

Re: Files with identical SHA1 breaks the repo

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,

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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]

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

Linus weighs on on Git's use of SHA1 (may be interesting) http://marc.info/?l=git=148787047422954=2

Re: Files with identical SHA1 breaks the repo

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:

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Re: Files with identical SHA1 breaks the repo

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

Files with identical SHA1 breaks the repo

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 repository makes it impossible to checkout the repository properly if both