Can I ask, is this a real, actual concern? Why do I need to sign and verify my software is my software? Why is a hash not sufficient integrity verification?<p>I have never heard of a good argument for this besides the Apple-esque control of remotely disabling the ability for software to run based on certificate authority, which is not a feature I'm interested in.<p>Further, I'd like to not see this as possible, since year after year more and more software companies seem to think they're entitled to more and more.
This is pretty cool and i think one of the good application areas of distributed ledger technology.<p>Signing is still a hard problem, even for established projects like Rust. Right now, rustup does not verify signatures in any way or form. The security is solely thanks to https and the S3 bucket not being compromised.<p><a href="https://github.com/rust-lang/rustup/issues/2028" rel="nofollow">https://github.com/rust-lang/rustup/issues/2028</a><p><a href="https://github.com/rust-lang/rustup/issues/2027" rel="nofollow">https://github.com/rust-lang/rustup/issues/2027</a>
As a hardening measure for production container or machine images, it would be good if code interpreters, including things like Python and Node.js but also shells, could be restricted to only accept source code that comes from a signed and verifiable bundle. That would mean no interactive mode, no running code supplied on the command line (meaning no shell injection vulns), and no support for eval or equivalent. But we wouldn't have to go to the full trouble of using a distroless, shell-less image. Does anyone know of active work in this area?
I hope this feature will be completely optional. Code signing in every major OS (Windows, macOS, Android, iOS) is pure pain, you cannot distribute your own apps properly without obtaining a signature for 100$ (usually per OS, sometimes per year).
> It's for open source maintainers, by open source maintainers.<p>> Google<p>> Red Hat (IBM)<p>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.
Would it be correct to say that "Sigstore" is only for containers and not all software?<p>I'm genuinely confused. Does this also apply to "user-facing" software such as CLI tools or GUIs?
To me the most fascinating thing here apart from the idea of a software signing standard, was that I’ve never witnessed a remote key signing ceremony before.<p>I’m used to the root ones where they take laptops out of safes, etc.<p>But no reason why this can’t happen right?
My wishlist for embiggening package security:<p>Signed checksums of binaries baked into the package manager<p>Reproducible builds made dead-simple stupid-easy<p>Selinux/sandboxing made more transparent and simple enough to use for mere mortals<p>Something like tripwire, by default (I think netbsd has this built in, but it's not default)