Re: New MaxSVN releases (incl. 1.8.17 and 1.9.5)

2017-02-24 Thread Johan Corveleyn
On Fri, Feb 24, 2017 at 2:43 AM, Stefan wrote: ... > Please note that normally we'd have shipped this version with OpenSSL > 1.1.0c. However, we decided to postpone an upgrade to OpenSSL 1.1.0 for > the time being due to Apache httpd not having a compatible release > available

Re: New MaxSVN releases (incl. 1.8.17 and 1.9.5)

2017-02-24 Thread Stefan Hett
On 2/24/2017 11:06 AM, Johan Corveleyn wrote: On Fri, Feb 24, 2017 at 2:43 AM, Stefan wrote: ... Please note that normally we'd have shipped this version with OpenSSL 1.1.0c. However, we decided to postpone an upgrade to OpenSSL 1.1.0 for the time being due to Apache httpd not

Re: 1.10.0-alpha2 is up for signing

2017-02-24 Thread Johan Corveleyn
On Fri, Feb 24, 2017 at 3:39 AM, Stefan wrote: > On 2/21/2017 13:54, Stefan Sperling wrote: >> The new 1.10.1-alpha2 release is up for signing. >> >> The proposed 1.10.0-alpha1 release had a compilation problem on Windows. >> The alpha2 release should fix this problem. It is

Re: [PATCH] use SHA-2 family hash for releases

2017-02-24 Thread Stefan Hett
On 2/24/2017 6:26 AM, Daniel Shahaf wrote: Andreas Stieger wrote on Thu, Feb 23, 2017 at 21:08:43 +0100: +++ tools/dist/release.py (working copy) @@ -537,9 +537,9 @@ def roll_tarballs(args): shutil.move(filename, get_deploydir(args.base_dir)) filename =

svnconflict build failure on Windows (was: Re: 1.10.0-alpha2 is up for signing)

2017-02-24 Thread Stefan Sperling
On Fri, Feb 24, 2017 at 03:39:43AM +0100, Stefan wrote: > On 2/21/2017 13:54, Stefan Sperling wrote: > > The new 1.10.1-alpha2 release is up for signing. > > > > The proposed 1.10.0-alpha1 release had a compilation problem on Windows. > > The alpha2 release should fix this problem. It is based on

Re: Files with identical SHA1 breaks the repo

2017-02-24 Thread Stefan Sperling
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

Re: Files with identical SHA1 breaks the repo

2017-02-24 Thread Branko Čibej
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

2017-02-24 Thread Stefan Hett
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

2017-02-24 Thread Branko Čibej
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

2017-02-24 Thread Paul Hammant
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

2017-02-24 Thread Branko Čibej
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

2017-02-24 Thread Daniel Shahaf
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

2017-02-24 Thread bert
The whole idea of the pristine cache is handling duplicate files… I don’t see what you are trying to solve by adding a salt. The pristine store is not a password store, where expensive hashing is a good feature… not a user facing slowdown and we never designed Subversion as a storage area for

RE: Files with identical SHA1 breaks the repo

2017-02-24 Thread bert
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 enough for our use and that of our users ‘except for

Re: Files with identical SHA1 breaks the repo

2017-02-24 Thread Barry
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

2017-02-24 Thread Mark Phippard
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

2017-02-24 Thread Andreas Stieger
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: svnconflict build failure on Windows

2017-02-24 Thread Stefan
On 2/24/2017 11:35, Stefan Sperling wrote: > On Fri, Feb 24, 2017 at 03:39:43AM +0100, Stefan wrote: >> On 2/21/2017 13:54, Stefan Sperling wrote: >>> The new 1.10.1-alpha2 release is up for signing. >>> >>> The proposed 1.10.0-alpha1 release had a compilation problem on Windows. >>> The alpha2

Re: Files with identical SHA1 breaks the repo

2017-02-24 Thread Mark Phippard
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

2017-02-24 Thread Stefan Sperling
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

2017-02-24 Thread Andreas Stieger
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

2017-02-24 Thread Daniel Shahaf
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: svn commit: r1784336 - /subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh

2017-02-24 Thread Greg Stein
On Fri, Feb 24, 2017 at 3:29 PM, wrote: >... > +++ subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh > Fri Feb 24 21:29:04 2017 > >... > +$SVNLOOK changed -t "$TXN" "$REPOS" > +if [ $? -ne 0 ]; then > + echo $FILES >&2 > + echo "svnlook failed, possible