On Mon, Nov 13, 2017 at 01:29:15PM -0500, Konstantin Ryabitsev wrote: > >The thing is developer workstations are *already* trusted, because if those > >workstations are compromised they can compromise the code itself, which in > >practice is quite difficult to effectively audit. So why add an additional > >trusted entity when you already have one? > > I would argue the point you're making here. Compromising code that is headed > for git repositories is significantly more difficult than code that is going > into a tarball. A malicious commit going into a git repository at least has > the potential to be reviewed and analyzed (and will almost certainly be > noticed if it lands in the Linux kernel repository). However, a 2-line > change somewhere deep in the released tarball will likely never be noticed > without someone actually checking for such sneaky changes.
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. > If I were an attacker in control of a developer workstation, I would target > specifically tarballs -- I would make use of the race condition between when > "git archive" completes and when the gpg sign command is invoked to > substitute the generated tarball for a malicious one. > > >That said, with deterministic builds you can get the best of both worlds: > >build > >on both kernel.org infrastructure and dev workstations and only release if > >the > >builds match 100% > > It's not quite what we do, but the process of releasing a kernel does not > rely on us accepting tarballs from Linus or Greg. Instead, we take the git > tree reference, the tarball prefix, and the gpg signature -- and then > generate the tarball on our end. If the signature we received successfully > verifies the tarball we generated on our end, that means that our git tree > is identical to Linus's (or Greg's) tree, and therefore we can trust our > generated tarball. When you say "GPG signature", do you mean the GPG signature on the git commit? Or is this a GPG signature on a tarball? > This was written as a convenience, not as a security check (Linus oftentimes > goes diving to remote parts of the world and does not want to spend most of > his day uploading 600-megabyte tarballs over bad connections). However, it > also acts as a useful double-check to verify both that git repositories on > our end do not differ from the ones on Linus's workstation, and to make sure > "use a race condition to sneak in a trojaned tarball" attack cannot succeed. > > It is my intent to deprecate the ability to upload tarballs entirely and > force everyone to use the same process Linus and Greg use to generate > tarballs on our end and then use the provided signature to verify it. That process to generate that tarball is deterministic right? 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. -- 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/20171113184627.GA22583%40savin.petertodd.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
