161–170 of 460 posts
Not to toot my own horn too much, but in hindsight this seems prescient.
Earlier quoted context omitted.
So, what's the acceptable LOC count threshold for using a library? Maybe scolding and mocking people isn't a very effective security posture after all.
Scolding and mocking is all we're left with, since two decades worth of rational arguments against these types of hazards have been dismissed as fear-mongering.
Earlier quoted context omitted.
Rust makes me especially nervous due to the possibility of compile-time code execution. So a cargo build invocation is all it could take to own you. In Go there is no such possibility by design.
You're confusing compile-time with build-time. And build time code execution exists absolutely exists in go, because that's what a build tool is. https://pkg.go.dev/cmd/go#hdr-Add_dependencies_to_current_mo...
"go build" of arbitrary attacker controlled go code will not lead to arbitrary code execution.
If you do "git clone attacker-repo && cargo build", that executes "build.rs" which can exec any command.
If you do "git clone attacker-repo && go build", that will not execute any attacker controlled commands, and if it does it'll get a CVE.
You can see this by the following CVEs:
https://pkg.go.dev/vuln/GO-2023-2095
https://pkg.go.dev/vuln/GO-2023-1842
In cargo, "cargo build" running arbitrary code is working as intended. In go, both "go get" and "go build" running arbitrary code is considered a CVE.
Earlier quoted context omitted.
How does it avoid the sharing headaches that make the ergonomics of snaps so bad?
I never used snaps, so I don't understand what you mean here. Here's a couple of typical Qubes usage patterns: https://www.qubes-os.org/news/2022/10/28/how-to-organize-you... , https://blog.invisiblethings.org/2011/03/13/partitioning-my-...
From that article, it looks like perhaps the difference is that snaps are isolated at the app level, whereas qubes is a layer down, where each qube is a kind of workspace with multiple apps potentially installed in it. That seems reasonable enough, though you do have to be willing to pay the disk and mental overhead cost associated with setting up the same tools multiple times, or maintain playbooks/whatever to automate that, or am I going to figure out how to get my one VSCode instance access to the different isolated environments where I need an editor, and if I do that have I basically compromised the whole system model.
Earlier quoted context omitted.
We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained. If y…
npm workspaces and npm scripts will get you further than you might think. Plenty of people got along fine with Lerna, which didn't do much more than that, for years. I will say, I was always turned off by NX's core proposition when it launched, and more turned off by whatever they're selling as a CI/CD solution these days, but if it works for you, it works for you.
People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…
It’s too bad that more robust languages and frameworks lost out to the import-world culture that we’re in now.
OSs need to stop letting applications have a free reign of all the files on the file system by default. Some apps come with apparmor/selinux profiles and firejail is also a solution. But the UX needs to change.
Which operating system lets an application have "free reign of all the files on the file system by default"? Neither Linux, nor any BSD, nor MacOS, nor Windows does. For any of those I'd have to do something deliberately unsafe such as running it as a privileged account (which is not the "default").
Earlier quoted context omitted.
We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained. If y…
npm workspaces and npm scripts will get you further than you might think. Plenty of people got along fine with Lerna, which didn't do much more than that, for years. I will say, I was always turned off by NX's core proposition when it launched, and more turned off by whatever they're selling as a CI/CD solution these days, but if it works for you, it works for you.
the truly chilling part is using a local llm to find secrets. it's a new form of living off the land, where the malicious logic is in the prompt, not the code. this sidesteps most static analysis. the entry point is the same old post-install problem we've never fixed, but the payload is next-gen. how do you even defend against malicious prompts?
Run Claude Code in a locked down container or VM that has no access to sensitive data, and review all of the code it commits?
In which case you couldn’t really separate your dev environment from a hostile LLM.