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

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

611–620 of 797 posts

Re: Hard Rust requirements from May onward

#611

Post by zahlman »

dcsommer wrote: post #227
gpm wrote: post #202

Earlier quoted context omitted.

Not really. All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs. There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes th…

> basically fine How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.

How many ways to cause a segmentation fault in CPython, that don't start with deliberate corruption of the bytecode, are you aware of?

How is "type confusion" a security issue?

Re: Hard Rust requirements from May onward

#612

Post by steveklabnik »

AlotOfReading wrote: post #521
steveklabnik wrote: post #510

Earlier quoted context omitted.

With crypto, you really want to just write the assembly, due to timing issues that higher level languages simply cannot guarantee.

You don't want to write the whole thing in assembly, just the parts that need to be constant time. Even those are better written as called subroutines called from the main implementation. Take BLAKE3 as an example. There's asm for the critical bits, but the structural parts that are going to be read most often are written in rust like the reference impl.

Yes, for sure.

Re: Hard Rust requirements from May onward

#613

Post by cozzyd »

stefan_ wrote: post #601
cozzyd wrote: post #596

Earlier quoted context omitted.

this is not normally a problem for a distro where the environment is well known

It is such a non problem it forced them to hack a „fuck you this Python is owned by the distribution not you“ message into pip requiring you to agree to „breaking your system“ to use it. Of all the languages, python in the base system has been an unmitigated garbage fire.

yes because then you're starting to use non-distro python packages. If you want to do that, use a virtualenv, there is no safe other way (even if there was no python in the base system) .

Re: Hard Rust requirements from May onward

#614

Post by zahlman »

krater23 wrote: post #235
lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

Memory safety is mostly a issue of the past. Clearly, there are new code bases with memory issue too. But we have tools to prevent that. The new security issues are supply chain attacks. And Cargo is the way to have exactly this.

As GvR famously reminded everyone in 2011, a language and its packaging system are separate things.

But Rust, you know, has one.

Re: Hard Rust requirements from May onward

#615

Post by OneDeuxTriSeiGo »

jenadine wrote: post #579
embedding-shape wrote: post #386

Earlier quoted context omitted.

> Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious. I think any projects that are run by people that see themselves as "X-people" (like Python-people, Perl-people) always have a bit "ick" reaction to new languages being added to projects they might see as part of a language's community. So say you're a C++ developer, contributed to…

I was (and am still) a C++ person. But I somehow became also a Rust person. I am sure some people felt attacked, but imho Rust has most of the characteristics that made C++ a good language and that's why I "embraced" Rust rather than felt attacked.

Yeah rust is not C++ but it really compliments C++ well. Each has their niche and tbh I see them converging into the two kings of the systems space rather than actually competing with each other.

Re: Hard Rust requirements from May onward

#616

Post by stefan_ »

cozzyd wrote: post #613
stefan_ wrote: post #601

Earlier quoted context omitted.

It is such a non problem it forced them to hack a „fuck you this Python is owned by the distribution not you“ message into pip requiring you to agree to „breaking your system“ to use it. Of all the languages, python in the base system has been an unmitigated garbage fire.

yes because then you're starting to use non-distro python packages. If you want to do that, use a virtualenv, there is no safe other way (even if there was no python in the base system) .

Yes, the distro people are strong believers in virtual environments as best practice - for you, not them.

Re: Hard Rust requirements from May onward

#617

Post by woodruffw »

bsder wrote: post #568
woodruffw wrote: post #544

Earlier quoted context omitted.

I'm not following: Rust excels at C interop, so why wouldn't you use the OEM drivers/SDK and bind them through Rust for your own code? That's what I've always done when I need to interact with a C library in Rust.

> I'm not following: Rust excels at C interop Zig is an example of excelling at C interop--not Rust. And Cargo is an impediment in the embedded ecosystem rather than a bonus. Part of why we're getting Rewrite-it-in-Rust everywhere is precisely because the C interop is sufficiently weak that you can't do things easily in a piecemeal fashion. And lets not talk about Rust compile times and looking at Rust code in a debu…

I don't have strong opinions in either direction about Zig. But there's clear empirical evidence that Rust has a successful C interop story[1][2][3].

And note: browsers are the pathological case, in terms of build system integrations, global state assumptions, C++, etc.

(Your other complaints have a place, and don't seem unreasonable to me. But they're empirically not impediments to Rust's interop story.)

[1]: https://chromium.googlesource.com/chromium/src/+/refs/heads/...

[2]: https://firefox-source-docs.mozilla.org/build/buildsystem/ru...

[3]: https://www.memorysafety.org/blog/rustls-nginx-compatibility...

Re: Hard Rust requirements from May onward

#618

Post by pdntspa »

stefan_ wrote: post #601
cozzyd wrote: post #596

Earlier quoted context omitted.

this is not normally a problem for a distro where the environment is well known

It is such a non problem it forced them to hack a „fuck you this Python is owned by the distribution not you“ message into pip requiring you to agree to „breaking your system“ to use it. Of all the languages, python in the base system has been an unmitigated garbage fire.

People are too harsh on this. It's not hard to install a version manager and set your primary python to that. Which is just good hygiene.

My understanding of the reasoning is that python-based system packages having dependencies managed through pip/whatever present a system stability risk. So they chose this more conservative route, as is their MO.

Honestly if there is one distribution to expect those kinds of shennanigans on it would be Debian. I don't know how anybody chooses to use that distro without adding a bunch of APT sources and a language version manager.

Re: Hard Rust requirements from May onward

#620

Post by bgwalter »

zahlman wrote: post #606
stefan_ wrote: post #601

Earlier quoted context omitted.

It is such a non problem it forced them to hack a „fuck you this Python is owned by the distribution not you“ message into pip requiring you to agree to „breaking your system“ to use it. Of all the languages, python in the base system has been an unmitigated garbage fire.

> it forced them to hack a It was not their action, nor is it hacked, nor is the message contained within pip. The system works by pip voluntarily recognizing a marker file, the meaning of which was defined by https://peps.python.org/pep-0668/ — which was the joint effort of people representing multiple Linux distros, pip, and Python itself. (Many other tools ignore the system Python environment entirely, as mine wil…

Well the essential system Python should be in /usr/sbin and read-only (insofar Python allows that with its __pycache__ spam).

The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken.

Post reply on HN