Re: [git patches] libata updates, GPG signed (but see admin notes)

On Fri, Nov 4, 2011 at 7:59 AM, Ted Ts'o <tytso@mit.edu> wrote:

No they won't. Not if you do it right. It's easy enough to automatically replace the SHA1's in the description, the same way we replace everything else.

Really.  It's *trivial*.

Maybe some current tools don't do it, but if I were to convert the kernel tree, I'd absolutely *require* the conversion to be done right. And "right" means "don't just get the parent SHA1's right, but the ones hiding in the description too".

Any conversion tool has to keep track of the translation from "old SHA1 to new SHA1" *anyway* because of all the other issues (ie exactly things like parent pointers etc), so conversion tools by definition have the information to do things like this right.

But "internal cryptographic signatures" are fundamentally different. A conversion tool *cannot* convert them, since it won't have access to the private keys in question, and thus cannot fix up the signature.

Sure, if I do the conversion, I could make *my* signatures match. And that is true for every signer out there - individually. But only individually, never collectively. Sure, we could all meet in one place and synchronously re-sign things on our private machines with some "distributed conversion tool", but realistically that really really doesn't work.

It's a fundamental problem. And it really isn't a theoretical one - it's one we know will happen *some* day.

I haven't worried about SHA1, exactly because I know it's not a real problem - we can always convert. But internal signatures very fundamentally change that.

And it really is about *internal* signatures. The kinds of signed tags we have now are not a problem. Those can trivially be converted in a distributed manner, exactly because they are "detatched" from what they sign. We carry them along with the git repo, but they don't mess up history, and they can be re-created individually without changing anything else.

And yes, this was actually a design issue for me, which is why I feel so strongly about it. I actually *thought* about issues like this five+ years ago: I wanted to have cryptographic security, but I very much on purpose wanted it to be "outside" the repo.

(Ok, so the git tag objects can sign other git tag objects recursively, and in that case you have an ordering issue where a conversion would first have to get somebody to re-sign their "inner" tag before the "outer" signature can be re-created, but even if that were to happen - and I don't think anybody does it - it's a trivial problem with no real complexity issues).

I agree that we can hide them - that's after all what the pgpsig thing does in the "internal commit signature" that git has in pu/next. That one hides ie even more specifically, by putting it in the headers of the commit, but that's just a random implementation detail.

But I really think that "internal signatures" that actually affect the SHA1 of the object and its history have fundamental design problems. They may not be "insurmountably bad", but they are definitely real.

                        Linus