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

Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

edera.dev

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#51

Post by aDyslecticCrow »

kibwen wrote: post #29
aDyslecticCrow wrote: post #11

Earlier quoted context omitted.

I personally suspect it's an effect of the over reliance of the package manager approach to software development that rust and a few other languages use, which itself is an unintended to consequence of a well designed library import system. Languages where importing a library is hard, libraries tend to grow quite large. Large libraries have larger backing, more established development and security protocols. When Ope…

But Rust doesn't have an abundance of small/atomic libraries. This is describing NPM, not crates.io. Rust doesn't have the same culture as Node.

It's a range, but rust is closer to Node than it is to c and c++ in this culture.

I would probably place rust in-between python and node. It is made worse by the relative in-maturity of the ecosystem which contributes to the fragmentation. Rust will likley improve, but I have little faith for Node, as it's cultural as you mention.

Case in point; here is a list of most used crates. Some of these contain a single macro or wrapper. https://lib.rs/std

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#52

Post by TZubiri »

Ygg2 wrote: post #30
TZubiri wrote: post #23

Earlier quoted context omitted.

1. Radical new paradigm that critiques and disregards most of the traditional infrastructure. 2. Completely FOSS, barely any salaried devs, if any they are donation based. 3. Culture for code "reuse" instead of actually coding. Everyone wants it in their own flavour (we have tar, but I kinda want async-oop-tar) 4. Cognitive dissonance between 3 and 1, rusties don't want to succumb and use a standard tar library becau…

> rusties don't want to succumb and use a standard tar library because of performance (self inflicted performance hit from creating an incompatible ecosystem) or pride (we need a version written in rust). Pure BS. If I wrote something in Rust rather than a binding it was because using often Linux based C libs on all Tier 1 platform is as smooth of a process as swimming in shards of glass.

While developer experience is obviously a positive, in tradeoff engineering it ranks very low. It is even the sign of a narcissistic developer who values their experience over the user's.

Also even if you aim for DX it is very subjective which causes fragmentation, which causes abandonment and other issues, as mentioned in my comment.

This is a job sir, if it's painful that's to be expected ( and probably unavoidable too, in 30 years the new generation will hate your "smooth" DX)

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#53

Post by Ygg2 »

TZubiri wrote: post #52
Ygg2 wrote: post #30

Earlier quoted context omitted.

> rusties don't want to succumb and use a standard tar library because of performance (self inflicted performance hit from creating an incompatible ecosystem) or pride (we need a version written in rust). Pure BS. If I wrote something in Rust rather than a binding it was because using often Linux based C libs on all Tier 1 platform is as smooth of a process as swimming in shards of glass.

While developer experience is obviously a positive, in tradeoff engineering it ranks very low. It is even the sign of a narcissistic developer who values their experience over the user's. Also even if you aim for DX it is very subjective which causes fragmentation, which causes abandonment and other issues, as mentioned in my comment. This is a job sir, if it's painful that's to be expected ( and probably unavoidable…

This isn't just a developer experience. It's user experience as well. As in "shit doesn't work on my Windows Arm."

Sure reuse where possible, but sometimes you need to rewrite.

> which causes abandonment and other issues, as mentioned in my comment.

Did Linux being written in C stop Intel from abandoning it? The abandonment issues mentioned are mostly orthogonal.

C stopping retreat of corporations from the open source space, is about as likely as a paper mache figure will have an effect on the Dark matter distribution. You are suggesting picking prog. languages will have an effect on global economics.

C being unpopular and thus not picked for development is more due to it being a very footgunny language, without modern programming language conveniences. Like package management or linters available out of the box.

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#54

Post by TZubiri »

Ygg2 wrote: post #53
TZubiri wrote: post #52

Earlier quoted context omitted.

While developer experience is obviously a positive, in tradeoff engineering it ranks very low. It is even the sign of a narcissistic developer who values their experience over the user's. Also even if you aim for DX it is very subjective which causes fragmentation, which causes abandonment and other issues, as mentioned in my comment. This is a job sir, if it's painful that's to be expected ( and probably unavoidable…

This isn't just a developer experience. It's user experience as well. As in "shit doesn't work on my Windows Arm." Sure reuse where possible, but sometimes you need to rewrite. > which causes abandonment and other issues, as mentioned in my comment. Did Linux being written in C stop Intel from abandoning it? The abandonment issues mentioned are mostly orthogonal. C stopping retreat of corporations from the open sourc…

>Windows Arm

That's both an obscure and a complicated OS/Arch combination.

>Intel abandoned Linux

I don't understand, Intel never maintained Linux.

>C being unpopular

Lol

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#55

Post by Ygg2 »

TZubiri wrote: post #54
Ygg2 wrote: post #53

Earlier quoted context omitted.

This isn't just a developer experience. It's user experience as well. As in "shit doesn't work on my Windows Arm." Sure reuse where possible, but sometimes you need to rewrite. > which causes abandonment and other issues, as mentioned in my comment. Did Linux being written in C stop Intel from abandoning it? The abandonment issues mentioned are mostly orthogonal. C stopping retreat of corporations from the open sourc…

>Windows Arm That's both an obscure and a complicated OS/Arch combination. >Intel abandoned Linux I don't understand, Intel never maintained Linux. >C being unpopular Lol

> That's both an obscure and a complicated OS/Arch combination.

Ok. A more realistic example. I want to develop a Windows game, because that's where the audience is. And I want to develop my game in Rust, because I know it better than C++.

So, I need a tar/zar/mar library that exists on Linux as a C lib or Rust native library. My goal is to finish the game but don't care about performance or even CVEs that much.

> Intel never maintained Linux

They definitely did maintain several drivers, and Clear Linux Distribution.

But I was talking about their overall strategy. They are pivoting to "Intel first" mantra, sacking many Linux driver maintainers.

https://www.theregister.com/2025/10/09/intel_open_source_com...

> Lol

What niche is it popular now that hasn't been devoured by C++, Java and others?

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#56

Post by int_19h »

pjmlp wrote: post #48
kibwen wrote: post #46

Earlier quoted context omitted.

No, this is mistaken. A crate is both rustc's unit of compilation and Cargo's unit of dependency. Feel free to lament this conflation all you like, but what it means is that the common pattern is for library authors to publish large crates that are internally split into smaller crates for better compilation parallelism. This just isn't a problem by any metric; it doesn't increase your trusted computing base. That's n…

It is surely a problem given the cumulative time everyone waits compiling them distributed across Rust users. Also if it wasn't a problem, articles like this wouldn't exist, https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-...

If the same code was all aggregated in a single large crate, it would still be compiled as a single unit, so I don't see how it would affect compilation times. And, of course, that is orthogonal to security issues.

That pip/npm/cargo model doesn't play well with distro package managers is not a new thing. I think that eventually the distro packagers will have to bite the bullet and just start packaging apps that need any of these as bundles (which, yes, means that they need to be serviced separately for security updates; but there's no reason why the metadata used to decide when that is necessary should be the same as install-time package dependency graph).

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#57

Post by int_19h »

Veserv wrote: post #21
normie3000 wrote: post #17

Earlier quoted context omitted.

I haven't seen this perspective before but it's a very elegant explanation for why e.g. npm is so much scarier than maven. I wonder if safety could be improved a little if private package management was easier than throwing things out in public.

Newer languages have made packaging and importing dependencys significantly easier, but have done this while increasing coupling and making switching dependencys harder. This results in brittle dependency trees. Using a private package manager, intermixing private and public, and substituting arbitrary dependencys with compatible alternatives, i.e. modularity, should be easy. Only then does solving the problem become…

> What we used to have is a big ball of mud. Modern languages made it easier to decompose a system into components. But what we really want is easily decomposing a system into modular components which is yet unsolved.

We need to take modularity a lot more seriously, and by this I don't mean just making things more pluggable, but also well-defined component boundaries and contracts on them.

Sadly a lot of this stuff is moving at a glacial pace, and little of it is mainstream. Design-by-contract was introduced 40 years ago, and yet no mainstream PL in use offers anything past the bare minimum (asserts). Niche tech like Ada SPARK is picking it up, but even there it took decades.

And now we throw AI into the mix and expect things to work. Madness.

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#58

Post by int_19h »

TZubiri wrote: post #54
Ygg2 wrote: post #53

Earlier quoted context omitted.

This isn't just a developer experience. It's user experience as well. As in "shit doesn't work on my Windows Arm." Sure reuse where possible, but sometimes you need to rewrite. > which causes abandonment and other issues, as mentioned in my comment. Did Linux being written in C stop Intel from abandoning it? The abandonment issues mentioned are mostly orthogonal. C stopping retreat of corporations from the open sourc…

>Windows Arm That's both an obscure and a complicated OS/Arch combination. >Intel abandoned Linux I don't understand, Intel never maintained Linux. >C being unpopular Lol

I wouldn't say that Windows/ARM is that obscure anymore, not when there are quite a few laptops on the market with it.

But, by the same token, it's not an exotic dev platform. The compilers are there, the libraries already have to compile on Linux/ARM as well as Windows/x64, which means that the same C code will usually compile and work just fine on Windows/ARM.

So yeah, no, that's not a valid reason to rewrite it in Rust.

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#59

Post by int_19h »

kobebrookskC3 wrote: post #36
greatgib wrote: post #24

I'm so confused, I was thinking that we were rewriting everything from C to Rust because Rust was a "safe language" preventing vulnerabilities...

if it was in c, who knows how many memory corruption bugs would be found before they stumbled upon this...

In C, the library in question would already be many decades old and with minimal churn, and thus those memory corruption bugs would have been discovered long ago.

There are advantages to building on mature foundations, even if techniques used to build those foundations are dated by modern standards.

Post reply on HN