Re: SHA-1 collision in repository?

Nathan Hartman <hartman.nathan_at_gmail.com> writes:

> Is it possible and does it make sense to always continue reading until
> EOF, when the read is either 0 or < 16k? In other words to eliminate
> the comparison against the expanded size?

I believe setting the expanded size correctly is the only fix we need.

> Alternatively, if reading up to the expanded size and then stopping,
> does it make sense to attempt another read, which must come back as 0,
> to verify that the expanded size and actual size are equal? If not
> equal, an error message on this issue would be far more helpful than
> the one currently output.

Not sure. The caller often does just that but that essentially just
involves:

  if (rb->off == rb->len)
    *len = 0;

and trivially returns 0. I suppose we could make a call to data
extraction functions but I don't know how that would behave. I am
reluctant to do it on a release branch.

There is one additional check we should add, on trunk at least. This
code was originally written as a read_fn for an svn_stream_t and thus
had to allow short reads. It is now a read_full_fn and the only short
read is at EOF, so we should verify the expanded size on a short read.

> Have you had a chance to test against the 1.10 rc?

The trunk/1.10 code has been reworked and, as far as I can tell, the bug
is not present.

-- 
Philip