Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #59481

Re: Secure boot signing infrastructure - feedback request

From Steve McIntyre <steve@einval.com>
Newsgroups linux.debian.kernel
Subject Re: Secure boot signing infrastructure - feedback request
Date 2017-11-23 17:30 +0100
Message-ID <uP2xY-7IA-13@gated-at.bofh.it> (permalink)
References (2 earlier) <uyJfZ-5Uo-9@gated-at.bofh.it> <uyKF3-74D-13@gated-at.bofh.it> <uzTPY-2RZ-21@gated-at.bofh.it> <uzTZT-34a-445@gated-at.bofh.it> <uOMjw-5PN-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Nov 22, 2017 at 11:07:02PM +0000, Ben Hutchings wrote:
>On Wed, 2017-10-11 at 21:48 -0300, Helen Koike wrote:
>[...]
>> I did a summary about the current discussion here:
>> https://wiki.debian.org/SecureBoot#Wrap-up_of_the_discussions_so_far
>> Feel free to edit this wiki or let me know if I forgot something.
>> 
>> Questions:
>> * About item 2.1. (reproducible builds), if we strip the signatures from
>> the binaries before doing the comparison is the reproducible build
>> criteria acceptable? Can we just strip the signatures and if the result
>> is the same we consider it reproducible? Or is changing the criteria ok?
>
>The Reproducible Builds project has consistently set the standard that
>results must be bit-for-bit identical.  I don't think we should expect
>it to add an exception that requires parsing archives and executables
>to verify that they're "mostly reproducible".

So there are always going to be things that *can't* be reproducible
then. Anything with signatures directly applied is fundamentally
incompatible with that standard. Meh, I'm not going to lose any sleep
over it.

...

>> * Item 2.4 seems the strongest argument to me against the buildd
>> approach, but the byhand approach seems to complicated, or we need to
>> reformulate it, any suggestions?
>
>I think that it should be possible to mitigate these problems by
>combining the proposed signing service with the earlier plan of doing
>two source uploads:
>
>Firstly, the signing service would not provide the signatures in plain
>text but would encrypt them using a developer's GPG key (or multiple
>keys).  Key selection might be done by specifying the key fingerprint
>in the source package (which could be problematic for binNMUs), or in
>the signing service configuration (which would effectively prevent
>source NMUs).  This makes the signing service useless to an attacker
>who only compromises a buildd briefly.

OK, that sounds like a more useful compromise.

>Secondly, the detached signatures would be uploaded as an extra package
>to a separate archive suite, similar to the way debug symbol packages
>are now handled.  Those extra packages could easily be ignored when
>attempting to reproduce the build.  But I don't know whether dak's
>logic for debug symbol suites is sufficiently general to handle this.

Pass. Ansgar?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"This dress doesn't reverse." -- Alden Spiess

Back to linux.debian.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-05 20:30 +0200
  Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-09 03:20 +0200
  Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-10-09 15:10 +0200
    Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-09 18:40 +0200
      Re: Secure boot signing infrastructure - feedback request Julien Cristau <jcristau@debian.org> - 2017-10-09 18:50 +0200
      Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-10-09 20:10 +0200
        Re: Secure boot signing infrastructure - feedback request Ansgar Burchardt <ansgar@debian.org> - 2017-10-13 00:10 +0200
          Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-10-13 00:20 +0200
            Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-31 17:00 +0100
              Re: Secure boot signing infrastructure - feedback request Helen Koike <helen.koike@collabora.com> - 2017-11-15 14:50 +0100
                Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:20 +0100
                Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-11-23 17:30 +0100
              Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:10 +0100
            Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-23 00:10 +0100
              Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-11-23 17:30 +0100
          Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-22 23:10 +0100
            Re: Secure boot signing infrastructure - feedback request Tollef Fog Heen <tfheen@err.no> - 2017-11-24 21:00 +0100
        Re: Secure boot signing infrastructure - feedback request Steve McIntyre <steve@einval.com> - 2017-10-13 00:50 +0200
          Re: Secure boot signing infrastructure - feedback request Ben Hutchings <ben@decadent.org.uk> - 2017-11-22 23:20 +0100

csiph-web