Secure boot signing infrastructure - feedback request

[Steve McIntyre]

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 at einval.com
"This dress doesn't reverse." -- Alden Spiess