Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #59481
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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