Communication about shim/SB development is not working well

[Steve McIntyre]

[ Mail sent to the EFI list and in BCC to others who I believe may be
  interested. Apologies if you're not interested or if you receive
  more than one copy... ]

Hi folks!

I think it's way past time we had a discussion about how we're
communicating around shim/SB development and maintenance. Most of the
recent discussion I've seen has been in a closed environment (keybase)
and I have a strong conviction that it's not working well enough for
us. *Please* don't take this as me pointing fingers of blame at
anybody here, I'm just trying to make things better for us.

Right now, I can see three related issues that are causing real
problems for many of us. There are probably more!

1. Keybase is *awful* for keeping track of discussions

   As YA re-implementation of IRC, I think that keybase is just about
   usable for ad-hoc real-time conversation. As an old-timer who
   prefers plain text (*grin*), it has a number of places where it
   annoys me, but that's not the issue I want to raise. The problem is
   that it's way too easy to miss *really* important messages in the
   flow of conversations. There's no attempt to thread things, so
   context gets lost. If there are a few conversations going on and
   you're not watching the keybase window *constantly*, you'll miss
   things.

   As a key example of this problem: I've just submitted Debian's
   reviews for 15.4 at the weekend and we're now waiting on signed
   binaries to come back. Until Julian just pinged me in irc
   separately, I knew nothing at all about yesterday's reported
   problem with older Mac machines
   (https://github.com/rhboot/shim/pull/364). In my opinion, this is a
   show-stopper for us in Debian as we tend to have quite a large user
   base on older machines. I'm going to have to go around the
   build/test/submit loop again. At this point I genuinely don't know
   if I've missed any other similarly-important issues that I should
   be aware of, and that scares me.

   If we *do* need private conversations, then keybase is a reasonable
   place. As a place to share private git repos (e.g. for
   collaborating under embargo), that's a major selling point. But for
   longer discussions about day-to-day development it sucks badly. I'm
   on the verge of rage-quitting.

2. Discussions in keybase are not open

   We've got a load of shim reviews outstanding for various distros
   and tool vendors. We had even more until recently, with lots of
   people still asking for reviews/sigs on older versions of shim that
   we know we can no longer support. Unfortunately, lots of these
   people were given no clue as to what was going on. The first time
   that the new requirement to move to 15.3^W15.4 came to light for
   most of these people was when we started closing months-old
   reviews.

   Right now, I think we have a few 15.4 submissions that are not good
   enough for our standards. Those of us who've been reviewing those
   submissions have been giving guidance on what's needed and I *hope*
   we're helping. But there's no publically-shared information about
   the patches we'd recommend on top of 15.4, for example. We're not
   helping ourselves here.

3. Lack of persistent documentation about how to manage SB

   I know many of us have written user-facing documentation about what
   Secure Boot is, the basics of how it works, etc. But at the higher
   level, we don't have any docs at all to recommend how to do things
   *as a vendor*. I've spoken before about writing up some "best
   practices" docs and I still volunteer to do some of that (with help
   please!) but we don't yet have a space for this. We should probably
   include recommendations on lots of things: key management, which
   tools to use (and why!), how to test things, etc. This area of
   FLOSS is a minefield - IMHO it's still far too easy to make
   mistakes that can have very bad consequences. Let's be honest, the
   learning curve here is basically vertical. We should make this
   better.

Proposals
=========

So, what do I propose to fix these issues I've listed?

1. Open mailing list(s) with public archives

   I've already set up an EFI mailing list [1] and linked to it a few
   times. Yes, I'm hosting that list. I'm not precious about that,
   however - if people would rather move it somewhere else, or use a
   discourse instance, or *something* then that's OK. But IMHO it has
   to be something with *persistence* and *threading* so that we have
   a chance of tracking detailed conversation today, and
   yesterday. And also from three weeks ago when some maintainers were
   on vacation, or from six months ago to allow new subscribers to
   learn things. You know what I mean.

   We can encourage *all* shim maintainers to join up on the list and
   see what's going on. We should probably have an -announce list for
   new shim versions, etc. Maybe a -test list for testing reports?
   Sorry, maybe getting carried away. :-)

   I'm *not* really thinking about these being list(s) for end-users,
   but more a place to help us work together better and make sure that
   SB in Linux is a good experience for those users. We *definitely*
   should be sharing our problem reports here, for example.

   [1] https://lists.einval.com/cgi-bin/mailman/listinfo/efi

2. Wiki for docs

   There's nothing magic here - we can just start using the wiki
   feature of the existing shim repo on github. Any objections to
   that? If you have better suggestions, then let us know please!

What's next?
============

Responses welcome! If you think I'm wide of the mark here, please say
so. If you think I've missed something, ditto. If you'd like to run
the documentation project, please say so and tell me where to send the
beer! :-)

Cheers,

Steve

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
“Rarely is anyone thanked for the work they did to prevent the
 disaster that didn't happen.”
   -- Mikko Hypponen (https://twitter.com/mikko/)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.einval.com/pipermail/efi/attachments/20210420/5ee731ed/attachment.sig>