Both are billion dollar companies, we as individuals have nothing in common with them. Enshittification happens due to market conditions that apply to small and large companies alike. Redis and elasticsearch aren't underdogs fighting for the little guy, they are just a smaller scale version of the same shit.
I'd rather have a software commons and have tech be owned by the workers and not soul-sucking corporations, no matter the size.
+1 for Node-RED. If we've learned anything from elasticsearch/redis/bitnami/and dozens of others, it should be "don't build important things on code that isn't enshittification-resistant"
If you are actually against the policy and suspect a lot of people are too, then don't silence your employees by keeping their feedback isolated to 1:1s which you admit are ineffective.
Executives need clear feedback to avoid making major mistakes.
Code signing, 2FA, and reducing dependencies are all incomplete solutions. What we need is fine-grained sandboxing, down to the function and type level. You will always be vulnerable as long as you're relying on fallible humans (even yourself) to catch or prevent vulnerabilities.
Apparently they've tried to implement this in JavaScript but the language is generally too flexible to resist a malicious package running in the same process.
We need to be using different languages with runtimes that don't allow privileged operations by default.
It's true that we were all sold the lie of individual actions being the way to solve the climate crisis (recycling, turning off lights, etc.) But I think the conclusion is to try other strategies rather than giving up when the first strategy didn't work.
The ideal situation would be building a society that believes everyone deserves to be fed, clothed, and housed regardless of their ability to make profitable things. Weird how politically unpopular that seems to be.
Both producers and consumers of media are in the same boat of barely surviving. Maybe we can work with each other instead of against each other? :)
This seems to only address a few of the nine threats to the software supply chain, mainly "(D) External build parameters" and maybe the content-addressable storage addresses some of the distribution phase threats: https://slsa.dev/spec/v1.1/threats
There are still many other ways that a dependency can be exploited before or after the build phase.
BNPL is only "good" if your definition of "good" is about GDP, market flexibility, high-performance index funds, and other things that have nothing to do with human happiness.
I'll believe that BNPL is good when all the companies become non-profits that use excess funds to cancel debts rather than lining the pockets of rich investors.
People have been running different levels of privileged code together on the same machine ever since the invention of virtual machines. We have lots of lightweight sandboxing technologies that could be used when invoking a particular action such as tj-actions/changed-files that only gives it the permissions it needs.
You may do a "docker build" in a pipeline which does need root access and network access, but when you publish a package on pypi, you certainly don't need root access and you also don't need access to the entire internet, just the pypi API endpoint(s) necessary for publishing.
Every action gets these permissions by default. The reason we know it had that permission is that the exploit code read from /proc/pid/mem to steal the secrets, which requires some permissions: https://blog.cloudflare.com/diving-into-proc-pid-mem/#access...
Linux processes have tons of default permissions that they don't really need.
This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process.
You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the thing they are designed to do and nothing more.
There's essentially nothing nefarious changed-files could do if it were limited to merely reading a git diff provided to it on stdin.
Github provides no mechanism to do this, probably because posts like this one never even call out the glaring omission of a sandboxing feature.
Amazon really encourages valkey in the elasticache dashboard. There's a banner advertising lower prices and it's listed first in the dropdown when you go to create one. Default settings do have power.
> All the cybersecurity companies saying "We don't have anything to say about this situation." is just them being true to their main in-group: for-profit companies that don't want to upset a big current or potential buyer. They are, first and foremost, part of that "community", and they happen to be involved in cybersecurity. Solidarity is happening there, just not to the people in cybersecurity.
This sucks and we should change it for sure. So many other industries have successfully become professionalized, unionized, and kicked the grifters to the curb. But it feels more and more like the cybersecurity grifters are the ones holding the reins.
On its own, immutability isn't a complete solution to supply chain attacks. Software still needs to be updated and those updates could contain malware too.
You need immutability and something like sandboxing where actions cannot e.g. dump the memory of the runner process to steal secrets.
The alternative is vetting every single line of code in every dependency and every subdependency perfectly for every update, which is not realistic.
The effort to replace US tech is not anything similar to the European tech industry.
US technology has a hegemony because we were first to the party, our economy is larger, and our laws are hostile to newcomers (lack of interoperability requirements, lack of enforcement of anti-trust laws, strong defense of DMCA laws, non-competes, and trade secret laws).
I've worked in the EU tech sector. They have tons of startups that operate just like US startups: VC funded, hockey-stick growth, and hiring like crazy. Their stricter labor laws don't get in the way of that.
The hyper-growth, VC-funded startup model is itself quite exploitative, but if it's still possible with stricter labor laws, then fears about them impacting growth are unfounded.
> you're going to personally be better off changing companies
Job mobility for tech workers is a fluke of current economic conditions. If interest rates spike, or a recession happens, or a bubble bursts, this benefit would go away and you'd be stuck at that exploitative company or unemployed.
Unionization and labor laws can make workers less disposable without substantially affecting growth (see: European tech hubs).
There's no reason why tech unions can't have solidarity with other unionization efforts (and there are thousands of reason why we should have that solidarity).
Us tech workers could be leveraging the privilege we have to get better conditions for everyone.
A perfect example is non-compete clauses. Tech workers enjoy high job mobility, which is only hindered by non-competes. It's no accident that major tech hubs were some of the first states to ban them, helping all workers.