OHNONONNO RUST BROS I THOUGHT WE WERE SECURE!?!?

OHNONONNO RUST BROS I THOUGHT WE WERE SECURE!?!?

Attached: 3DB63E7F-E5CE-432E-B23D-FFEE84B22CD8.jpg (1170x1941, 1.58M)

YWNBAW

kek.
langmixing with Go gave Rustoids an STD

>typosquatted malicious dependency
Nothingburger.

Can you still get stds if you remove benis?

but at the end of the crate it stated
>stand with Ukraine
so the crate author was allowed to stay

Typosquatting is not a supply chain attack

Meanwhile the Cargo team sits around and does literally nothing about typo squatting. They are probably boiling xenoestrogens out of plastic bags whilst little Timmy just got pwned by typing _ instead of -

Good. Illiterates should not use computers

I would abstain from fucking monkeys these days... cut your penis before you regret it, rust sisters now is the time

It turns out C++ has none of these weaknesses

Enjoy your memory corruption

If you're a retard who can't write, how does C++ protect you from downloading a typosquatted dependency?

By making dependencies so hard to download, build, and integrate into projects that you rewrite them from scratch instead. Go ahead and look at any large C/C++ project and you'll find tons of untested, unfuzzed reimplementations of things that would be easy to use libraries in any other language.

The one thing I think Rust did unquestioningly wrong is build.rs. I'm less certain if they could get away without it given Rust's use-cases, but not running any third party code at build time is one of the very few advantages Go has over Rust.

>The one thing I think Rust did unquestioningly wrong is build.rs.
>not running any third party code at build time is one of the very few advantages Go has over Rust.
How does that work? Surely any project that's not just a bunch of Go code is going to need to run some kind of build script to generate resources, compile other languages, etc.

>Surely any project that's not just a bunch of Go code
Running the cgo compiler isn't third party code, so it can at least link to C code.

>run some kind of build script to generate resources, compile other languages, etc.
That all has to be done manually, and any package that requires it is not go gettable and is usually not usable in a big build. Often you will find that the package maintainer has run that generation script themselves and committed the generated files to make their package go gettable. The Go model has some massive shortcomings of its own but it has the significant advantage that if you make a typo you won't immediately execute some of the typosquatter's code.

>with Go Malware
lol based

Attached: golang-1.png (600x600, 52.95K)

>Often you will find that the package maintainer has run that generation script themselves and committed the generated files to make their package go gettable.
That seems like a pretty awkward workaround.

>but it has the significant advantage that if you make a typo you won't immediately execute some of the typosquatter's code.
How much does that actually matter? You've still compiled a malicious binary, so you're just as compromised once you run that. Also, an attacker could put whatever they like into the automated tests.

>How much does that actually matter?
It makes a difference for things like CI pipelines and whatnot where the machine doing the building isn't building it. If a CI machine becomes compromised then it can inject malicious code into unrelated binaries. In practice doing proper virtualization and containerization should be as good but those aren't perfect and a lot of people don't even try. Also a lot of devs are just running things on their own workstations or desktops.

>That seems like a pretty awkward workaround.
Yeah it is. I don't think the Go model is perfect, in fact it might be overall worse then cargo/npm/etc, but it does have that one advantage. For the one personal project I have where I am writing something to run in the browser, I did put in the effort recently to push npm into a docker container. But for cargo I haven't since there's a solid two, even three, orders of magnitude less dependencies involved in my typical Rust projects compared to that one typescript project to audit. Even my worst Rust project in terms of dependencies is still less than a tenth.

> Enjoy your memory corruption
unsafe
unsafe
unsafe
unsafe

> By making dependencies so hard to download, build, and integrate into projects that you rewrite them from scratch instead.
C++ makes you think a bit about whether a dependency is worth it. And how you’re going to use it.

If rust is trying to market itself as a secure language then the biggest barrier to import a package from the internet should not be the time it takes to type the name. Secure code takes careful thought and deliberate design. A compiler cannot substitute for that. Rust combines a false sense of security with a culture and toolset that is outright dangerous