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

APT Rust requirement raises questions

lwn.net

Post reply on HN
Print view View original

201–210 of 508 posts

Re: APT Rust requirement raises questions

#201

Post by SAI_Peregrinus »

Muromec wrote: post #88
mrob wrote: post #33

The announcement says: >In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing. I can understand the importance of safe signature verification, but how is .deb parsing a problem? If you're installing a malicious package you've already lost. There's no need to exploit the parser when the user h…

It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature. Also there is aspect of defence in depth. Maybe you can compromise one package that itself can't do much, but installer runs with higher priviledges and has network access. Another angle -- installed package may compromise one container, while a bug in apt can compromise the environment which provi…

> It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature.

Yes, .deb violates the cryptographic doom principle[1] (if you have to perform any cryptographic operation before verifying the message authentication code (or signature) on a message you’ve received, it will somehow inevitably lead to doom).

Their signed package formats (there are two) add extra sections to the `ar` archive for the signature, so they have to parse the archive metadata & extract the contents before validating the signature. This gives attackers a window to try to exploit this parsing & extraction code. Moving this to Rust will make attacks harder, but the root cause is a file format violating the cryptographic doom principle.

[1] https://moxie.org/2011/12/13/the-cryptographic-doom-principl...

Re: APT Rust requirement raises questions

#202

Post by bobbylarrybobby »

xscott wrote: post #165
movpasd wrote: post #84

Earlier quoted context omitted.

You might this blog post interesting, which argues that it's Rust semantics and not syntax that results in the noisiness, i.e.: it's intrinsic complexity: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html I found it reasonably convincing. For what it's worth, I found Rust's syntax quite daunting at first (coming from Python as well), but it only took a few months of continuous use to get used to it. I think…

I'm not sure which of the dozen Rust-syntax supporters I should reply to, but consider something like these three (probably equivalent) syntaxes: let mut a = Vec:: ::new(); let mut b = >::new(); let mut c = >::new(); let mut d: Vec = Vec::new(); Which one will your coworker choose? What will your other corworkers choose? This is day one stuff for declaring a dynamic array. What you really want is something like: let…

I've only ever seen `a` and `d`. Personally I prefer `a`. The only time I've seen `c` is for trait methods like `>::func`. Noisy? I guess. Not sure how else this could really be written.

Re: APT Rust requirement raises questions

#203

Post by Havoc »

leoh wrote: post #87

I hate learning new things. It sucks. Also, I hate things that make my knowledge of C++ obsolete. I hate all the people that are getting good at rust and are threatening to take away my job. I hate that rust is a great leveler, making all my esoteric knowledge of C++ that I have been able to lord over others irrelevant. I hate that other people are allowed to do this to me and to do whatever they want, like making th…

Think tech space isn’t for you if you hate learning new things.

Re: APT Rust requirement raises questions

#204

Post by tyfon »

I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust.

There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far.

The computer runs modern linux just fine, I just wish the rust team would at least release an "i386" boostrap binary that actually works on all i386 like all of the other compilers.

"We don't care about retro computers" is not a good argument imho, especially when there is an easy fix. It was the same when the Xorg project patched out support for RAMDAC and obsoleted a bunch of drivers instead of fixing it easily. I had to fix the S3 driver myself to be able to use my S3 trio 64v+ with a new Xorg server.

/rant off

Re: APT Rust requirement raises questions

#205

Post by yoyohello13 »

tcfhgj wrote: post #32
chillfox wrote: post #21

Earlier quoted context omitted.

[flagged]

actually a vegan has to preach to some degree, otherwise it would be like a human rights advocate looking away when humans are tortured

Frankly, I more often see meat eaters get defensive. We got to a restaurant, the vegan guy gets a meatless meal. The vegan guy gets bombarded with "Oh, you don't eat meat?" "Why?" "What's wrong with eating meat?" "I just like having a steak now and then."

Re: APT Rust requirement raises questions

#206

Post by eichin »

ndiddy wrote: post #73
gorgoiler wrote: post #54

Earlier quoted context omitted.

There are many high profile DDs who work or have worked for Canonical who are emphatically not the inverse — Canonical employees who are part of the Debian org. The conclusion you drew is perfectly reasonable but I’m not sure it is correct, especially when in comparison Canonical is the newcomer. It could even be seen to impugn their integrity.

If you look at the article, it seems like the hard dependency on Rust is being added for parsing functionality that only Canonical uses: > David Kalnischkies, who is also a major contributor to APT, suggested that if the goal is to reduce bugs, it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats that Klode mentioned from APT entirely. It is only needed for two tools, apt-ftparc…

Mmm, apt-ftparchive is pretty useful for cooking up repos for "in-house" distros (which we certainly thought was serious...) but those tools are already a separate binary package (apt-utils) so factoring them out at the source level wouldn't be particularly troublesome. (I was going to add that there are also nicer tools that have turned up in the last 10 years but the couple of examples I looked at depend on apt-utils, oops)

Re: APT Rust requirement raises questions

#207

Post by SoftTalker »

saghm wrote: post #47
epolanski wrote: post #11

Earlier quoted context omitted.

The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality. There's lunatics that want to replace basic Unix tools like sudo, etc, that are battle tested since ages which has been a mess of bugs till now. Instead Rust should find it's niches beyond rewriting what works, but tackling what doesn't.

FWIW sudo has been maintained by an OpenBSD developer for a while now but got replaced in the base system by doas. Independent of any concerns about Rust versus C, I don't think it's quite as unreasonable as you're claiming to consider alternatives to sudo given that the OS that maintains it felt that it was flawed enough to be worth writing a replacement for from scratch.

sudo had grown a lot of features and a complicated config syntax over the years, which ended up being confusing and rarely needed in practice. doas is a lot simpler. It wasn't just a rewrite of a flawed utility but a simplification of it.

Re: APT Rust requirement raises questions

#208

Post by rrmm »

gorgoiler wrote: post #92

”[One] major contributor to APT suggested it would be better to remove the Rust code entirely as it is only needed by Canonical for its Launchpad platform. If it were taken out of the main APT code base, then it would not matter whether they were written in Rust, Python, or another language, since the tools are not directly necessary [for regular installations].” Given the abundance of the hundreds of deb-* and dh-*…

If this could be done it seems like the ideal compromise. Everyone gets what they want.

That said eventually more modern languages will be dependencies of the tools one way or another (and they should). So probably Debian as a whole should come to a consensus on how that should happen, so it can happen in some sort of standard and fair fashion.

Re: APT Rust requirement raises questions

#209

Post by surajrmal »

inetknght wrote: post #104
fn-mote wrote: post #20

The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt. > it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats [...] from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates [...] Another interesting, although perhaps tangential, criticism was that th…

> the "new solver" currently lacks a testsuite To borrow a phrase I recently coined: If it's not tested then it's not Engineered. You'd think that core tools would have proper Software Engineering behind them. Alas, it's surprising how many do not.

Integration tests are still tests. There are definitely cases for tools where you can largely get by without unit tests in favor of integration tests. I've written a lot of code generation tools this way for instance.

Re: APT Rust requirement raises questions

#210

Post by stingraycharles »

mbel wrote: post #131
stingraycharles wrote: post #52

Earlier quoted context omitted.

Seems like a fairly decent syntax. It’s less simple than many systems languages because it has a very strong type system. That’s a choice of preference in how you want to solve a problem. I don’t think the memory safety guarantees of Rust could be expressed in the syntax of a language like C or Go.

> It’s less simple than many systems languages because it has a very strong type system. I don’t think that’s the case, somehow most ML derived languages ended up with stronger type system and cleaner syntax.

Is ML a systems language? Sorry, maybe my definition is wrong, but I consider a systems language something that’s used by a decent amount of OS’es, programming languages and OS utilities.

I assume you’re talking about OCaml et al? I’m intruiged by it, but I’m coming from a Haskell/C++ background.

Rust is somewhat unique in terms of system language this because it’s the first one that’s not “simple” like C but still used for systems tools, more than Go is as far as I’m aware.

Which probably has to do with its performance characteristics being close to the machine, which Go cannot do (ie based on LLVM, no GC, etc)

Post reply on HN