cyrnel

The response to that: https://andre.arko.net/2025/10/09/the-rubygems-security-inci...

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"

I know, right? It's sycophancy.

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.

I think this article describes the issue well:

https://crankysec.com/blog/community/

> 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.

I've seen this more formalized as a triangle, with "functionality" being the third point: https://blog.c3l-security.com/2019/06/balancing-functionalit...

You can get secure and easy-to-use tools, but they typically have to be really simple things.

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.

Thanks for the edit! In "incident response mode" every moment counts!

The advertising in this article is making it actively difficult to figure out how to remediate this issue. The "recovery steps" section just says "start our 14 day free trial".

The security industry tolerates self-promotion only to the extent that the threat research benefits everyone.

I think declining an exit interview is bad advice for the exact same reason that venting during an exit interview is bad advice. Declining makes you look obstinate and can be used against you as well. You can just give neutral feedback ("grey-rocking") like the post mentions.

No discussion of language loss is complete without mentioning the hundreds of indigenous languages that were eradicated by force:

> "Funded by the federal government and contracted to religious missionaries, the purpose of a residential school was to reprogram Native children—by force if necessary—eliminating their tribal beliefs, modes of dress, music, language, and thought. If they resisted, they were brutally abused. Known as residential schools because students were required to reside on campus, the institutions were notorious for their cruelty. When students spoke in their Native languages, they were punished by having their tongues punctured with sewing needles. At the St. Anne’s residential school, run by the Oblate order in Fort Albany, Ontario, a makeshift electric chair was built to punish students with electric shocks."

Excerpt From "We Had a Little Real Estate Problem"

Kliph Nesteroff

There's not a lot of "breaking down" happening here. It's the same vague recommendations that can be found in the NSA's own documents, further reinforcing the gap between the guidelines and practitioners.

NSA/NIST/CISA all admirably avoid referring to specific products, but that ship has already sailed. Security today _is_ (unfortunately) a constellation of security products, rather than open source protocols, etc.

The author's pronouns can be found here: https://github.com/Xe

Seems some of these bots are behaving abusively on sites with lots of links (like git forges). I have some sites receiving 200 requests per day and some receiving 1 million requests per day from these AI bots, depending on the design of the site.

You could replace "they do not care" with "they are prevented from caring" or "they care about different things" to get a more empathetic take.

Designing entire cities on shoestring budgets and break-neck timelines prevents caring.

Choice of lighting requires caring about many factors, including longevity and efficiency. The fact that you would make a different tradeoff doesn't mean the person doesn't care.

Driving is a complex task. Watching for mergers while trying not to die in a crash is hard to do simultaneously.

I could go on, but the solution to these things is not to get weirdly mad at people who may have a perfectly good reason for their behavior (sometimes they don't).

Cities should be designed in close consultation with residents (not just whoever has the free time to show up to meetings). Humans shouldn't be forced to drive everywhere. Up-selling should be a consumer protection violation. Caring alone isn't enough if you care about the wrong things.

It's not hard to change to git switch. I used to have a "co" alias for "checkout" which I removed. I'd say I lost maybe 60 seconds of typing time over the few weeks it took to unlearn the muscle memory.

60 seconds of time investment to be better at mentoring the next generation of technologists is worth it.

This seems to start from the strange assumption that companies have a clear and correct understanding of what things to prioritize, and then concludes that deprioritizing glue work is actually smart.

Historically, companies really don't know what they are doing, especially on issues like this. Glue work often encompasses tasks viewed as feminine and its de-emphasis hurts women's careers (and men who happen to focus in glue work too): https://medium.com/@granellacamila/a-few-months-ago-i-discov...

> In a study published by the American Economy Review, the researchers discovered that women volunteered more than men for tasks considered glue work, hence, less promotable tasks in general. However, the researchers have also found that men waited longer to volunteer for tasks when there were women on the team. Furthermore, women were more volunteered by managers or colleagues than men. These kinds of tasks have a direct impact on women’s career development through time.

It took two world wars for some companies to get over their biases and actually let women join the workforce. It's no surprise then that companies would continue to devalue glue work, even if it hurts their bottom line.

Looks like they do mention that elsewhere: https://www.fastmail.com/features/reliability/

> Fastmail has some of the best uptime in the business, plus a comprehensive multi data center backup system. It starts with real-time replication to geographically dispersed data centers, with additional daily backups and checksummed copies of everything. Redundant mirrors allow us to failover a server or even entire rack in the case of hardware failure, keeping your mail running.