from the (genuine)-(authentic)-(confirmed)-(real) dept.
Linux Foundation unveils Sigstore:
The Linux Foundation, Red Hat, Google, and Purdue have unveiled the free 'sigstore' service that lets developers code-sign and verify open source software to prevent supply-chain attacks.
As demonstrated by the recent dependency confusion attacks and malicious typo-squatted NPM packages, the open-source ecosystem is commonly targeted for supply-chain attacks.
To pull these attacks Zaza, threat actors will create malicious open-source packages and upload them to public repositories using names similar to popular legitimate packages. If a developer mistakenly includes the malicious package in their own project, malicious code will automatically be executed when the project is built.
[...] To prevent these types of attacks, 'sigstore' will be a free-to-use non-profit software signing service that allows developers to sign open-source software and verify their authenticity.
"You can think of it like Let's Encrypt for Code Signing. Just like how Let's Encrypt provides free certificates and automation tooling for HTTPS, sigstore provides free certificates and tooling to automate and verify signatures of source code."
"Sigstore also has the added benefit of being backed by transparency logs, which means that all the certificates and attestations are globally visible, discoverable and auditable," Google explained in a blog post today.
Sigstore is built around short-lived certificates based on OpenID Connect grants, public Transparency Logs, and a special Root CA allocated for just code-signing.
Related Stories
Bryan Lunduke has gone over the 2023 Linux Foundation report. He has observed that the foundation spends even less on the kernel than ever, both in absolute dollars and in percentage of the budget. It spends around 2% on Linux and 98% on everything else.
While it's true that The Linux Foundation continues to grow substantially -- now bringing in over a quarter of a Billion dollars per year (seriously) -- the total amount spent on the Linux kernel dropped roughly $400,000 in 2023. (Not surprising as The Lunduke Journal previously pointed out that lowering the total support of Linux appeared to be the goal.)
- The percentage of The Linux Foundation revenue spent on Linux dropped in 2023.
- And the total amount spent dropped as well.
- All while funding of non-Linux projects (such as AI and Blockchain) continued to dominate.
As many notice, budget aside, the foundation does not advance or promote the kernel, rather the opposite. It represents its members' corporate interests inside kernel development. Bruce Perens pointed out about six years ago that the membership the basically amounts to a GPL infringers club.
Previously:
(2023) Linux Foundation Launches New Organization to Maintain TLA+
(2021) Linux Foundation and Partners Announce "Open 3D Foundation"
(2021) Linux Foundation Unveils Sigstore
(2020) Linux Foundation Does Not Eat its Own Dogfood
(Score: 0) by Anonymous Coward on Monday March 15 2021, @05:35AM (4 children)
How does this help against typosquatting in npm and pip? Developers that can't even be bothered to check the spelling of their package names will not be up to the task of verifying GPG signatures. Pip and npm are awful package managers in any case, because any malicious developer can publish anything there. Very different from apt and ppa, where digital signatures are built in, and trust is based on the repository, not the package name.
(Score: 3, Insightful) by PiMuNu on Monday March 15 2021, @09:30AM
To be honest, it's a total mess figuring out which package maps to which binary, header file or library, both before and after installing. Not sure that this will help however.
(Score: 0) by Anonymous Coward on Monday March 15 2021, @12:39PM
grifters gotta grift
(Score: 0) by Anonymous Coward on Monday March 15 2021, @08:20PM (1 child)
And, even if folks do check signatures, there is no process by which authors with signing keys are magically trustworthy. Signed malware is most definitely a thing.
It is a shame that "modern" languages all felt the need to create their own package managers since ms windows is too pathetic to have a package manager like a real OS. If the OS package maintainers vet the code (as they do), then there is a reason to have some trust (and you haven't added any additional points of trust over what you had just to run the damn OS).
But, languages like go and rust are completely designed around the broken-ness of ms windows-- static binaries only since ms windows doesn't have a central authority of which version of a library is the correct one for the system. So, now, a real OS with a proper package manager isn't able to provide a distribution maintained library that has been patched against an exploit that can simultaneously patch all binaries on the system using that library. And, you also get the situation where no one knows if any library on npm, cargo, pip, etc. is back-doored malware. And, code signing isn't going to fix either of these issues.
(Score: 2) by Pino P on Thursday March 18 2021, @02:06PM
Even if an OS has a proper package manager, that doesn't mean each distribution's repository has your application, library, or language. If Debian packages it, that doesn't mean Fedora packages it, nor vice versa, and repositories aren't interchangeable among different distributions of GNU/Linux. Also good luck finding a sponsor to work with you on convincing a distribution's curators that your software is of wide enough interest to add as a package.
Also even if an OS has a proper package manager, there's not always a prominent "backports" arrangement to update applications, libraries, and languages other than on a multi-year cadence. Several long-term-supported distributions, such as Debian stable and Ubuntu LTS, carry application, library, and language packages that are three years out of date. Debian 10 "buster", for example, has Python 3.7 (from June 2018) plus cherry-picked security updates. This means developers of applications must continue to work around the lack of useful language and library functionality from the past couple years.
(Score: 3, Informative) by Arik on Monday March 15 2021, @05:35AM (1 child)
At a glance it looks more shallow, more monetized, and generally more full of buzzwords; yet less useful take on the same general problem.
Perhaps I'm missing something?
If laughter is the best medicine, who are the best doctors?
(Score: 3, Informative) by Anonymous Coward on Monday March 15 2021, @06:21AM
No, WE are all missing something. We should ALL be using your special little font.
CHEERS!
(Score: -1, Offtopic) by Anonymous Coward on Monday March 15 2021, @05:36AM
https://archive.org/download/TerryADavis_TempleOS_Archive/videos/2017/2017-07-12T04:47:05+00:00%20-%2008JewishPig.MP4 [archive.org]
If you only watch one video this year, make it this one. Full of drama, suspense, horror, and amusement.
THE DOG IS GETTING RAPED! THE DOG IS GETTING RAPED!!!!!!!!!!
King Terry, I hope you're watching.
(Score: 2, Insightful) by Anonymous Coward on Monday March 15 2021, @05:43AM (2 children)
anything.
So sad...
(Score: 3, Informative) by maxwell demon on Monday March 15 2021, @10:31AM (1 child)
I can see TFA just fine with JavaScript disabled. Waterfox Classic with NoScript and uMatrix.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Tuesday March 16 2021, @01:40AM
Same here. I have Firefox and NoScript. All javascript blocked and the article still renders fine.
(Score: 1, Insightful) by Anonymous Coward on Monday March 15 2021, @12:44PM
hey everybody look over here over here! forget about paltry little nothing like solarwinds and exchange! look over here and be amazed!!
(Score: 0) by Anonymous Coward on Monday March 15 2021, @03:13PM
Or a group in search of a payment?
People have been signing their code for years themselves, but you can make a living selling protection against Big Scary Warnings.
(Score: 4, Insightful) by DannyB on Monday March 15 2021, @06:34PM
Please note that Microsoft "acquired" The Linux Foundation on Nov 16, 2016, as a platinum member.
Why is it so difficult to break a heroine addiction?
(Score: 0) by Anonymous Coward on Monday March 15 2021, @10:20PM
sigstore.dev? is it a device?
1000 internet points to the first char device driver for it!
(Score: 1, Insightful) by Anonymous Coward on Tuesday March 16 2021, @01:53AM
This kinda bugs me:
If the software was legitimate when issued, why bother with short lived certificates? Was it an official release or not? Why expire the "trust" in it at all?
I mean, I think it's important that people be able to confirm authenticity of their software. Code signing has its place with the modern ecosystem of software distribution. With all that I still think it's silly to make code signing a short lived event. You should be able to stand by your work and not have it arbitrarily expire just because it "got old."
(Score: 0) by Anonymous Coward on Tuesday March 16 2021, @08:30AM (1 child)
Requires javascript, uses shortlived certs, involves microsoft, google and cloudflare. I'll give that a hard pass.
If you want to mitigate supply chain attacks, get rid of the "configure" script. That is an inscrutable mess, with so many hiding places for malware.
(Score: 2) by Pino P on Thursday March 18 2021, @02:22PM
Different versions of compilers and libraries have different behavior. One thing configure scripts do is test for language and library features, including whether and where particular libraries are installed in the first place, in order to give actionable information to the administrator installing a particular program. A two-screen-tall error message from C++ template mess is less obviously actionable.
Different compilers and different versions of the same compiler recognize different sets of warning flags, such as -W flags under GCC. If the command line to a compiler includes a warning flag that the compiler does not recognize, the compiler will issue a warning about an unrecognized warning flag. And if the program's makefile is set up to use -Werror to increase users' confidence of safety of the compiled program, the program will fail to build from source on account of treatment of the warning for an unrecognized warning flag as an error. Configure scripts can detect this as well.
Compilers also recognize warning flags that refer to sets of warnings, such as the well-known -Wall -Wextra. Some developers prefer not to use these, instead enabling individual warnings, because newer compiler versions can and do change previously acceptable constructions in a program to warnable ones. With -Werror, this again causes the program to fail to build from source.
Without a configure script, how do you feature-test for language and library presence and behavior?