[Monotone-devel] Re: Problem with keys handling in monotone

[graydon hoare]

Lorenzo Campedelli wrote:

> while trying to locally use the new netsync feature of
> monotone  0.10, I think I found a problem in key
> management.
> It looks like the keydata field in the public_keys
> table
> was stored with the trailing CR in 0.9, and without it
> in 0.10. This causes a different computation of the
> hash field in the same table depending on whether the
> key was generated on 0.9 or 0.10 versions.
> You can reproduce the problem following the steps
> found in the attached file.

yes, I'm aware of this fault. christof petig ran into it already. there 
is, as far as I'm aware, only one instance in which this is a problem: 
when you initially migrate your database from the 0.9 schema to the 0.10 
schema, the initial hash value calculated is wrong. 0.9 didn't actually 
store key hash values, that was introduced in 0.10. it's just the 
migration function which makes a mistake (it doesn't strip whitespace).

you need to issue "monotone reindex <collection>" to trigger a full 
re-hashing of all contents and rebuilding of the merkle trees for 
<collection>. anyone who wants to play with netsync on an existing 
database will need to do this. it doesn't matter which collection you 
name, I usually just have it build a collection for my default branch 
net.venge.monotone.

I have marked an entry in the BTS to do a full review of all the uses of 
base64-encoded content (the base64 encoder breaks lines and inserts 
whitespace).

> Is it correct to send directly to you this kind of
> reports, or should I write to the mailing-list?

you can mail me or the mailing list. I tend to prefer the mailing list 
-- and/or the bug tracking system, don't be shy about flooding it with 
reports -- so the issue is archived in public and we can track it. also 
please do not mail me at work (@redhat.com) since I am only allowed to 
work on monotone on my spare time. my @pobox.com address is best.

-graydon