Hard Rust requirements from May onward • Hacker News Board

Re: Hard Rust requirements from May onward

#521

Post by AlotOfReading » Sat, Nov 01, 2025, 10:04 PM UTC

steveklabnik wrote: post #510

kelnos wrote: post #502

Earlier quoted context omitted.

> Formally verified _always_ beats anything else. Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?). And these days I would (unfortunately) consider assembly as an "obscure language". (At any rate, I assume Rust versions of cryptographic primitives will still have some inline a…

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.

Re: Hard Rust requirements from May onward

#522

Post by steveklabnik » Sat, Nov 01, 2025, 10:04 PM UTC

samdoesnothing wrote: post #475

steveklabnik wrote: post #464

Earlier quoted context omitted.

It’s been ten years since Rust 1.0, if that were to happen, we’d be seeing it now. But we don’t.

That makes no sense. It was much longer than 10 years before people considered C to be tech debt for example. Idk if it will be 10 years exactly, but we are seeing better languages emerging (Swift 6, Mojo, probably others) that provide the same safety guarantees and performance/use case profiles as Rust, but are vastly more ergonomic and lovely to use. I fear Linux was hasty integrating Rust because it will likely pr…

You’re the one that said ten years.

Re: Hard Rust requirements from May onward

#523

Post by julian-klode » Sat, Nov 01, 2025, 10:06 PM UTC

steveklabnik wrote: post #510

kelnos wrote: post #502

Earlier quoted context omitted.

> Formally verified _always_ beats anything else. Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?). And these days I would (unfortunately) consider assembly as an "obscure language". (At any rate, I assume Rust versions of cryptographic primitives will still have some inline a…

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

It's insanely complex, particularly you want _verified_ crypto. Last year (or two years ago?) I had to fix a tiny typo in OpenSSL's ARM assembly for example, it was breaking APT and Postgres left and right, but only got triggered on AWS :D

Re: Hard Rust requirements from May onward

#524

Post by cardanome » Sat, Nov 01, 2025, 10:07 PM UTC

JW_00000 wrote: post #195

cmm11 wrote: post #54

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

To be honest I don't really read insults either in this e-mail or in the thread you linked. If I'm seeing it right, there's only one comment by the guy in that thread, right? That comment is direct and uses language that may be considered unprofessional ("crap"/"crappy"), but it's not insulting the users (they are not referred to as crappy). Same for the e-mail. Unnecessary drama as usual...

Browser integration is a completely basic feature I expect from any password manager. It is absolutely useless for most people without it.

In fact not having it encourages copy and paste which reduces security.

Whats next? Strip javascript support from browsers to reduce the attack surface?

I don't get how this is even a discussion. Either he is paid by canonical to be a corporate saboteur or he is completely insane.

Re: Hard Rust requirements from May onward

#525

Post by noosphr » Sat, Nov 01, 2025, 10:08 PM UTC

adwn wrote: post #463

noosphr wrote: post #365

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog I don't understand how people keep giving the benefit of the doubt to corporations. They aren't people. They feel no guilt and have no shame.

Julian Klode is not a corporation, though, so we should give him the benefit of a doubt.

The whole thread started someone making the wrong point that:

>They are of no commercial interest to Ubuntu.

Which is plainly false.

Julian can believe whatever he wants, in fact the more naively idealistic he is the better for Canonical.

The fact of the matter is that corporate Linux's benefits from impossible to run setups. That's the whole business model. The more convoluted the setup is the more money they make. Rust fits into this business model perfectly.

You'd think people would have learned this after the Nth rug pull from supposed champions of free software like RedHat.

Re: Hard Rust requirements from May onward

#526

Post by pclmulqdq » Sat, Nov 01, 2025, 10:09 PM UTC

bgwalter wrote: post #480

jcranmer wrote: post #467

Earlier quoted context omitted.

> But hasn't all that foundational code been stable and wrung out already over the last 30+ years? Not necessarily. The "HTTP signature verification code" sounds like it's invoking cryptography, and the sense I've had from watching the people who maintain cryptographic libraries is that the "foundational code" is the sort of stuff you should run away screaming from. In general, it seems to me to be the cryptography f…

If you mean GnuPG, that is what Snowden used. It could be better than new software that may have new bugs. Memory safety is a very small part of cryptographic safety. (New cryptographic software can also be developed by all sorts of people. In this case I'm not familiar, but we do know that GnuPG worked for the highest profile case imaginable.)

GPG works great if you use it to encrypt and decrypt emails manually as the authors intended. The PGP/GPG algorithms were never intended for use in APIs or web interfaces.

Ironically, it was the urge not to roll your own cryptography that got people caught in GPG-related security vulnerabilities.

Re: Hard Rust requirements from May onward

#527

Post by tialaramex » Sat, Nov 01, 2025, 10:11 PM UTC

steveklabnik wrote: post #510

kelnos wrote: post #502

Earlier quoted context omitted.

> Formally verified _always_ beats anything else. Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?). And these days I would (unfortunately) consider assembly as an "obscure language". (At any rate, I assume Rust versions of cryptographic primitives will still have some inline a…

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

I would like a special purpose language to exist precisely for writing crytographic code where you always want the constant time algorithm. In this niche language "We found a 20% speed-up for Blemvich-Smith, oops, it actually isn't constant time on the Arrow Lake micro-code version 18 through 46" wouldn't even get into a nightly let alone be released for use.

It seems that for reasons I don't understand this idea isn't popular and people really like hand rolling assembly.

Re: Hard Rust requirements from May onward

#528

Post by quotemstr » Sat, Nov 01, 2025, 10:11 PM UTC

cbmuser wrote: post #442

jrmg wrote: post #133

Earlier quoted context omitted.

Here’s Debian’s “Supported Architectures”: https://wiki.debian.org/SupportedArchitectures . These platforms are all in ‘unofficial’ status (like, they work, but are not officially supported by the core Debian project). Who is actually _running_ Debian Trixie on these platforms now? It is counter-intuitive to me that these platforms are still unofficially supported, but 32-bit x86 [edit: and all MIPS architectures!] a…

They’re not going to fall to the wayside, we’re eventually getting Rust support on these. It’s just a bit annoying that Rust proponents are being so pushy in some cases as if Rust was the solution to everything.

They're >20 years old and nobody seriously uses them for modern software. Come the fuck on. Let them go.

Re: Hard Rust requirements from May onward

#529

Post by jcranmer » Sat, Nov 01, 2025, 10:11 PM UTC

steveklabnik wrote: post #510

kelnos wrote: post #502

Earlier quoted context omitted.

> Formally verified _always_ beats anything else. Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?). And these days I would (unfortunately) consider assembly as an "obscure language". (At any rate, I assume Rust versions of cryptographic primitives will still have some inline a…

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

I do think this is pretty much the one use case for a true "portable assembler", where it basically is assembly except the compiler will do the register allocation and instruction selection for you (so you don't have to deal with, e.g., the case that add32 y, x, 0xabcdef isn't an encodable instruction because the immediate is too large).

Re: Hard Rust requirements from May onward

#530

Post by RustSupremacist » Sat, Nov 01, 2025, 10:13 PM UTC

This is the same maintainer who broke KeePass on Debian and then flipped off everyone in the thread. Someone needs to pull him aside and let him know the world does not revolve around him and the problems he chooses to manufacture to justify his paycheck.

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...