As I wrote someone earlier... It would be easier to just sign the git revision hashes at various intervals. Such as explicitly including the revision hash that each release is made from in the release docs itself. And then signing that release. That way everyone... git repo maintainers, devels, mirrors, users... can all verify the git repo via that signature. Of course the sig key material needs to be handled in a sanitary way, but still, it's the idea that matters. And git, not svn, would need to be the canonical repo committers commit to, etc.
Thanks for Tor. ---I could imagine that they might try to sneak in a commit to the git repository. We have a hook that mails all commits to the mailing list, and we watch that pretty well. But they could disable the hook during their commit. As I mentioned in the earlier mail, the git tree is made up of hashes, so they can't just modify it outright. I've looked over the 'git log' output, and didn't find anything odd. It might be neat to do an automated comparison of "mails that made it to the mailing list" vs "commits to the git repository", if we wanted another layer of checking. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
