subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stef...@apache.org>
Subject Re: 1.9.4 fix
Date Mon, 02 May 2016 05:19:34 GMT
On 30.04.2016 02:47, Daniel Shahaf wrote:
> Stefan Fuhrmann wrote on Fri, Apr 29, 2016 at 09:29:20 +0200:
>> Issue #4554 talks about two things, a set of conditions and their
>> immediate impact (broken dump file).  The dump file will simply
>> not load and that's easy enough to detect.  The set of conditions
>> is as follows:
>>
>>    1. Representation sharing must be enabled (default since 1.6 or so).
>>    2. At least one change must be committed using a 1.8+ server.
>>    3. Property and directory deltification must not be enabled
>>       (available since 1.8 but enabled by default only since 1.9).
>>    4. A file gets committed whose contents happens to look exactly
>>       like a serialized hash (i.e. a directory content or property list)
>>       that has been committed with 1.8+.
>>    5. No file with the same contents has been committed using a pre-1.8
>>       server with rep-sharing enabled.
>>
>> Point 4 is unlikely to occur by accident.  By far your best shot
>> at this is to have a 4-byte file containing "END\n", which happens
>> to match an empty hash.  Another chance is committing the contents
>> of a .svn folders of a pre-1.7 working copy - which requires some
>> serious fiddling with the .svn folders.
>
> If these conditions do occur in a repository, though, a third-party tool
> that does not verify checksums for empty files would incur data loss
> when accessing that repository through Subversion 1.9.3 or older.

There are two types of interfaces here:  Some SVN API
and the dump file.  Both are affected.  Invalid dump
files are easy to identify while API users would expect
file_length() to return correct results without double-
checking them, which it did not.

> Does any third-party tool make that optimization?

Such a tool would probably ignore checksums altogether
because there is no point in explicitly ignoring them
for empty files only.

>> 'svnadmin load' will fail.
>
> This sentence applies to any version of svnadmin, including pre-1.9.3
> ones.

Correct.

>> No-op changes cannot be produced by standard SVN tooling
>
> They can: just undo the changes while 'commit --editor-cmd' is waiting
> for the editor to exit.  (I posted a scripted version of that at some
> point, but can't find it.)

Thanks for pointing that out.  I was not aware that this
would send the change list before waiting for commit msg.

-- Stefan^2.

Mime
View raw message