Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Konstantin Ryabitsev: > On Mon, Nov 13, 2017 at 01:46:27PM -0500, Peter Todd wrote: >>> 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 >>>

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 2:38 PM, HW42 wrote: > Peter Todd: >> 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

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Peter Todd: > 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

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

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

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 01:59:41PM -0500, Jean-Philippe Ouellet wrote: > 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

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 01:46:27PM -0500, Peter Todd wrote: 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

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 1:46 PM, Peter Todd wrote: > 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,

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

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

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On 13 November 2017 at 13:29, Konstantin Ryabitsev wrote: > (If you're interested in how the kernel release process works, you can see my > talk from last year: https://www.youtube.com/watch?v=9ZIu3a3gocM) Looks like I gave the wrong link. Here is the direct one:

Re: [qubes-devel] (trying to avoid) unpacking before checking signatures

On Mon, Nov 13, 2017 at 10:28:15AM -0500, Konstantin Ryabitsev wrote: > On 08/11/17 10:51 PM, Jean-Philippe Ouellet wrote: > >I could of course verify the signature of the auto-generated > >sha256sums.asc file which covers all the files (including compressed > >ones), but that means trusting

[qubes-devel] (trying to avoid) unpacking before checking signatures

Hello, The way some things are distributed on kernel.org (e.g. util-linux [1], cryptsetup [2], etc.) is such that the authors upload .tar and .tar.sign files, and then the kernel.org infrastructure compresses those (creating .tar.gz & .tar.xz) and signs all resulting files (creating