Nearly three weeks later with no responses. Let's see if we get things moving... On Wed, Oct 11, 2017 at 09:48:46PM -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. I think it's a fair summary, yes. >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? I *personally* believe that being able to remove the signatures and compare binaries is fine for reproducibility purposes. Arguments otherwise would help here. >* 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) ACK. >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. Right. Wanting to go the revocation route would depend on the development of yet more new software features. But: this is not something that any of the other SB-supporting distros seem to be caring about so far so I don't think it's something we should have to implement as a pre-requisite. >* 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? We've been discussing Secure Boot for ~5 years now, and I think it's an important feature that we should support in Debian. Does anybody here disagree with that? Multiple people have spent time designing and implementing pieces of the solution to make it work in Debian's infrastructure, but we've yet to make any progress in actually *doing* it. We've had a suggestion (and initial patches) to do this via "autobyhand" scripts on ftp-master, but we've finally seen public objections to that design from ftpmaster. Ben's hopes for that route seem unrealistic too, in terms of manual processing and checking. As a second option, in a discussion with Joerg (remotely) and Luke at DebConf, we thrashed out what we thought was a reasonable alternate solution to drive signing via the buildds instead. Ben has voiced some concerns about the security of that path (extending the attack surface for signed binaries) and reproducibility. So, we're at an impasse. We've had multiple attempts to get this going, with various subsets of this group discussing designs but not *all* the interested parties at each point. We've seen (effective) vetos of each of those designs, meaning we're stalled. Where do we go from here? I appreciate that some folks might feel slighted that they've been left out of some of the discussions. If so, sorry - that was not intentional. :-( Can we put that behind us and work together to make a workable solution please? I propose a sprint to get things moving. I'm prepared to organise it, and facilitate as much as I can. I recognise that not everybody might be able to (or willing to) attend in person, but I don't think that should be a barrier to constructive discussions. Thoughts? -- Steve McIntyre, Cambridge, UK. steve@einval.com Who needs computer imagery when you've got Brian Blessed?
Attachment:
signature.asc
Description: PGP signature