761–770 of 894 posts
Earlier quoted context omitted.
Is this the first time you have ever thought about the idea of supply chain attacks? This is the first thought 90% of people have and it doesn't work. Too much work to manually verify diffs and LLMs aren't good enough at this yet.
No, I think about it all the time. It’s just baffling that this kind of attack is still a thing, after a decade+ of this happening over and over again.
This is exactly to avoid this kind of issue that I decided to work on StableBuild. StableBuild pins and hosts a copy of your dependencies at a specific freeze date, so that your supply chain is never contaminated. This way, a compromised version published after your freeze date (even with the same version number!) would never reach your build.
Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in? It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.
We run everything NPM related inside Apple containers, and are looking to do the same with Python and Rust soon. Bwrap on Linux does the same. I like to think of it like working with dangerous chemicals in the lab. Back in the days, people were sloppy and eventually got cancer. Then dangers were recognized and PPE was developed and became a requirement. We are now at the stage in software development where we are beg…
Earlier quoted context omitted.
> the "roll your own crypto vibe", which I disagree with Again, you run into the attack surface area here. Think about the Heartbleed vulnerability. It was a vulnerability in the DTLS implementation of OpenSSL, but it affected every single user, including the 99% that weren't using DTLS. Experienced developers can, and should, be able to elide things like side-channel attacks and the other gotchas that scare folks of…
The reason I disagree about crypto is because: 1. It's really really hard to verify that you have not left a vulnerability in (for a good time, try figuring out all the different "standards" needed in x509), but, more importantly, 2. You already have options for a reduced attack surface; You don't need to use OpenSSL just for TLS, you can use WolfSSL (I'm very happy with it, actually). You don't need WolfSSL just for…
That's actually not really crypto, though - that's writing a parser (for a container that includes a lot of crypto-related data). And again... if you import a 3rd-party x.509 parser and you only need DER but not BER, you've got unnecessary bloat yet again.
"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…
Batteries included systems are still susceptible to supply chain attacks, they just move slower so it’s not as attractive of a target. I think packages of a certain size need to be held to higher standards by the repositories. Multiple users should have to approve changes. Maybe enforced scans (though with trivy’s recent compromise that wont be likely any time soon) Basically anything besides lone developer can decid…
Well, there’s other things. Maven doesn’t allow you to declare “version >= x.y.z” and doesn’t run arbitrary scripts upon pulling dependencies, for one thing. The Java classpath doesn’t make it possible to have multiple versions of the same library at the same time. That helps a lot too.
NPM and the way node does dependency management just isn’t great. Never has been.
Earlier quoted context omitted.
Fetch has also lacked support for features that xhr has had for over a decade now. For example upload progress. It's slowly catching up though, upload progress is the only thing I'd choose xhr for.
You can pipe through a TransformStream that counts how many bytes you've uploaded, right?
Earlier quoted context omitted.
> They are going to be out of date whenever a standard changes (HTML, etc.) You might want to elaborate on the "etc.", since HTML updates are glacial.
The HTML "Living Standard" is constantly updated [1-6]. The PNG spec [7] has been updated several times in 1996, 1998, 1999, and 2025. The XPath spec [8] has multiple versions: 1.0 (1999), 2.0 (2007), 3.0 (2014), and 3.1 (2017), with 4.0 in development. The RDF spec [9] has multiple versions: 1.0 (2004), and 1.1 (2014). Plus the related specs and their associated versions. The schema.org metadata standard [10] is und…
I've been advocating to minimize the number of dependencies for some time now. Once you've maintained an open source project for several years, you start to understand the true cost of dependencies and you actually start to pay attention to the people behind the libraries. Popularity doesn't necessarily mean reliable or trustworthy or secure.
I'll agree with that, and you would think it's common sense for any competent engineer, but for many people it's just an afterthought. Including senior and lead engineers. General matters like security are a political liaison, how can you raise the alarm/advocate for critical security improvements as an IC without making people around and above you look bad? How can you justify time invested into these things without…