Re: [gentoo-dev] Re: rsync mirror security
On Mon, Aug 10, 2015 at 11:44 PM, Matthias Maier tam...@gentoo.org wrote: That is, I was under the impression signing a tag only signs the references themselves, and then relies on SHA1 referential integrity beyond that. No, a signed tag verifies that the whole integrirty of the entire repository, whereas a signed commit only authenticates the differences introduced by a single commit. As long as there are no conflicts, a signed commit can be rebased freely (especially also on top of malicious commits...). A signed commit and a signed tag are basically equivalent as far as authentication of the contents of the tree go. All a tag does is reference a commit by sha1, and a commit references the top level directory of the tree by sha1 in the state it was in when it was created. Sure, you can rebase a commit, but that doesn't actually change a commit. It creates one or more new commits in the place of a bunch of existing ones with new sha1s, and points the current head at the last one. If the old commits are no longer referenced by any other heads they will get garbage collected. If you point two heads at the same commit and do a rebase the history as seen by the other head won't change at all. Since a tag is just a label it is actually EASIER to tamper with than a commit. You can't change a commit without changing its hash. tags are referenced by name, not by hash, which is basically the whole point, so you CAN change the content of a tag and have it keep the same name. Of course, if you try to push/pull that new tag git is going to complain about the inconsistency, just as it does if you try to do a non-fast-forward push and so on. I don't think that having a bazillion tags or rewriting them constantly adds any security to the tree. What might add security for end-users is if git automatically checked the push signatures, which are the signatures that ensure that branches aren't tampered with (which is what rebasing you bring up actually does). -- Rich
Re: [gentoo-dev] Re: rsync mirror security
constantly adds any security to the tree. What might add security for end-users is if git automatically checked the push signatures, which are the signatures that ensure that branches aren't tampered with (which is what rebasing you bring up actually does). It is news to me that a signature from a push is also transported to a subsequent pull request for a client, do you have some external references for this procedure? Regardless of the technical implementation, the fact still remains that with the current git repositories (gentoo and the one populated with metadata from gentoo-mirror) we might have another way of providing a signed and tamper-proof [1] ebuild tree (apart from our daily, signed snapshots). Best, Matthias [1] At least as long our git infrastructure is not compromised... signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rsync mirror security
On Tue, Aug 11, 2015 at 10:53 AM, Matthias Maier tam...@gentoo.org wrote: constantly adds any security to the tree. What might add security for end-users is if git automatically checked the push signatures, which are the signatures that ensure that branches aren't tampered with (which is what rebasing you bring up actually does). It is news to me that a signature from a push is also transported to a subsequent pull request for a client, do you have some external references for this procedure? They're stored in the tree under the ref refs/push-certs. I have no idea how to go about verifying them - they're pretty new so there aren't a lot of docs. I had no idea they were even there until Robin answered a similar question I asked him. git ls-remote for those curious about what other refs are lying around. -- Rich
[gentoo-dev] Re: rsync mirror security
Users can fetch/pull from Github. We could also provide automatic signed tags every 30min/1h/2h/whatever (signed with a suitable infrastructure key). With that, the integrity of a tagged git checkout can be easily verified on client side. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rsync mirror security
On 10 Aug 2015 16:05, Matthias Maier wrote: Users can fetch/pull from Github. We could also provide automatic signed tags every 30min/1h/2h/whatever (signed with a suitable infrastructure key). With that, the integrity of a tagged git checkout can be easily verified on client side. it would have to re-use the same tag name every time otherwise we end up with 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea depending on how fast the process is, it could just be part of the receive hook on the server that does the checking now. that way the tag is always up to date with every push a developer makes. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rsync mirror security
On 11 August 2015 at 09:05, Matthias Maier tam...@gentoo.org wrote: We could also provide automatic signed tags every 30min/1h/2h/whatever (signed with a suitable infrastructure key). With that, the integrity of a tagged git checkout can be easily verified on client side. I'm distinctly under the impression that a signed tag doesn't really give you anything a signed commit wouldn't. That is, I was under the impression signing a tag only signs the references themselves, and then relies on SHA1 referential integrity beyond that. Hence, a signed tag basically is a statement proving X author authorized Y-SHA1, and then it subsequently implies that X author authorized whatever Y-SHA1 refers to. So adding additional tags *just* for the purpose of having a periodic signature would give no benefit over the all tags are signed, all commits are signed mechanism for git users, and the signed tag could _not_ be verified against an RSYNC clone. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: rsync mirror security
On 11 August 2015 at 15:06, Mike Frysinger vap...@gentoo.org wrote: it would have to re-use the same tag name every time otherwise we end up with 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea I was very much under the impression git is not designed with repeated tag replication in consideration. The git tag documentation very much implies that any tag having its reference changed will result in effort being required of everyone who wishes to consume that tag. ( It literally brands the act of re-tagging things to be insane ) Tags are very much intended to be immutable references to commits. If you need mutable references to commits, isn't that what branches are for? -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: rsync mirror security
That is, I was under the impression signing a tag only signs the references themselves, and then relies on SHA1 referential integrity beyond that. No, a signed tag verifies that the whole integrirty of the entire repository, whereas a signed commit only authenticates the differences introduced by a single commit. As long as there are no conflicts, a signed commit can be rebased freely (especially also on top of malicious commits...). Best, Matthias
Re: [gentoo-dev] Re: rsync mirror security
it would have to re-use the same tag name every time otherwise we end up with 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea Or we supply a signature of the sha1-sum of the tag in question by some external procedure... Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rsync mirror security
On 11 August 2015 at 15:44, Matthias Maier tam...@gentoo.org wrote: No, a signed tag verifies that the whole integrirty of the entire repository, whereas a signed commit only authenticates the differences introduced by a single commit. git tag -s test cat ./.git/refs/tags/test 456d216e3d1894d62429daf0ec482c3afb087dbe git cat-file tag 456d216e3d1894d62429daf0ec482c3afb087dbe object 9ca77ee7f72902e4e89456ff560a670465969603 type commit tag test tagger Kent Fredric kentfred...@gmail.com 1439264837 +1200 A test tag -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAABCAAGBQJVyXBKAAoJEOhUMksTZqgg2/kP/iCXS12W57RB2wPQHgebgSpK 86zXXvXC5rqndTmGwOmYA9FcO/n2u+SMwk0ZGol9LWuvkKaW/6Wi/vzvG24lggWy GxKRQTNHPXVHxwPQZOhj6fwS9EkC3rCSMWv82qLrbXvBqsH/dLXymq2nl+YDEGi1 lLkDWkX7EYWA6sgdnDhNzjPaHVC9P5qP1JDZOrKY0Qzm9JBDMl0xO9/faITrBMDi BmVVHNELKQ9uN8BYxmQfHqUFKO2SWXFbqJftQ6LqpXmFHWDpasmY3gTMczPpQ47I le+LPo0tT3Yk0fhBc8uk0/69kaHMa5hMmBPHuHh5ANWLPpxSyiDzCqqS9i8wPB+M MONhAoVyLYaFUf62fBxa6kxKDdQuC5JRYjeiFs60k1uG/QI4OhjoIbbaaxJxQ0sy 45iZ3PBlVxbgxkpPRJtftr9PJBMDabekZbI5F6jX7S+x6G40O4ss1W1QnXsdFvqd vJvVdIdnrGqu/6JXZpz2J65N3HfMqfj9PHNDJaxM6da6+z6HQ3JwvNSVum8dAaJn jKoisQ7bEuXl2WOj5SCfAqjtOUp2pbYJCCb5QVHWuHCk53cvcY6FmGQPEzj42uVQ bKSYGaJ3637t+NPysinifQv1HTfViP7lh/O3znsGj7qcm6DXGnHvkp84LFch6yiY /oFbaDvWZ8zKyMSAJ9Ou =Ieic -END PGP SIGNATURE- git cat-file tag 456d216e3d1894d62429daf0ec482c3afb087dbe /tmp/sigfile cp /tmp/sigfile /tmp/sigfile.asc *edits both so sigfile has content, and asc file has signature* gpg --verify /tmp/sigfile.asc gpg: enabled debug flags: memstat gpg: assuming signed data in '/tmp/sigfile' gpg: Signature made Tue Aug 11 15:47:22 2015 NZST gpg:using RSA key E854324B1366A820 gpg: Good signature from Kent Fredric (GMail) kentfred...@gmail.com [unknown] gpg: aka Kent Fredric (CPAN Author) ken...@cpan.org [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 3D96 B36C 8FEA AC54 F5A3 DAE7 E854 324B 1366 A820 gpg: keydb: kid_not_found_table: total: 1 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: secmem usage: 0/65536 bytes in 0 blocks ^^ - so its clear the signature is only on the tag data itself. And what does the tag refer to? object 9ca77ee7f72902e4e89456ff560a670465969603 What is that? git cat-file -t 9ca77ee7f72902e4e89456ff560a670465969603 commit So how is GPG verifying The whole repository ? -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: rsync mirror security
On Mon, Aug 10, 2015, at 22:56 CDT, Kent Fredric kentfred...@gmail.com wrote: So how is GPG verifying The whole repository ? You can verify the state of the repository via $ git fsck after that you can verify that the current HEAD is tagged with a valid and singed tag with something like $ git tag -v `git describe HEAD` This verifies the integrity of the whole history up to HEAD - at least if you consider sha1 to be cryptographically Best, Matthias PS.: I think I was mistaken with respect to individually signed commits - the verification seems to be stricter than I thought.
Re: [gentoo-dev] Re: rsync mirror security
On 11 Aug 2015 15:23, Kent Fredric wrote: On 11 August 2015 at 15:06, Mike Frysinger wrote: it would have to re-use the same tag name every time otherwise we end up with 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea I was very much under the impression git is not designed with repeated tag replication in consideration. git has no problem fetching rewritten tags. internally, it doesn't care either -- a tag is merely a reference to an object. The git tag documentation very much implies that any tag having its reference changed will result in effort being required of everyone who wishes to consume that tag. ( It literally brands the act of re-tagging things to be insane ) Tags are very much intended to be immutable references to commits. the git docs take the stance that publishing any mutable names is wrong. same goes for rebasing and publishing rewritten history. that's simply the recommended practice. it doesn't mean that the world blows up when you do rewrite things. If you need mutable references to commits, isn't that what branches are for? no, that's not what they're for. -mike signature.asc Description: Digital signature
