Observation by Petr in issue1382, msg7413.

This requires a volunteer to study the code and figure out (1) where we think
we're performing the check and (2) whether it can be done earlier.

A good sanity check to begin with would be to take a patch bundle which we think
is corrupt and actually compare the hash to make sure.  If we do get a failure,
then we are more sure that this bug is legit

Attachments

• possibly-corrupt.dpatch.gz

For me, the hash check works.

A few days ago, I had a sudden urge to check if darcs still watches out for
malicious paths in patches. So I tried to craft a malicious bundle and I did
have to circumvent the hash check by changing the hash whenever I changed the
content.

Hi Reinier, did you mean that you tried checking the possible-corrupt bundle I
had attached?  If so, how?  I imagine I still need to chop off bits of the
bundle before I try something like the sha1sum utility.

Or did you just mean your malicious bundle?

The problem is not that the hash check is not done. The problem is that a bad
bundle will crash darcs before it tries to check the hash, leaving the user
puzzled as to what's wrong (while it could just say "bad bundle"). Getting a
"darcs failed: bug in ..." whatever is not so great.

Eric Kow <kowey@darcs.net> added the comment:
> Hi Reinier, did you mean that you tried checking the possible-corrupt
> bundle I had attached?  If so, how?  I imagine I still need to chop off
> bits of the bundle before I try something like the sha1sum utility.
>
> Or did you just mean your malicious bundle?

I just meant my malicious bundle.

Seems like we just need a volunteer/round-tuit to modify darcs apply so
that it complains about patch bundle hash mismatch first before trying
to do anything else.

Golly, that doesn't sound too hard.

Huh? We could not reproduce the hash check insufficiency.  We noted that 
if we do wibble the patch bundle hash to something else, we get a bad hash 
warning.  Are we sure this is really the problem here, at least for 
issue1382?