Linux Foundation Debuts Sigstore Project for Software Signing (darkreading.com) 19
The Linux Foundation has announced the launch of Sigstore, a new nonprofit initiative that aims to improve open source software supply chain security by making it easier for developers to adopt cryptographic signing for different components of the software development process. From a report: Sigstore will be free for software providers and developers, who can use it to securely sign software artifacts such as release files, container images, binaries, and bill-of-material manifests. Signing materials are then stored in a tamper-proof public log. The service's code and operation tooling will be fully open source and maintained and developed by the Sigstore community. Founding members include Red Hat, Google, and Purdue University. The idea for the service came from Luke Hinds, security engineering lead in Red Hat's Office of the CTO. He pitched the concept to Google software engineer Dan Lorenc, and the two began to work on it. Now the Sigstore project has a "small but agile community" working on its development, Lorenc says.
Double Edged Sword (Score:2)
I'm just interested in how SigStore will protect itself from nefarious users. This could go really badly if it isn't done well. I'm not sure if there is a right way to do it without so
Re: (Score:2)
Well then, it must be too complicated to sign your packages with gpg sign and upload your public key to key server or make it available on a secure web site that you control. Just publishing an sha checksum must be even harder! :)
I am not against this initiative at first glance if it can improve anything but the publishers too lazy to sign their code and/or publish checksums will probably be too lazy to use that new tool as well. Here is a trick I do when I really need to install some code from those publis
Re: (Score:2)
Well then, it must be too complicated to sign your packages with gpg sign and upload your public key to key server or make it available on a secure web site that you control. Just publishing an sha checksum must be even harder! :)
the problem with that is that you could be absolutely anybody. even a trojan could be signed by a GPG key. as i said: there are *seventeen* separate and distinct requirements here, any one of which if you fail to implement results in catastrophic collapse in some way.
You will usually get results from virus scanning companies and others confirming that the file possesses that checksum indeed.
couple of things: firstly that's centralised control (critical reliance on what the *virus* company says is - or is not - "trusted"). secondly, not everyone runs anti-virus software not necessarily out of quotes laziness quotes *but precisel
Re:Double Edged Sword (Score:5, Informative)
This sounds like a "Let's Encrypt" for software development signing. Honestly, I think it is a great thing. So many times I've had to install unsigned drivers from opensource projects. It never makes me feel good. With the cost of even the cheapest code signing certificates could be prohibitive many small open-source projects.
when i did a Software Engineering "Requirements Specification" style review of how distros perform chain-of-trust signing from source to binary, it was a deep month-long rabbit-hole. it turned out to have over *seventeen* separate and distinct critical requirements. the *only* distro that had successfully implemented them all?
debian.
* ubuntu have an insufficient number of developers in the gpg keyring to engender sufficient trust that it could not be taken over through social engineering or intelligence agencies
* not even Suse or Redhat RPM-based distros had the full chain, lacking one of the critical steps without which it was possible to not fully trust a distro.
* archlinux entirely lacks a source signing system that allowed hackers to re-register a package after github developers cancel their accounts.
* don't even get me started on pip3, Mozilla B2G or npm.
this is of deep concern (from TFA):
To make the process simple, Sigstore relies on the OpenID authentication protocol to connect certificates to identities.
combined with this from the website:
Using OpenID connect identities allows users to take advantage of existing security controls such as 2FA, OTP and hardware token generators.
2FA using whose cloud-centralised service?
so... that's OpenID... as controlled by whom? so now we have to provide our "Real World ID" connected to a Google Server before we can be quotes "trusted" quotes??
this statement from the website is particularly disturbing https://sigstore.dev/what_is_s... [sigstore.dev]
The toolsets we have historically relied upon were also not built for the present circumstance of remote teams. This can be seen by the need to create a web of trust, with teams having to meet in person and sign each other’s keys.
have they actually bothered to ask how debian and other distros relying on peer-distributed keyring signing have converted to dealing with the issue of remote trust, now that meeting in person is less likely?
then... oh god no...
Want to find out more?
Come on over to our slack workplace
so unless you agree to be monitored and your GPS coordinates, IP address, real name and identity tracked and sold to the highest bidder, you're not welcome to contribute or participate.
what a f***g sxxx-show.
Re:Double Edged Sword (Score:4, Informative)
It's not designed for distro level stuff, it's supposed to improve things for random developers who maintain a package or two. It doesn't have to be perfect to increase security for them, because at the moment a lot of those packages are not really authenticated at all. They are just one compromised password away from being replaced with malware.
Re: (Score:2)
It's not designed for distro level stuff, it's supposed to improve things for random developers who maintain a package or two. It doesn't have to be perfect to increase security for them, because at the moment a lot of those packages are not really authenticated at all. They are just one compromised password away from being replaced with malware.
anything that involves "a package or two" is basically the exact same concept as a distro except it's a "mini ecosystem distro"... that's independent of any distro. as such, the exact same requirements are needed to provide the kinds of deeply comprehensive chain of guarantees, *including* ensuring that the underlying web of trust is for, by, and of the people.
failure to meet those requirements - in full - gives you things like Sigstore, which is set to make google and other providers of 2FA solutions the
Good (Score:2)
You know someone is going to get burned by all the packages that blindly get installed. Python seems especially bad in that respect. You can’t run anything without someone saying oh just do a pip install foopackage123. I mean how convoluted is your scripting language that you need virtual environments?
How aboult just locally signed files? (Score:3)
One basic thing that seems to be overlooked is basic file signing to ensure a file hasn't been altered, not just up the supply chain but locally (e.g. config files). There are lots of ways of embedding the signature but I think actually storing it on the filesystem as an extended attribute would be best as it can apply to any type of file. Previous efforts for executable signing have been abandoned because kernel modules were not signed. That has changed but now we don't have file signing!
Re: (Score:2)
> That has changed but now we don't have file signing!
The way dpkg and rpm do it, at least, (-V flag) has merit, because if the file is replaced, its signature is not.
Re: (Score:2)
This is largely my fear - that soon it will be impossible to create or distribute software if it's not signed. So no longer are you able to distribute something yourself, you will be beholden to some external authority (either centralized or decentralized). Because I guarantee that "self signing" is going to be resisted.
The great democratization has failed, we were not sufficiently diligent. "Those who sacrifice freedom for security deserve neither" and all that.
On a more upbeat note - there has to be a
Re: (Score:3)
Certificates are about trust, but they don't serve the need you describe. It tells you that you can be sure of where it came from - not whether to trust them.
If you wait for more than "good enough," it may be a lifetime before you have anything at all. Much like your 3D game engine example. If you wanted to play 3D games in the 90s, should you wait until 2020 or beyond? Or would you consider the "ray casting" done by modern cards to be a hack and inferior to true ray tracing and wait another 25 years?
Licensing Model (Score:1)
What's the licensing model? Is it actually truly open-source, or is it locked into GPL meaning its just "Linux" branded open-source, but the BSDs, Solaris, and other OSes are stuck once again not being able to incorporate the tooling directly because of licensing restrictions?