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

On Wed, Nov 2, 2011 at 8:22 PM, Jochen Striepe <jochen@tolot.escape.de> wrote:

So I don't think those are *big* issues. Sure, you'd want the public key to be public for it to make any real sense to save, but on the other hand, they *are* generally public. Yes, yes, you might have keys that are only used - and only made public - within some particular organization, but in that case the source code that gets signed with those keys would tend to be private to that organization too, so..

And yes, keys get revoked or they expire, but that's still a pretty rare event, so it doesn't really invalidate the argument that making the original signed content available can quite often be useful - even if it's not guaranteed to *always* be useful.

No, my main objection to saving the data is that it's ugly and it's redundant. Sure, in practice you can check the signatures later fine (with the rare exceptions you mention), but even when you can do it, what's the big upside?

And there are much bigger real downsides, imho.

For example, let's say that we do eventually end up switching from SHA1 to SHA256 in git, and we do a full re-import of the tree. Guess what? All those signatures are now just so much garbage. Sure, you can recreate them (create some trusted script that you agree does a 1:1 transform, and re-sign everything), but in practice you can't ever really do that - because all those things are tied to the tree, so you need to have *everybodys* private keys in one place to do so. And the people who signed things initially would have to be insane to allow that.

So I'm actually of the opinion that "internal signatures" are bad design at a rather fundamental level.

In contrast, the "external signed tags" are fine: it's not just that there are much fewer of them, it's that they are *independent*. So you can easily re-generate the signed tags, because each signer can *individually* decide to validate the newly converted tree, and sign off on the fact that the conversion was done identically using new external tags with signatures.

This was one of the reasons I made the signed tags work the way they do. And it wasn't because I was extremely far-sighted and thought of all the problems that internal signatures have - it's because monotone had their internal signatures, and every other email on the monotone list was about all the problems it caused.

So see above - I just wouldn't worry about it. The possible few cases where it would occur are dwarfed by the cases where it *doesn't* occur, and those are the ones I'd concentrate on. They are the ones that need to be important enough that it's even worth carrying the random noise around.

Are they?

So I do think that there are real upsides at the *process* level where you can use the signatures to verify that what is pulled is pulled from the person you thought it was. I don't think anybody disputes those advantages. But outside of that I think it gets very gray, and there real disadvantages.

That said, I don't care *that* much. I don't mind polluting the merge commits with information that I don't think is really worth it. So I'd be willing to carry the signature information around, although I'd hope to minimize it and have some sane way to hide it.

            Linus