I think it boils down to a question of consistency; if a known developer who signs their commits suddenly starts submitting code that isn't signed that could act as a warning flag to identify potential breaches. As with all integrity mechanisms the point of them isn't to authenticate or authorise the user. We should be careful not to conflagrate the issues. As a core dev I suggest that all core devs sign commits to the master branch. On 13/06/2014 13:43, Kyle Marek wrote: > On 06/13/2014 08:29 AM, Rocki Hack wrote: >> Hi all, >> >> I'm the author of the post on github. >> >> I fully agree that signatures are good and we should use them, but >> signing all commits is missing the point that >> there is no more gain in security as if only tags / single commits are >> signed >> and as Linus Torvalds said it can cause serious trouble in merging >> with external sources (and more). >> >> We need to trust the contributors to the trunk at first (git is not >> all about accountability [integrity]). >> And as they are verifing the pull request / trunk, we all have to >> trust in particular the one who merge it. >> >> After verifing (by the trunk contributor) that everything is good a >> signed tag / commit is created (by the trunk contributor) and all >> referenced commits are automatically included in the signature. >> Then external contributor can verify that the trunk contributor >> actually did his job correctly and if so they can "trust" his >> signature in the future. >> External contributors do not need to sign with gpg, it's recommended >> that they only use "-s". >> >> So the whole point is to bring a real world meaning to our digital >> signatures [trust]. >> That is what Linus Torvalds means with make it worth less if you sign >> all commits. >> >> What do you think "Trust" is? >> I hope you carefully think about it. > I think that since the signature *doesn't actually sign the contents of > the commit* (as in the diff, or the SHA1 that git currently uses), *and > just signs the tag that states **who* committed the commit, that signing > one commit doesn't count as signing them all. The signed part of a > commit contains no information about the previous commits (not even > checksums). My viewpoint on signing commits is that the only thing they > help prove is *who* committed, and nothing more. So when one person > commits to their fork, and another person makes a signed commit that > merges the first person's commit into the repository, what's there to > prove that the first person actually is the first person and not a > hacker who had his git password? > > If I'm wrong about what's signed and unsigned, please politely correct me. > > ------------------------------------------------------------------------ > > At the time of sending this message, I have not been contacted by > any government official or worker regarding my participation in > CipherShed or any related project. I have not been asked to supply any > information to them that may be used to impersonate me nor have I been > asked to aid the government or it's officials or workers in modifying > part of CipherShed or any related project. I am not aware of any of my > property or anything regarding me being bugged, searched, or compromised > in any way. Anything that accepts PGP encryption or signing should have > been cryptographically secured with my PGP key. > -- -- At the time of writing, no warrants have been served to me, nor am I under any legal compulsion concerning the CipherShed project. I do not know of any searches of seizures of my assets.
Attachment:
signature.asc
Description: OpenPGP digital signature
