On Mon, Nov 13, 2017 at 02:01:24PM -0500, Konstantin Ryabitsev wrote: > >I do agree that theres more potential for a change in git to be noticed, but > >I > >have to wonder how much that's actually true in practice? A backdoor can > >easily > >be a one character code change, and that's rather difficult to spot. > > It isn't nearly as difficult to spot when it's a part of a git commit, > because it will stand so much more in a diff than it would inside a 600MB > tarball. :)
Yes, we agree one has a 0% chance of being noticed; the other has a 0% + epsilon chance. :) > Yes, "git archive" will generate deterministic tarballs -- at least if git > versions are fairly close together. This has broken a couple of times in the > past, but in both cases the changes in git were rolled back because it was > judged that having a mechanism to have deterministic tarball generation was > more valuable than having "more correct" tarballs. Good to hear! > >I might be misunderstanding how all this works, but maybe what we actually > >need > >here is a new type of tarball signature verifier, that takes the GPG > >signature > >from the signed git commit, and verifies that the tarball matches the tree > >that > >the git commit signed. It should be possible to do this with just the tarball > >and part of the git commit if the tarball is in fact deterministically > >generated from the Git commit. > > You can do this right now -- it would be a 5-line script, honestly, but > would still require unpacking the tarball and ultimately you will not really > gain anything that you don't already have right now by comparing to the .sig > file provided by Linus or Greg. It already assures you that the tarball > you've downloaded was generated directly from a git tree that is identical > to the git tree on the developer's workstation. Alright, sounds like I had a misunderstanding of how this all worked. If I understand it correctly, you're able to provide a signature on a tarball that's signed directly from the developer themselves, from a tarball they personally generated. We also have a mechanism to deterministically regenerate those tarballs from the git commits they were supposed to have been generated. In this scenario, once we get past the problem of uncompressing the tarball - which I think is adequately addressed by doing that in a DispVM as the OP suggested - we do in fact have a signature directly from the developer on that tarball with no additional trust dependencies, and we can deterministically check it against the git commit it was supposed to have come from as well to make sure it matches the reviewed code in git. Sounds good to me! :) -- https://petertodd.org 'peter'[:-1]@petertodd.org -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20171113191514.GB22972%40savin.petertodd.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
