Linus has a point, but it's not without flaws. Linus is saying that it makes you complacent, and doesn't prove anything about any release, and that you should s

Linus has a point, but it's not without flaws. Linus is saying that it makes you complacent, and doesn't prove anything about any release, and that you should sign golden commits. He says this because only what is shipped needs to be trustworthy; and the value of a signature degrades with the more things it signs. This raises the question, though; how do you know when you reach that golden commit? Is the signer responsible for auditing every commit since the last signature, every line of code? If he doesn't, what does the signature prove? That's what Linus has wrong; The signatures aren't about proof, they're about audit trail. For Linus and the kernel.org use case, this isn't necessary. They've already built tooling, and most importantly structure around the code auditing. Every commit that goes into the mainline is somewhat audited by Linus himself. There's a whole layer of competent release engineers in front of him. Code doesn't make it onto the kernel.org repos without having been trusted by a very select group, and doesn't get pulled to master without the word of God. I suggest, for the average developer, having two keys. One online, to verify that the commit was developed on your computer. One offline, that is only used for releases. One for audit trail, one for golden.