Proposal: UEFI secure boot implementation sprint, early 2018

[Steve McIntyre]

[ Mailing various interested folks directly, and adding a CC to the
  relevant lists and the DPL. If you think I've missed people off,
  please let me know - my intention is not to slight anybody here. ]

Hi folks,

We've had more discussion over the last few days about how we
could/should implement UEFI Secure Boot infrastructure in Debian
[1-4]. I hope that we've got past the "should we do this or not"
diversions. It's time that we got together to finish the discussion
and get things up and running.

We've had several proposed routes to make the infrastructure work:

 * "byhand" or similar, driving things from ftpmaster getting the
   package maintainer do the work to combine unsigned binaries with
   sigs then upload again

 * "dh_sign", driving things from the maintainer scripts running on
   buildds, uploading automatically to the archive

 * a hybrid of these: driving things from buildd, but returning the
   sigs to the maintainer (somehow) to combine and upload

There are pros and cons and for all routes, but I believe that it
should be possible to work together to design something that will do
what we need without triggering too many objections or security fears.

Sprint proposal
===============

I propose that the interested people get together for a sprint *in
early 2018*. We should have the following people to *agree a design*
and *implement* that design:

 * (at least one) DSA member, able to do sysadmin-level things
   needed. Tollef and Julien have already been working in this area
   and understand what we're trying to do.

 * (at least one) ftpmaster, able to implement and/or review any
   needed changes in dak. Ansgar, Joerg and Luk have been involved in
   discussions already and understand the problem space.

 * (at least one) buildd software maintainer, able to implement and/or
   review any needed changes in the buildd stack.

 * maintainers of the packages that we expect to use the
   infrastructure (Linux kernel, grub, fwupdate), so we can work
   through example uploads and test things. Ben obviously covers the
   kernel side, and I have access for the grub and fwupdate packages.

 * Helen has been the primary developer working in this area so far,
   providing code for two of the proposals so far and helping to drive
   discussion. She should be there!

I expect that 3-4 days together should be enough for us to make this
work. To be honest, I'd hope that 2 day might be enough for what we
need, but 3-4 days should give us sufficient time to experiment and
play with things. We don't *have* to have everybody together
physically in one place, but experience tells me that would be by far
the most effective and efficient way to do things.

So... Please respond with:

=====================================================================
 a) your willingness to take part in this sprint
 b) your availability to travel for this sprint
 c) ideas on when/where we could meet up, if you have any
=====================================================================

and we'll get something sorted out. My own preferences would be to try
and arrange something in January (maybe) in Europe (as most of the
people are in Europe!), but those are not hard and fast. Maybe Germany
to make it easier for Joerg/Ansgar to join us?

If we don't have this done by the end of March, I don't think we'll
ever get Secure Boot in Debian.

@lamby: adding you in CC early for sprint budget approval. Clearer
details to follow!

[1] https://wiki.debian.org/SecureBoot#Wrap-up_of_the_discussions_so_far
[2] https://lists.debian.org/debian-efi/2017/10/msg00029.html
[3] https://lists.debian.org/debian-efi/2017/11/msg00007.html
[4] https://lists.debian.org/debian-efi/2017/11/msg00008.html

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
            handing rope-creating factories for users to hang multiple
            instances of themselves.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20171124/522e6160/attachment.sig>