Re: [Monotone-devel] Re: partial pull #3 - calling conventions

[Christian Ohler]

Lapo Luchini, 2007-05-26:

> Space is not the scarce resource here (well, not the most important one,
> at least, IMHO): time is.
> Pull time is not only a question of size, it's also (mainly?) a question
> of the time taken by the multiple hash and signature verifications.

Ok.  Still, verifying signatures on 10MB worth of data is very likely 
faster than verifying them on 71MB worth of data.

Assuming that cryptographic verification is what's really taking too 
long at pull time, maybe we shouldn't be doing it at pull time? 
Wouldn't it be possible to defer the verification of each file's hash, 
each revision's id, each cert's signature etc. until the respective item 
is accessed for the first time?

Obviously, if monotone allows unverified data in its database, there 
would be a new kind of failure: Information that was assumed to be 
available might turn out not to be.  For example, if a malicious server 
sends a bogus manifest to a monotone client claiming that this manifest 
corresponds to a certain revision id, the client might detect later on 
that the manifest doesn't actually hash to that id.  So the client would 
have to discard the revision.  But that's no worse than a gap.  In fact, 
it's much simpler to deal with than a gap since monotone wouldn't have 
to handle such a situation particularly gracefully.

Or is all of the cryptographic verification that monotone does during 
pull really needed at that time due to security considerations (e.g. to 
ensure that the server doesn't perform a DoS attack on the client by 
sending an infinite chain of junk revisions)?

Christian.