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. [email protected] "This dress doesn't reverse." -- Alden Spiess
