[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: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 10 May 2017 13:44:58 +0200

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_apache.org]
> Sent: woensdag 10 mei 2017 13:34
> To: Daniel Shahaf <d.s_at_daniel.shahaf.name>
> Cc: dev_at_subversion.apache.org; commits_at_subversion.apache.org
> Subject: Re: svn commit: r1794632 - /subversion/trunk/notes/sha1-
> advisory.txt
>
> On Wed, May 10, 2017 at 09:11:50AM +0000, Daniel Shahaf wrote:
> > > Summary:
> > > ========
> > >
> > > Subversion repositories can be corrupted by committing two files
> > > which have different content, yet produce the same SHA1 checksum.
> >
> > I don't think we should call this "corruption": the on-disk data
> > structures are intact, both syntactically and semantically. The problem
> > is in the libraries' assumption that sha1 has no collisions.
> >
> > I'm afraid I don't have a good suggestion; perhaps "Distinct files that
> > have equal sha1 checksums cannot be checked out"?
>
> I think we should call it corruption simply because it looks like
> that to our users when it happens (see webkit).
>
> This is a user-facing text. We want users to take action and upgrade so
> they won't run into the problem. The purpose of this text is to raise
> awareness. It is not to communicate technical details of the problem,
> which can be obtained by other means (reading code, mailing lists, etc.)
>
> I expect "corruption" will turn on people's alarm bells more than your
> suggested wording which is very exact but also sounds less dramatic.

Those alarm bells are the reason why I wouldn't call it corruption, as that
part will probably be highlighted in the media, while there is nothing
corrupt on disk.

        Bert
Received on 2017-05-10 13:45:12 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.