[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1794632 - /subversion/trunk/notes/sha1-advisory.txt

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 11 May 2017 05:44:45 +0000

Stefan Sperling wrote on Wed, May 10, 2017 at 13:34:07 +0200:
> On Wed, May 10, 2017 at 09:11:50AM +0000, Daniel Shahaf wrote:
> > > Details:
> > > ========
> > >
> > > In February 2017 a group of researchers released two PDF files which have
> > > different content but produce the same SHA1 checksum. This was the first
> > > publicly known SHA1 collision ever produced.
> > >
> > > If both of these files are committed to a Subversion repository, Subversion
> > > de-duplicates content based on the SHA1 checksum and only the content of
> >
> > Missing qualifiers: only for FSFS and FSX and only if rep-sharing is
> > enabled. (I see the "Recommendations" section says that, but I think
> > they belong here.)
>
> Ack, fixed.

You've added the "only FSFS and FSX" part but not the "only if
rep-sharing is enabled" part. Was that intentional?

(I see the "Recommendations" section mentions enabling rep-sharing
post-upgrade, but that's separate to stating that repositories that have
rep-sharing disabled _today_ are not vulnerable.)

> > Moreover, the error is not spurious; on the contrary: it functions
> > exactly as designed, and prevents the wrong file from being used. Let's
> > say this in the advisory?
>
> Too much detail, I'd say.

My intention with this text was to avoid readers forming the (mistaken)
impression that the md5 checksum error is a bug and concluding that
libsvn is brittle. The md5 error is a safety net functioning as
designed. I know this; you know this; the reader might not.

> > > introduced the problem. This dump file can be loaded into a new repository.
> > > If there were more commits after the problematic revision then dump and load
> > > all of these subsequent revisions as well.
> >
> > Mention 'svndumpfilter exclude'?
>
> That may be a third possibility. But has anyone tested it?

I just did:

[[[
% svnlook tree r
/
 shattered-1.pdf
 shattered-2.pdf
% svnadmin create r2
% svnadmin dump -q r | svndumpfilter exclude /shattered-2.pdf | svnadmin load r2
Excluding prefixes:
   '/shattered-2.pdf'

Revision 0 committed as 0.
Revision 1 committed as 1.
<<< Started new transaction, based on original revision 1

Dropped 1 node:
   '/shattered-2.pdf'

     * editing path : shattered-1.pdf ... done.

------- Committed revision 1 >>>

% svn cat file://$PWD/r2/shattered-1.pdf | md5sum
ee4aa52b139d925f8d8884402b0a750c -
% svn cat file://$PWD/r/shattered-1.pdf | md5sum
ee4aa52b139d925f8d8884402b0a750c -
]]]

Thanks for the fixes!

Cheers,

Daniel
Received on 2017-05-11 07:44:58 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.