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". > * About item 2.2. Would it be ok if we just have a easy revoke mechanism? > In Shim there is already a MokListX (a blacklist of keys or binary > hashes), but the current way to update this list is if the user has > physical access to the machine, but I was talking with the Shim upstream > maintainer and we agreed that we could implement a solution where we > could feed a blacklist to shim, and if this list is signed by the > vendor_cert (aka Debian's key in our case), and if it is a newer version > of the list, shim would update MokListX without requiring user > intervention (it would be an equivalent to KEK for UEFI) > Is this solution acceptable? If we have an easy way to revoke, then we > can easily undo an attacker's work. We can sign everything automatically > (if the package is in a whitelist) without the need for the ftp masters > to review each upload manually. I think we will need some sort of reliable mechanism to revoke signatures, however we implement signing. > * 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. 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. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein
Attachment:
signature.asc
Description: This is a digitally signed message part