Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

Post reply on HN
Print view View original

401–410 of 497 posts

Re: Maybe you shouldn't install new software for a bit

#401

Post by cratermoon »

jodrellblank wrote: post #391
cratermoon wrote: post #118

Earlier quoted context omitted.

Typically when hand-rolling code you implement only what you require for your use-case, while a library will be more general purpose. As a consequence of doing more, have more code and more bugs. Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. For supply chain security and bug count, I'll take a focused custom implementation of specific fea…

leftpad was a focused custom implementation of a specific feature, instead of a library full of generalized functionality. At the time it was pulled, the leftpad code (JavaScript, Node, NPM) was: module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; ch || (ch = ' '); len = len - str.length; while (++i A newer version was: https://github.com/left-pad/left-pad/blob/master/index.js w…

I realize I may have made it seem like I was saying leftpad was a general-purpose library. My aside about it was to note that even widely used libraries can still have bugs. That’s orthogonal to their scope.

Re: Maybe you shouldn't install new software for a bit

#402

Post by anthk »

jodrellblank wrote: post #391
cratermoon wrote: post #118

Earlier quoted context omitted.

Typically when hand-rolling code you implement only what you require for your use-case, while a library will be more general purpose. As a consequence of doing more, have more code and more bugs. Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. For supply chain security and bug count, I'll take a focused custom implementation of specific fea…

leftpad was a focused custom implementation of a specific feature, instead of a library full of generalized functionality. At the time it was pulled, the leftpad code (JavaScript, Node, NPM) was: module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; ch || (ch = ' '); len = len - str.length; while (++i A newer version was: https://github.com/left-pad/left-pad/blob/master/index.js w…

That's almost the first literal exercise with strings you'll learn with "The C prog lang 2nd ed" ebook. One of the most trivial cases among writting a word/space/tabs counting program (wc under Unix).

Re: Maybe you shouldn't install new software for a bit

#403

Post by abustamam »

This advice is good even if there weren't security vulnerabilities. When I was a junior engineer I'd install a bunch of packages just willy nilly. My manager was like "stop installing packages for simple things. Just learn how they work and code it yourself."

I've done that ever since. Of course, I still use packages like express and tailwindcss. But in the era of LLMs, using a package for something like react drop-downs is unnecessary.

Re: Maybe you shouldn't install new software for a bit

#404

Post by Phelinofist »

CriticalRegion wrote: post #288
Phelinofist wrote: post #281

Earlier quoted context omitted.

Either my reading of your comment is wrong or you misunderstood the supply chain comment by OP I think: what they mean is that a supply chain attack that gets the exploit on a system would be great now because the reported vulns are unfixed pretty much everywhere

No, you read it right. I just misunderstood the post's message as "these exploits will enable more supply chain attacks". I'll probably delete my comment since it's debating a strawman. It is absolutely right that these exploits might enable these attacks to have a larger impact. I still don't think that I agree with the message since a malicious npm package already installed can get its payloads from a C2 server, it…

> since a malicious npm package already installed can get its payloads from a C2 server, it doesn't need an npm update

In general I agree, but I think these two vulns are 0day-y and pretty much every major distro is affected AFAIU, so there is perhaps slightly more potential than usual

Re: Maybe you shouldn't install new software for a bit

#405

Post by cratermoon »

akoboldfrying wrote: post #124
cratermoon wrote: post #118

Earlier quoted context omitted.

Typically when hand-rolling code you implement only what you require for your use-case, while a library will be more general purpose. As a consequence of doing more, have more code and more bugs. Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certain edge doses properly. For supply chain security and bug count, I'll take a focused custom implementation of specific fea…

Yes, a lot hinges on how little you can get away with implementing for your use case. If you have an XML config file with 3 settings in it, you probably won't need to implement handling of external entities the way a full XML parsing library would, which will close off an entire class of attendant vulnerabilities. > Also, even seemingly trivial libraries can have bugs. The infamous leftpad library didn't handle certa…

I’m not aware of any memory corruption bugs, but some weird cases where Linux, stuck with legacy 8-bit character handling for filenames and paths, lead to unesirable behavior with Rust’s native Unicode strings.

The race conditions were indeed TOCTOU bugs. In a sense, the bugs were a result of incorrectly handling shared mutable data, though in this case the mutations were external to Rust.

https://corrode.dev/blog/bugs-rust-wont-catch/

Re: Maybe you shouldn't install new software for a bit

#406

Post by dingocat »

0xbadcafebee wrote: post #38

"Wait a week to install software" does not work. Just a few months ago a massive exploit hit the web, which was a timed attack which sat for more than a month before executing. If everyone starts waiting a week, their exploits will wait 2 weeks. Cyber criminals do not need to exploit you immediately, they just need to exploit you. (It also doesn't change a large range of vuln classes like typosquatting)

You're throwing the baby out with the bathwater, though. Waiting a week still prevents a decent amount of attacks. Not every attack can evade detection for two weeks. Even if it did, security scanning tools might still detect them.

Say hypothetically that 20% of attack slip through, which is still worrying, you can mitigate 80% of attacks by just waiting a week. It's a low risk, high reward strategy.

Re: Maybe you shouldn't install new software for a bit

#407

Post by kibwen »

pjmlp wrote: post #213
c7b wrote: post #162

Earlier quoted context omitted.

My pet theory is that package managers will one day be seen like we see object-oriented programming today. As something that was once popular but that we've since grown out of. It's also a design flaw that I see in cargo/Rust. Having to import 3rd party packages with who-knows-what dependencies to do pretty much anything, from using async to parsing JSON, it's supply chain vulnerability baked into the language philos…

Rust is quite bad on this, having to rely on external crates for error handling or macros is even worse than what async runtime to pick up. Yes, I mean crates like anyerror and syn.

I'm all for including more things in the Rust standard library, but anyhow and syn are literally from a core Rust dev. It's not some left-pad rando, it's like a Linux user saying they don't trust the Git developer.

Re: Maybe you shouldn't install new software for a bit

#408

Post by Joeri »

marcus_holmes wrote: post #57

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face. But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to…

Blaming the victim is too easy. NPM is unsafe at any speed. You cannot use it in any but the most trivial capacities without opening yourself up to supply chain attacks.

Why is npm the only package ecosystem that has so many problems? What are the other package system owners doing better? Let’s start there, instead of blaming the victims.

Re: Maybe you shouldn't install new software for a bit

#409

Post by kibwen »

c7b wrote: post #179
weregiraffe wrote: post #168

Earlier quoted context omitted.

But you can't expect the language std to supply you with every package under the sun.

I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer. One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable pack…

> C/C++ are doing fine without package managers.

More or less the entire Debian apparatus is an organization devoted to being a C/C++ package manager, and while as an end-user it's adequate for installing applications it's still an enormous pain to use packages as libraries even with apt and friends. And once you get outside of apt, you're in an endless hellscape. People don't seem to understand that the real reason that people love Rust is not because of memory safety (let's be honest, most people are too short-sighted to care about that); it's because of Cargo.

Re: Maybe you shouldn't install new software for a bit

#410

Post by kibwen »

pjmlp wrote: post #214
c7b wrote: post #179

Earlier quoted context omitted.

I don't have an answer what the alternative is going to look like. But smarter people than me may find something. C/C++ are doing fine without package managers. Go at least has a more capable standard library than Rust. But I'm not sure if Go's import github approach is the answer. One idea I've been entertaining is to not allow transitive imports in packages. It would probably lead to far fewer and more capable pack…

In C and C++'s case, the batteries included is POSIX + Khronos.

In this analogy, the battery is the Leiden jar cobbled together by Benjamin Franklin in 1750. It's 2026, POSIX is unfit for purpose.
Post reply on HN