The Linux Foundation's "sigstore" project

[Posted March 10, 2021 by corbet]

The Linux Foundation has announced a project called sigstore; its purpose is to protect against supply-chain attacks by signing (and verifying) release artifacts. "Very few open source projects cryptographically sign software release artifacts. This is largely due to the challenges software maintainers face on key management, key compromise / revocation and the distribution of public keys and artifact digests. In turn, users are left to seek out which keys to trust and learn steps needed to validate signing. Further problems exist in how digests and public keys are distributed, often stored on websites susceptible to hacks or a README file situated on a public git repository. sigstore seeks to solve these issues by utilization of short lived ephemeral keys with a trust root leveraged from an open and auditable public transparency logs."

to post comments

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 15:04 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (24 responses)

The content of the sigstore website, is unreadable without downloading and running at least one nonfree program in your browser

https://cdnjs.cloudflare.com/ajax/libs/modernizr/2.8.3/mo...

Requiring people to run arbitrary javascript, which could compromise the computer if there exists one of many security holes, is not the right way to start for securing software distribution.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 15:09 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (17 responses)

> The content of the sigstore website, is unreadable without downloading and running at least one nonfree program in your browser

That Javascript is not non-free.

https://github.com/Modernizr/Modernizr

Minimizing it in this case is just an optimization for faster loading.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 15:51 UTC (Wed) by Rigrig (subscriber, #105346) [Link] (16 responses)

I'm not sure "You can find the source somewhere online" qualifies as free software.

What really annoys me though is that this could just have been a plain HTML page.
And it is.
But then someone used CSS to stick a "preloader" in front of the whole page and added some javascript (which depends on a bunch of external javascript libraries) to hide the loader after some delay.
So the only way to read it is to either run a bunch of external javascript blobs, or to also disable stylesheets.

And I think that a project which aims to improve the supply chain could have bothered with providing checksums for those external blobs: https://en.wikipedia.org/wiki/Subresource_Integrity

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 16:27 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (14 responses)

> I'm not sure "You can find the source somewhere online" qualifies as free software.

Sure it does. It is not ideal but just because you don't see the full source directly in the browser doesn't make it somehow non-free.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 17:29 UTC (Wed) by jebba (guest, #4439) [Link] (13 responses)

The license for it says:

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

https://github.com/Modernizr/Modernizr/blob/master/LICENS...

Wouldn't the license info need to be included? Just curious.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 19:39 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (12 responses)

They ideally should include a copy of the license. That practice is far from universal as we see here.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 20:21 UTC (Wed) by jebba (guest, #4439) [Link] (11 responses)

> They ideally should include a copy of the license.

Just "Ideally"? Isn't it required?

> That practice is far from universal as we see here.

The Linux Foundation themselves work against copyright enforcement of "Open Source", is it surprising that it is far from universal? Without people on the Board like Bdale Garbee and Karen Sandler, this is the result we get. Microsoft and copyright violations.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 20:47 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

> Just "Ideally"? Isn't it required?

A requirement is meaningless unless it is enforced. I doubt the authors care enough to bother.

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 1:06 UTC (Thu) by jebba (guest, #4439) [Link] (9 responses)

You think all 283 contributors (according to github) don't care? That's quite an assumption. And that allows an exemption?

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 2:55 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (8 responses)

> You think all 283 contributors (according to github) don't care? That's quite an assumption. And that allows an exemption?

Given how many websites do this and how often a requirement to bundle a license is enforced, it is a pretty mundane assumption. Also most of the contributors in a project with a long tail has a few patches each that fixed a bug or added a feature they wanted and moved on, leaving a much smaller number of contributors doing bulk of the work and they can either spend their limited time improving the library or enforcing a licensing term. In legal terms, there isn't an exception. In practice, this sort of licensing requirement is often overlooked and questioning me isn't going to change that one bit.

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 17:14 UTC (Thu) by jebba (guest, #4439) [Link] (7 responses)

So since they are too small and unlikely to be able to fight the Linux Foundation's lawyers, the violation is just fine. Got it.

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 17:20 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

> So since they are too small and unlikely to be able to fight the Linux Foundation's lawyers, the violation is just fine. Got it.

Complete mischaracterization of what I said. Try again.

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 17:30 UTC (Thu) by jebba (guest, #4439) [Link] (4 responses)

The Linux Foundation is big enough to overlook violating others' licenses and it is a common practice. Better?

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 17:34 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

> The Linux Foundation is big enough to overlook violating others' licenses and it is a common practice. Better?

Nope. I never talked about the Linux Foundation at all.

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 17:38 UTC (Thu) by jebba (guest, #4439) [Link] (2 responses)

OK, how about the corporate masters you routinely shill for violate free software developers' licenses regularly, so it doesn't matter because the community can't do anything about it.

Can we end this here, please?

Posted Mar 11, 2021 17:45 UTC (Thu) by jake (editor, #205) [Link]

This does not seem a productive use of anyone's time.

Let's just stop this here, please.

thanks,

jake

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 17:56 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

You seem very confused. I have zero association whatsoever with Linux Foundation nor do I work for any organization associated with it. I do have some experience getting free software licensing issued resolved as a volunteer distro package maintainer and developer for several years and that's the perspective I am sharing here. The enforcement of licensing requirements if the authors of the library care enough to do it has to initiated by them. I don't see any evidence at all for that. That's my point.

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 18:20 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Can you please stop your crusade?

This is not Slashdot.

The Linux Foundation's "sigstore" project

Posted Mar 12, 2021 20:13 UTC (Fri) by ratfactor (guest, #132367) [Link]

> ...this could just have been a plain HTML page.

The sharp irony of these awful Web practices (no matter how common they are) being needlessly used on a "web of trust" site is downright painful.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 15:11 UTC (Wed) by re:fi.64 (subscriber, #132628) [Link]

Modernizr is open source, seems just like the license for omitted from the bundle for some reason...

https://modernizr.com/license/

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 15:30 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (2 responses)

* website, https://sigstore.dev/,

I actually can see some github repo links and a slack link. Slack requires running nonfree software to join. At least the repos seem to be free software.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 15:32 UTC (Wed) by dskoll (subscriber, #1630) [Link] (1 responses)

Actually, I use Slack without using any non-free software. I use a Slack-to-IRC gateway, namely matterircd.

I still don't like Slack, but at least I can access it with free software.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 18:30 UTC (Wed) by IanKelling (subscriber, #89418) [Link]

I should have been clearer. To join slack as a new user requires running nonfree software in your browser last I checked. But there are free clients after you do that. Same with twitter.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 17:34 UTC (Wed) by jebba (guest, #4439) [Link]

It links to:

* Google ( https://fonts.googleapis.com/css?family=Catamaran:400,600 )

* Slack ( https://join.slack.com/t/sigstore/shared_invite/zt-mhs55z... )

* Microsoft Github ( https://github.com/sigstore/rekor and others )

The Linux Foundation's "sigstore" project

Posted Mar 12, 2021 20:11 UTC (Fri) by calumapplepie (guest, #143655) [Link]

I disagree on the risks of running arbitrary JavaScript being increased by its nonfree status.

I'm not denying that security holes to exploit exist: there are 0-days in Chrome and other browsers. However, they are rare, of the level that implies nation-state actors, and require long, delicate chains. But my experience with The Great Suspender (see https://lwn.net/Articles/846272/ ) shows that making sure to run open-source code doesn't prevent you from running hostile code..

TGS was a fully open-source extension with 2 million users. A dozen red flags were thrown (new maintainer, from outside the community, with no details of their existence, who never announces their presence, is said to have "purchased" the extension, makes a surprise release, doesn't put out a changelog, doesn't tag the release, includes code in release not on Github, requests additional permissions in release, and has dubious reasons for said permissions).

After three months, there was almost no change in the number of users.

The javascript library in question is open-source, as others have pointed out: while it is minified, that is to speed pageloads and is standard on the web. But that doesn't mean it's innocent. A reproducible build stack doesn't mean that the source code doesn't exploit a 0day. Even if it was distributed unminified, there is no way to know where a 0day may exist: reliably differentiating an unusual style choice from a sandbox compromise can't be done without running the code and carefully monitoring the executor.

Any time you run javascript from the internet, you are risking falling victim to 0days: regardless of if it's open-source or not, distributed minified or unminified. If that concerns you, install NoScript. If you still want SOME scripts, use LocalCDN and uBlock Origin in 'hard' mode. But know that while both of those extensions are fully open-source, either one has all the power it needs to compromise the entirety of your browsing activity.

We can debate the necessity of the site including any JavaScript on this site separately. But there is no way to run remote JavaScript (of ANY sort) securely without trusting that web browser sandbox is resilient. There is furthermore no way to be certain that the techniques you use to prevent JavaScript from running are themselves malicious. At some point, you need to draw the line of trust: drawing the line where minified open-source javascript is on one side and unminifed open-source code isn't is not a good place.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 16:36 UTC (Wed) by fwiesweg (guest, #116364) [Link] (3 responses)

Sounds like quite nice, I hope it gains some traction. I still try to avoid thinking of all the dependencies whose signatures I have not personally validated because it's scary. If only customers paid for such work... ah okay time to stop dreaming.

The Linux Foundation's "sigstore" project

Posted Mar 10, 2021 23:50 UTC (Wed) by shemminger (subscriber, #5739) [Link] (2 responses)

The recent SolarWinds attack happened in the infrastructure, and was caused by trusting the signature.
How would this help that threat model? Or would it introduce a false sense of trust?

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 7:20 UTC (Thu) by fwiesweg (guest, #116364) [Link]

So SolarWinds would have been prevented by trusting a non-signed package? I doubt it. Additionally, I don't think analyzing that unsigned package bit for bit is realistic, either, nobody has time for that and most organizations out there lack the required skill set. It happened despite the signature, not because of it.

Like everything we do, security-related work is iterative in nature and this is but a single building stone to secure the supply chain. Further steps are required and might include many things, from reviewed packages (signed by the reviewers, too), automatic content analyses (so packages are signed by those systems, too), etc., but there'd be no point in all of that if you can't even guarantee that the sources package arrives on your disk without having been tampered with somewhere between you and the maintainer/reviewer. So something like sigstore is a first and necessary, but in itself still insufficient step.

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 7:51 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

I think this is more for clueless projects like yarn that when the repository key expires just make a new one.

No thought about making a keyring package and use it to introduce the new key before the old one expires.

https://github.com/yarnpkg/yarn/issues/7866

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 9:40 UTC (Thu) by Sesse (subscriber, #53779) [Link] (1 responses)

If it's OpenID-based, what makes it more secure than just getting the file over TLS in the first place? If it so you can put it on GitHub without fear of… something? How do you know which OpenID scope to trust? (I thought OpenID was basically dead a long time ago, but seemingly not.)

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 14:20 UTC (Thu) by grawity (subscriber, #80596) [Link]

It's OpenID Connect, which is actually OAuth 2.0 extended with some of the features OpenID had – but otherwise it's unrelated to the original OpenID.

The Linux Foundation's "sigstore" project

Posted Mar 11, 2021 17:13 UTC (Thu) by mss (subscriber, #138799) [Link] (1 responses)

Looks to me like it is essentially a centralized PGP Web of Trust or TOFU database replacement specifically for signing packages.

That is, instead of calculating the trust of the PGP key that signed a release of some package using the aforementioned trust methods the signature will be checked directly in a centralized log.

The Linux Foundation's "sigstore" project

Posted Mar 12, 2021 22:06 UTC (Fri) by Jan_Zerebecki (guest, #70319) [Link]

Not even that, the sigstore-with-oauth sketched in the article will not tell you whether you should trust code that their DB says was signed by lwn@example.com . So you will still need to maintain some sort of trust DB in addition to this sigstore to answer that question.

Transparency

Posted Mar 12, 2021 4:41 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

A recurring pattern is people see Certificate Transparency and they say, oh that's a clever solution to a problem [it is] and I have a problem, so I should model my solution on Certificate Transparency...

I started out reacting to these by thinking "Huh, I guess it isn't a perfect fit, but maybe this works for you" and after seeing it fail so often I've now reached the point where I just grunt in disgust. It would be lovely if "sigstore" is the exception, but that feels unlikely.

CT was very narrowly tailored to solve a very specific problem, and most of these other problems have only superficial resemblance. I think the _most_ important thing I'd want anybody thinking "Certificate Transparency is the model I need to look at" to know is that all the clever cryptography in CT is only there to keep honest people (in this case public CAs) honest in the first place. The real benefits we reap would be the same if CAs just published a CSV file or something - but if there was a CSV file there would be a persistent temptation to tamper with it, and CT removes that temptation. And CT isn't even really finished. A sufficiently powerful and nefarious actor could pervert things pretty badly, and the features mooted to prevent that mechnically ("Gossip" protocols and consistency proof checking) are not in fact deployed. Because like I said, we're about keeping honest people honest, and at a certain point if they're all behaving you need to stop thinking of increasingly devious things they could be hiding from you - they are probably just being honest. Humans are lazy, and the subterfuge required to successful defeat CT as it stands is just too much effort.

But in the space sigstore wants to occupy I don't see honest people who need to be kept honest. I see a Wild West, and I fear that this technology doesn't do what you need in that circumstance at all.

I first saw mention of "sigstore" in a context which compared it to Let's Encrypt in the context of software. Operating a CA (which is what Let's Encrypt does) for Free Software code signing could make sense, but this does not seem to be that.

Transparency

Posted Mar 12, 2021 22:52 UTC (Fri) by Jan_Zerebecki (guest, #70319) [Link] (1 responses)

> And CT isn't even really finished. A sufficiently powerful and nefarious actor could pervert things pretty badly, and the features mooted to prevent that mechnically ("Gossip" protocols and consistency proof checking) are not in fact deployed.

Yes, Trillian AKA CT (which sigstore uses as a dependency) explicitly mentions that it does not yet protect against split view attacks, where an attacker completely simulates a log with different content just for you.

> But in the space sigstore wants to occupy [...] this technology doesn't do what you need in that circumstance at all.

Do you have any suggestions for technology that would be better? I'd have use for a way to detect when others see e.g. the content of Linux 5.11.0 as different than what I see.

Transparency

Posted Mar 13, 2021 4:13 UTC (Sat) by pabs (subscriber, #43278) [Link]

These DebConf talks introduce a gossip hub, which IIRC is meant to attempt to prevent split view attacks:

https://debconf18.debconf.org/talks/104-software-transpar...
https://debconf19.debconf.org/talks/66-software-transpare...

any upside to email verification for signature?

Posted Mar 13, 2021 11:45 UTC (Sat) by Jan_Zerebecki (guest, #70319) [Link]

sigstore fulcio which uses oauth oidc to verify an email for a signature as a replacement for private keys seems worse than possible alternative designs. Can anyone find any upside of it? That is, besides, if you want more centralization.

fulcio does not reduce the amount of secrets you need to keep as you also need to type in a password for your email provider. If that were the goal you could derive the signature private key and a password for your email from the same passphrase. However I think storing a regularly rotated secret per device in addition to your passphrase (that you'd use for both secret unlocking and login) is still preferable.

Instead consider 1) transparency log of fetched git branch heads (no signature to establish authority, as you need to establish which code to trust in another layer anyway) or 2) transparency log of signatures with transparency logged automated regularly rotated public-keys where the previous key signs the next one with tricks for recovery, like designating other keys as authorized notary for replacement for lost keys, storing an only replacement-authorised-key in your email, per device keys, etc. The UI for (2) can look the same as for fulcio, so that is not an argument to not have private keys in a design.