[conspire] Linux Foundation new open source software signing service vs signed firefox extensions vs TPM vs signed bootloader vs ...

Rick Moen rick at linuxmafia.com
Sun Mar 14 23:28:36 PDT 2021


Quoting Ivan Sergio Borgonovo (mail at webthatworks.it):

> Since we were talking about security of the software supply chain...
> 
> https://www.zdnet.com/article/linux-foundation-announces-new-open-source-software-signing-service/
> 
> Why requiring firefox extensions to be signed is a bad idea while
> Linux Foundation idea is good and secure boot is so and so...
> 
> I've a rough idea about what's the difference but I've yet to fully
> rationalize it, but maybe someone here has clearer, pre-cooked
> thoughts.

I've just now quick-skimmed the LF page about this sigstore project,
which _may_ be enough understanding to answer your question about this
vs. the Firefox thing.  It probably isn't enough understanding to 
fairly evaluate sigstore more generally.

In a nutshell:  The two proposals are alike in creating single points of
control/vetting, but appear to differ (at least, in current
implementation) in their coercive effect.


The essence of the Firefox thing:  Mozilla, Inc. decreed that the
Firefox browser codebase starting with Firefox 48 on 2016-08-02 would
refuse to run any extension not cryptographically signed by Mozilla,
Inc. at addons.mozilla.org .  They posted sundry justifications, omitted
here.  That code change applied to Release Edition and Beta Edition.
At that time, it could be averted by sticking to ESR Edition, Developer
Edition, nightly builds, or unbranded builds, all of which permitted 
switching off the requirement for code-signing in about:config.  I'm 
unsure how available those escape routes remain, five years later; I
suspect 'not much'.

Point is, though, that no facility existed for a user to add his/her
developer key to the browser's "trust what's signed by these people"
keyring, making Firefox 48+ somewhat less than open source, in a
disturbing way.  Granted, sufficiently motivated user communities 
could maintain a patchset to apply a fix, since the Firefox source 
remains MPL v2.  (I wish that would happen, but of course dev
time/effort cannot just be wished into existence.)

So, to sum up, the Firefox situation is coercive unless and until some
group of ticked-off developers maintain a persistent and practical 
patchset to field-correct Mozilla, Inc.'s policy -- in that running
one's own choice of extensions is impractical without Mozilla, Inc. 
authorisation.


The essence of LF's sigstore thing:  LF is designing software tools for
better (they hope) source & binaries code-signing and proposing to
operate a signature repository w/signing infrastructure available to 
sundry open-source coders.   

The details of this are being worked out.  Consequently, there's no 
indication at this early stage that anyone's setups will refuse 
by policy to accept source or binaries unsigned at the sigstore
canonical repository (which doesn't yet exist).  So, nothing like the
Firefox 48+ situation exists or _can_ exist at this early stage.

Extending just a bit of generosity of spirit:  I think it rather likely
that LF, despite its corporatist and bureaucratic nature, will create
only genuinely open source toolsets for this purpose, and will do its
best to make 'how to set up/run your own sigstore' as painless a task 
as possible.  So, I see no reason, at this point, to object.





More information about the conspire mailing list