261–270 of 529 posts
Earlier quoted context omitted.
Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries. I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.
Platform support is a non-issue for every library being discussed. This is an array construction macro, it has nothing to do with what operating system you're running on.
Earlier quoted context omitted.
As mentioned by others it’s just as easy for an attacker to modify a crate’s runtime code.
So? Runtime code requires actually executing the malicious code path which isn’t an immediate 100% hit rate for everyone that includes it in the dependency chain. For build.rs it’s a 100% compromise of everyone it’s in the dependency chain for. Additionally, at runtime you may not have access to secrets whereas at build time you most certainly do.
The rust ecosystem is going to be hit by malware just like the NPM ecosystem. I have been saying it for years. They made the same mistakes or even worse mistakes because all it takes is a compromised serde to take the entire ecosystem down.
Here's a suggestion, do you think it could be this simple? If you write a package-manager, don't execute any of the downloaded code in an automated fashion. No hooks, no build-time metaprograms. If your language _needs_ metaprogramming to function, it's a huge secondary issue that I don't know how to solve. You can try to make a meta-program annotation which disables side-effects, but the metaprogram ultimately must…
Supply chain attacks are not a problem that can be solved by a single silver bullet, however the biggest benefit comes from a combination of minimum release age + fresh 2FA required for every publish + automated scanning. This makes it considerably more difficult to pull off a supply chain attack and should be the baseline security for all package managers.
Earlier quoted context omitted.
So? Runtime code requires actually executing the malicious code path which isn’t an immediate 100% hit rate for everyone that includes it in the dependency chain. For build.rs it’s a 100% compromise of everyone it’s in the dependency chain for. Additionally, at runtime you may not have access to secrets whereas at build time you most certainly do.
The malicious code could use life-before-main hacks to gain code execution if it's linked at all, even if uncalled. https://grack.com/blog/2026/06/11/life-before-main/
Earlier quoted context omitted.
One of rust's strengths is it's ability to interface relatively easily with existing c code without having to rewrite absolutely everything in rust. I don't think that is something we want to give up.
build.rs changes nothing about how easy it is to integrate with C. What does simplify: figuring out how to supply library you need at build time. Which is the result of how bad dependency managment is outside (i.e. DLL-hell). Pretty much all other use cases of build.rs can be sandboxed. Well, there is sqlx that wants to connect to database at expansion time to compile check-queries (yew).
Although I suppose that's still doing a lot of shenanigans at compile time. It could be sandboxed pretty well (theoretically). I'd hate to give it up completely though, getting a compile time error when SELECT query params or return values have type mismatches is extremely nice.
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…
> There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries.
I wholeheartedly agree. Most standard libraries out there (when I say most I easily mean of 99% languages that I know) have pitifully tiny implementations. They at most provide for string parsing, io, a bare networking layer (that's at best a wrapper around the POSIX syscalls), threading and that's it. If you want to do anything more complex, you either have to roll it yourself or use an assortment of the "blessed libs" for any given language, that may or may not work properly, and may or may not even work well with each other. I got pissed off by this at some point so I decided to go ahead and roll my own standard lib that would actually have everything I need to.. actually develop apps. Now I know most people probably aren't going to be using it (mainly because its functional API isn't what most C++ devs want) but for me it's actually been brilliant.
Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high. Also most of these dependencies provide a breadth of features that the end package does probably not need.
Downloaded by_address v1.2.1
Downloaded block-buffer v0.12.1
Downloaded block-padding v0.4.2
Downloaded adler2 v2.0.1
Downloaded color_quant v1.1.0
Downloaded blowfish v0.10.0
Downloaded byteorder v1.5.0
Downloaded bytemuck_derive v1.12.0
Downloaded futures-sink v0.3.34
Downloaded bs58 v0.5.1
Downloaded critical-section v1.2.0
Downloaded fnv v1.0.7
Downloaded bytemuck v1.25.2
Downloaded form_urlencoded v1.2.2
Downloaded futures-macro v0.3.34
Downloaded futures-io v0.3.34
Downloaded blake2 v0.11.0-rc.6
Downloaded find-msvc-tools v0.1.11
Downloaded funty v2.0.0
Downloaded fdlimit v0.3.0
Downloaded ff v0.14.0
Downloaded foldhash v0.2.0
Downloaded bon v3.9.3
Downloaded fdeflate v0.3.7
Downloaded darling_core v0.23.0
Downloaded bon-macros v3.9.3Earlier quoted context omitted.
>I think we should be taking a more “batteries included” approach https://www.youtube.com/watch?v=GZOuz-SG7-g Funny how you skipped "I should build my own batteries" and when straight to "increasing and centralizing the duties of your main gratis 'vendor'".
I don't like the "bring your own" approach because unless one happens to be an absolute tour de force 10x engineer unstoppable god of a programmer (which most of us, myself included, are not), whatever you build is never going to be as well-rounded, fleshed out, and complete as something built by a larger organization, especially when it comes to UI libraries (which are monstrous projects if done right, e.g. meeting…