On Mon, Feb 6, 2012 at 16:02, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 02/06/2012 03:54 PM, Hyrum K Wright wrote:
>>...
>> And I'll note that the base checksum check is superfluous, as the
>> resulting contents check is still valid and being performed.
>
> That alone doesn't make the check superfluous. To make such a claim, you
> must demonstrate that the only service such a check provides is toward the
> integrity of the resulting contents. But I believe you'll find that it is
> primarily used to avoid even attempting the application of a text delta to a
> base which is already corrupt, a service which cannot be offered by the
> other checksum, *especially* in the scenarios it is employed by your shim
> (where the text delta will blindly overwrite whatever previous text was
> associated with the file because it is not, in fact, a true delta at all).
Right. Early-fail.
and:
On Mon, Feb 6, 2012 at 15:55, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 02/06/2012 03:49 PM, Greg Stein wrote:
>> Ev2 only has checksums for the resulting content. It uses
>> path/revision to specify the target of the text change.
>
> Ev1 also uses path/revision to specify the target of the text change. I
> wasn't aware that Ev2 was dropping an existing safeguard, though, especially
> one that provides an early out (before transmitting the new text). But I
> confess that I've not evaluated the whole system to see if such integrity
> checks are truly needed.
The deltification steps move into the RA layer, occurring outside of
the editor. These checks can be retained, just in a different context.
For example, let's consider the 'svn update' case: RA will tell the
server, "I have PATH/BASE_REV/BASE_CSUM. Please give me REV of PATH,
deltified against that base." The server looks up path/rev and
verifies the BASE_CSUM. It then computes a delta to bring path/rev up
to REV and sends that down the wire, saying "apply DELTA to get
CHECKSUM". When RA receives it, it fetches the base contents
(previously queried as part of the request) and applies the incoming
delta. It verifies the resulting checksum against CHECKSUM. Assuming
that passes, it calls the Ev2 alter_file(PATH, REV, PROPS, FULL_TEXT,
CHECKSUM) to set the new contents.
Of course, there may be some other hand-wave going on in here. The
verification of CHECKSUM on FULL_TEXT might only occur if alter_file()
*consumes* the FULL_TEXT stream. It is entirely possible that
alter_file() says "bah. I already have a pristine corresponding to
CHECKSUM, so stream_close(FULL_TEXT)." Of course, we already fetched
the darned delta from the server, so part of the update report should
say "the new full text has CHECKSUM. ask me for a delta if you need
it."
.... you get the idea, I hope.
Cheers,
-g
Received on 2012-02-06 23:18:55 CET