insanitybit

8 ms·

91.
by insanitybit 2mo ago
People have rapidly adopted far less tested databases when the dbs have claimed to solve real problems.
92.
by insanitybit 2mo ago
Sure, that seems reasonable enough. I'm pretty skeptical that it will happen, but it's not like it's impossible.
93.
by insanitybit 2mo ago
I'm not debating you at all. I'm asking what the model looks like since you've stated (and I've agreed) that a language model wouldn't work. I think it would make sense to explain how a theoretical model could do be
94.
by insanitybit 2mo ago
And I'm asking you to describe the model.
95.
by insanitybit 2mo ago
It's unclear what you are talking about then. Because the idea of training "ciphertext -> plaintext" for language models is absolutely bonkers, so what are you suggesting?
96.
by insanitybit 2mo ago
I'm referring to the first selection process.
97.
by insanitybit 2mo ago
How much am I expected to charitably interpret the joke? They said "only", I'm taking it at face value because it's obviously intended to be commentary and the obvious implication is that this issue is unique to NPM (as
98.
by insanitybit 2mo ago
> No way to prevent this says only package manager where this regularly happens "only"
99.
by insanitybit 2mo ago
Only if the jury believes in nullification, which isn't common. The jury is instructed to follow the law. The selection process asks "even if you think they were right, if it's against the law and they were guilty would you i
100.
by insanitybit 2mo ago
That axiom is clearly false. AI can interact with external systems, which means it is not just compressed knowledge - it has the ability to access new information.
101.
by insanitybit 2mo ago
left-pad is totally irrelevant to this conversation.
102.
by insanitybit 2mo ago
Yes, it has nothing to do with the design of npm (relative to similar languages/ repositories) and everything to do with the popularity.
103.
by insanitybit 2mo ago
I just don't think that this is that unique to javascript, it's absolutely not about npm, and I don't think that this is well supported as a relevant feature that leads to these attacks.
104.
by insanitybit 2mo ago
Yeah, my point is just that other package managers aren't in a great spot. NPM even lets you separate out "publish" and "release" now where you can publish to the registry but you have to separately "ack"
105.
by insanitybit 2mo ago
No build script control though.
106.
by insanitybit 2mo ago
162k vs millions. That's not even getting into package update velocity, authorship, the totally divergent goals, etc. I just think it's utterly pointless to compare.
107.
by insanitybit 2mo ago
Debian's scale for package distribution is tiny and explicitly curated by maintainers. Everything funnels through Debian. The goals are completely different. Debian packages what's necessary for an OS, npm packages everything need
108.
by insanitybit 2mo ago
I think that's barely meaningful. Which of the compromised packages would have been part of any reasonable stdlib?
109.
by insanitybit 2mo ago
Ruby is worse. crates.io is arguably worse.
110.
by insanitybit 2mo ago
I don't consider these comparable in any way that's worthwhile. The scale and goals are completely different.
111.
by insanitybit 2mo ago
Arguably crates.io is worse. NPM has cooldowns and has for a while, it has had Trusted Publishing for longer, it has human-approved releases that separate CI/CD from actual publishing. Ruby is probably worse in every way.
112.
by insanitybit 2mo ago
Yep, I'd recommend it.
113.
by insanitybit 2mo ago
This is the most boring comment posted on every one of these. NPM is by no means the worst offender here and offers a ton of solutions to this, lots of package managers are behind it or equivalent. NPM gets targeted a lot because it's
114.
by insanitybit 2mo ago
Dev laptops tend to have better monitoring than CI/CD so I still think this is a better option. You can also have devs use VMs or separate dev environments like an ec2 instance. To be clear, just solving the CI/CD portion is insuf
115.
by insanitybit 2mo ago
Yes, you should separate "tests execute" into their own unprivileged workflows that don't have "deploy" secrets.
116.
by insanitybit 2mo ago
Prod tends to have less privileges than CI/CD. CI/CD tends to be full admin, so it's far more sensitive. Prod tends to have tooling for detecting breaches, better logging, etc. People tend to use containers, which act as a sa
117.
by insanitybit 2mo ago
You'll just end up with people running `./configure` scripts or whatever instead. The solution I've currently landed on is: 1. Audit build scripts/ proc macros for rust code (and mark with cargo-vet). 2. Have an isolated
118.
by insanitybit 2mo ago
> almost certainly from running in CI where such secrets don’t exist. CI usually has the most privileged secrets anywhere in a company lol
119.
by insanitybit 2mo ago
I'm going to graciously give you one last chance to actually say something of substance before I stop responding entirely.
120.
by insanitybit 2mo ago
I don't know what you're trying to say at all. But no, the kernel is objectively not compliant because they label fixes with CVEs and not vulnerabilities. But even if they were compliant... what would that have to do with anything

More ›