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

Malicious Rust crate Arrayref runs a build-time payload

safedep.io

Post reply on HN
Print view View original

361–370 of 529 posts

Re: Malicious Rust crate Arrayref runs a build-time payload

#361

Post by afdbcreid »

Pannoniae wrote: post #302
afdbcreid wrote: post #295

Earlier quoted context omitted.

> Who said a standard library can't make breaking changes? The std making a breaking change is the language making a breaking change. Most mainstream languages guarantee stability, certainly Rust. > your program is smaller How so? It doesn't matter if the code is in std or a crate. > better security because a random kid can't pwn your deps, quality and interoperability That's exactly what I said: you don't need bigge…

>Most mainstream languages guarantee stability, certainly Rust. That's their mistake, right there... When you're upgrading software, you presumably want a better version. You can't have something better without changing it. It's a logical contradiction. >It doesn't matter if the code is in std or a crate. It very much does because you don't need 95% of the random stuff in the crates. Even for something like rand, you…

> You can't have something better without changing it. It's a logical contradiction.

Sorry, that's a strawman. Of course you cannot have a better version without changing things. You definitely can have a better version without changing public API.

And people upgrade their toolchain not because they want a different API. They mostly want bugs fixed, support, and sometimes features. Breaking the API has a huge cost and minor benefit.

> It very much does because you don't need 95% of the random stuff in the crates.

But why does it matter if all that stuff comes in std or in an different crate? As I said security doesn't play a role here. You can't even avoid compile-time cost because the std can only come precompiled because it only changes with the toolchain, which is another downside we want to avoid.

> I guess that's one solution but it would probably just be a better idea to split std in two SLAs, one is guaranteed for core stuff i.e. the status quo, one is YMMV.

And again, how is that different from what I say, other than calling "official crates" as "std"?

Re: Malicious Rust crate Arrayref runs a build-time payload

#362

Post by TZubiri »

atiedebee wrote: post #352
TZubiri wrote: post #339

Earlier quoted context omitted.

If those transitive dependencies are baked into the language runtime, how is anything materially different? You just shift the vector around.

Because the standard library of a programming language has a lot more eyes on it than one of the many small dependencies does.

You are just shifting where the eyes are, the amount of eyeballs (developer time) is the same. Unless the proposal is to increase the amount of (other) developers time.

The proposal ends up amounting to either shifting stuff around, or asking to other people to put in more effort? Into a project that usually doesn't pay (programming languages and runtimes)

Which by the way, asking other people to do stuff for free IS the attack vector, if you are the kind of dev or company that gets hit by these, your ultimate root cause is that your business strategy is using code without paying for it. No such thing as a free lunch, you will pay for it, among other things, with an increased cybersecurity risk.

Re: Malicious Rust crate Arrayref runs a build-time payload

#363

Post by fc417fc802 »

derefr wrote: post #318
fc417fc802 wrote: post #296

Earlier quoted context omitted.

I agree but think the problem is slightly more general. Consider that a package could be redacted not just due to exploit but also (among other things) for legal reasons, and that such reasons could be region specific. So a redacted package might or might not be available to manually download and some other metadata is desirable so that "audit" can notify you that you were compromised.

A package redacted for legal reasons should still be able to be built too! Presumably one or the other side of the relevant suit will need the package as evidence! I would suggest that such packages should simply require authenticated access + manual “write an email to ask to have your account be put on a whitelist”-driven authorization. Such a package would still be there (in its redacted state); but attempts to dow…

I think maybe you're missing the significance of legally mandated redaction - continuing to provide access could well constitute a criminal offense depending on the specifics. And there may be many other reasons for redaction - as a sibling comment notes you certainly don't want to continue serving a package that contains sensitive private information.

I see the "exploit" case as a strict subset of redaction in which you do want to continue serving downloads to parties that explicitly acknowledge that they understand the classification of the artifact in question.

(Amusingly this exchange has led me to realize that as things currently stand a piece of malware can trivially be made illegal to distribute and thus extremely difficult to develop countermeasures for provided that the malware authors are willing to violate an additional law or three.)

Re: Malicious Rust crate Arrayref runs a build-time payload

#364

Post by afdbcreid »

josephg wrote: post #329
afdbcreid wrote: post #283

Earlier quoted context omitted.

People confuse what they want. They do not want a big stdlib. The downsides are real (the stdlib cannot make breaking changes), and there are no upsides (except, maybe, for faster compilation, since std comes precompiled). They want more official crates (e.g. `regex` and `libc` are official crates, maintained by the Rust project). And the Rust project does not oppose to that, it just doesn't have the funding.

> there are no upsides (except, maybe, for faster compilation Another big reason to put something in std is providing types for cross-crate compatibility. If I want to pass a String from one crate to another, I’m glad that string is defined in std so there’s an obvious type we can both use in our APIs. C - for example - does not have this luxury. Everyone makes their own string type, and C APIs all need to translate…

That is true, but this does not require a huge stdlib. And Rust is partially open to that (even adding async traits for IO in std is something they'll likely do in the future), but because std can't make breaking changes, you need to be very careful and slow.

Re: Malicious Rust crate Arrayref runs a build-time payload

#365

Post by mattrighetti »

cosmic_cheese wrote: post #78

I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 tot…

> I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total.

Most of the things I wrote in Rust have less than 5 dependencies. Those 5 dependencies then depend on 20 other dependencies each. Those 20 dependencies have 2-3 other dependencies. And so on…

Re: Malicious Rust crate Arrayref runs a build-time payload

#366

Post by fc417fc802 »

derefr wrote: post #360
VorpalWay wrote: post #333

Earlier quoted context omitted.

> A package redacted for legal reasons should still be able to be built too! Presumably one or the other side of the relevant suit will need the package as evidence! This doesn't make sense if the legal reason is accidental release of secrets or PI, in which case you absolutely do not want to leave it up. I'm not talking about things like github tokens here, those can be revoked. But actual secrets or PI where that i…

I mean, unless the party you’re concerned about having your secret is the maintainers of the package store itself , what’s the functional difference between “it’s deleted from our servers” and “it’s marked private so only the author [or admins of the author’s org, insofar as user accounts are org-bound] can still download it”?

If I inadvertently committed (arbitrary example) my tax returns to a repo I'd hope that the operators of the package repository would promptly destroy all copies in their possession.

Re: Malicious Rust crate Arrayref runs a build-time payload

#367

Post by wmedrano »

thayne wrote: post #198
quikoa wrote: post #182

Earlier quoted context omitted.

A language without a large stdlib pushes this that functionality into (transitive) dependencies. I hope more language will adopt batteries included approach.

No stdlib will ever include all the "batteries" you need. And large stdlibs have their own set of problems, like stagnation, tying the library version to the language version, backwards compatibility garantees preventing evolution, and either needing a wide range of domain experts to maintain it, or having developers maintain components they don't have a deep understanding of. I think the sweet spot is having an ecos…

This particular crate (arrayref) seems pretty niche, but also doable in std now.

It lets you take a slice `&[T]` and return a slice with a known number of elements`&[T; N]`. tiny-skia was probably using this to get some SIMD optimizations.

As of Jan 2026, this seems to be in the standard library under slice::as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as...

Re: Malicious Rust crate Arrayref runs a build-time payload

#368

Post by wmedrano »

cosmic_cheese wrote: post #78

I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable. I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 tot…

Ok in theory, but I don't think it applies here. Maybe it does in a cultural way.

Arrayref seems somewhat niche, but its kind of in the standard library as of Jan 2026 as std::slice::as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as...

Post reply on HN