Signing snapshots
Aaron Bentley
aaron.bentley at utoronto.ca
Wed Jun 22 21:33:56 BST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John A Meinel wrote:
>> No, the way I'd do it is by not signing the inventory file-- sign the
>> inventory data instead. As a straw man, you'd sort it by unicode
>> codepoint, then write out a space-delimited inventory summary with id,
>> name, parent, type and contents-hash(if applicable) fields for each
>> entry. The format doesn't need to be parseable, just unique for each
>> tree.
>>
> Actually, you are missing an important point. What algorithm is used to
> generate "contents-hash" if not a hash function. Which means that if you
> upgrade you hash algorithm, suddenly all of those "contents-hash"
> entries change, and you need a new signature.
No, I understand that contents-hash is generated by a hash function, and
what that implies.
What I'm talking about is the comparability of two trees. It would be
nice if you could say 'if the tree's SHA-1 hash is not $foo, it is not a
true copy of this tree'.
> This really isn't any different from signing the <inventory> XML. The
> only trick is that you would want to be careful that the <inventory>
> tree would always be sorted in a specific way.
Actually, you need to normalize the data, not merely sort it. We can't
have whitespace changes or use of entity references affecting the
results. XML is tricky to normalize, so the strawman is about a format
that's got only one form and needs no normalization.
> Revfiles don't use a text_id, though you could arguably generate an
> text_id since it is necessary for the plain file storage, and just not
> make use of it in a revfile storage.
Eh? Are you sure revfiles don't use text_ids? How else do you refer to
the file contents in a text store?
> Also, keep in mind that you also want to sign the fact of the name of
> the committer, and the timestamp, and whatever other meta information
> you might have for a specific snapshot.
This was about how you hash the tree, not how you hash the revision.
Yes, a revision hash would have a tree hash, whether the current
inventory_sha1 or something else.
> Oh, if we start tracking file
> meta data (possibly inside the inventory file, possibly somewhere else)
> you also want to sign that. If someone is tracking the permissions of
> /etc, they don't want someone to be able to hack in and change it so
> that /etc/httpd/ssl/server.key is suddenly world readable.
Yep. There's plenty of room to tune the format.
> I understand your desire to be able to generate the signed text through
> some other process, and have it still satisfy the signature. But realize
> that as soon as you change hash algorithms, the old signature is
> invalidated.
No, I don't see that. You can always generate the hash using a specific
hash algorithm, if you want to compare to an old signature.
> But also be aware that there is a very positive benefit to signing the
> exact contents of a file. It is trivial to verify using external tools.
That's true.
> Also, it is certainly possible that someone hacks the bzr code such that
> it starts to say ignore certain files when generating and checking
> signatures. Because the thing which is signed is never actually visible,
> and not actually used anywhere else, it is very difficult to detect that
> this is happening.
It's trivial if that data comes into contact with an unhacked bzr.
> (Think of a company where people use an "recommended" bzr, or all use
> the same bzr on the same machine).
Yes, but if you assume 've been rooted, you've lost your security,
whether bzr gets replaced or bash or diff. End of story.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCucsz0F+nu1YWqI0RAh7NAJ9ebuh0/IE5xEFPwfpmxTDXIcFxTACeJA3e
7SewejVaJRSi/7nMmEnlMMY=
=2kyC
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list