> Red Hat (IBM)
Marketing in this manner is deceptive. Saying it’s “by and for” open source maintainers gives the impression this is a grass roots effort, when in reality this is a corporate initiative.
The legal entity here is the Linux Foundation.
As they’ve said, this seems like LetsEncrypt for software signing.
I found out about this project 30 mins ago and honestly it sounds great. it would be awesome for us to roll this out even for our internal libraries.
Red Hat and Google helps to show that money will be behind running the service (funded through the Linux Foundation)
This is the same set up with Let's Encrypt . Linux Foundation > ISRG > Let's Encrypt with money funded by corporate sponsors.
Money needs to come from somewhere when you run a critical service.
On what basis can you say that? It’s clear that a corporation that accepts legal liability for the software they run in production or ship would have a strong incentive to create a process around determining the origin of said software.
It's true that different open source projects care about different things (and some may genuinely not care about who contributes), but there are plenty of prominent open source software projects (the linux kernel, various programming languages, apache, etc) who deal with people who would like to submit vulnerabilities or simply cannot code well enough to avoid problems. It seems like all projects would like to avoid those outcomes, even if their legal situation is different, and providing a verifiable certificate chain could be a method of achieving that (either in contributions or in distribution).
Strong incentive no. In fact, most volunteer open source developers release their software with no legal liability at all (cf. MIT license).
For example - even though the GPL contains, to the extent legally possible, an "as-is" clause like the MIT liscence, it's extremely common for GPL projects to publish information (ex: hashes, known good package repos, etc) that help people ensure they've gotten the software they expect. Sigstore seems like it's driving towards the same goal.
The fact that it’s backed by an entity that is more eternal is actually a plus. Any concerns about bait and switch profit are addressed in the OSS license they pick.
I haven’t looked at the license but I’d hope it’s permissive (Apache, MIT, etc) otherwise, wouldn’t touch it.
That said, my speculations were about Google's intentions (not sigstore's) and if you think they are "completely untrue" then you are being misled and should potentially reevaluate the entire project.
Banning anonymous and pseudonymous contributors and requiring real names be provided to a trusted party is an explicitly stated goal of Google's[1] and one of the reasons they contribute to the sigstore project in the first place[2]. If I was going to try to make that happen, sigstore is a great way to lay down the infrastructure to implement something like that at a later point.
Additionally, anything that will centralize FOSS development (as being a root signing key for software would do) is probably not in it's best interests long term, because at that point the difference between a good and bad actor is a matter of policy and not a technical question.
I believe that you have the best of intentions, but others involved in the project clearly don't.
[1] https://security.googleblog.com/2021/02/know-prevent-fix-fra...
If there were any evil intent, I am telling you know, I would be kicking up a storm.
Sorry about the "completely untrue" statement, that was not helpful. It's just we face so much unneeded FUD all the time.