Hacker News Reader

Comment by Macha | Hacker News Reader

To be blunt:

If you compile my Rust library against dependencies that are not compatible as declared in Cargo.toml, the result is on you. If you want to regenerate a compatible Cargo.lock, that would be more understandable, and I don't go out of my way to specify "=x.y.z" dependencies in my Cargo.toml, so I have effectively given permission for that anyway.

They give the example of Debian "bumping" dependencies, but given the relative "freshness" of your typical Rust package vs say... Debian stable, I imagine the more likely outcome would be downgrading dependencies.

This reminds me of the time Debian developers "knew better" with the openssh key handling...

View on HN

To be blunt: if your library requires me to handle it differently than all the other software that exists, it's a bad library. If you break compatibility every week you should not be writing a library at all.

> This reminds me of the time Debian developers "knew better" with the openssh key handling...

How much % of the CVEs that exists are from debian patches and how much is upstream developers? Can you confidently claim that upstream developers are better at security than debian developers? Or are you just picking a single example and ignoring all the rest of the data that you don't like?

I have 3794 packages currently installed on my machines. If all of them required special handling like your snowflake library I'd just not be using a computer at all, because I certainly don't have the capacity to deal with 3794 special snowflakes.

> I certainly don't have the capacity to deal with 3794 special snowflakes.

It's hardly unique. Every major language other than C/C++ (and Python, but Python is just a mess in general) works like Rust here. If anything I'd say it's the C people who are the snowflakes.

> Can you confidently claim that upstream developers are better at security than debian developers?

I can confidently claim that upstream has better policies. Debian routinely patches security-critical software without dedicated security review; this predictably lead to disaster in the past and will lead to disaster again.

Also the Debian SSL key bug was not just one more CVE on a par with any other. It was probably the worst security bug ever seen in general-purpose software.

> I can confidently claim that upstream has better policies.

Debian has thousands of different upstream, you don't even know who they are, how can you claim to know their policies and to have evaluated all of them?

Also, all the 1 person projects do not get fixes in a timely manner. As you would understand if there was any amount of reasoning behind your arguments.

Are you done making stuff up or must you continue?

> Also the Debian SSL key bug

1. Shit happens

2. If you want random data you read from /dev/random, an uninitialised buffer is NOT random.

3. If your example dates to over a decade ago, I'd say the track record is excellent.

> Debian has thousands of different upstream, you don't even know who they are, how can you claim to know their policies and to have evaluated all of them?

Thousands of upstreams yes, thousands for security-critical software no.

> 2. If you want random data you read from /dev/random, an uninitialised buffer is NOT random.

That's not what was happening. Now who's making stuff up?

> 3. If your example dates to over a decade ago, I'd say the track record is excellent.

The worst bug in regular software had to happen at some point in time, it happens to have happened over a decade at all. It's not like Debian's record has been spotless since then.

> Thousands of upstreams yes, thousands for security-critical software no.

Everything is security critical.

> That's not what was happening. Now who's making stuff up?

You, who didn't read the mailing list exchange

> The worst bug in regular software had to happen at some point in time

??? How did you classify it? Were there any other contenders? Can you share which contenders were there?

> Debian routinely patches security-critical software without dedicated security review

This is untrue. Provide some evidence or withdraw your false claim. Thanks.

They patched openssh without dedicated security review...which directly allowed the xz backdoor debacle. Checks out to me.

If you expect a bsd software to run unpatched on linux… I don't know what to say to you… except to tell you to try and do it yourself.

openssh-portable already exists.

debian developers tried to be extra clever and it blew up in everyone's collective face.

>Can you confidently claim that upstream developers are better at security than debian developers?

With respect to the upstream application? Yes, obviously.

That's a valid take, and a good reason for your library (and other software using it) never being included in major distros. You're not obligated to make your code work with specific distros.

It's a good reason for others to avoid your libraries, though, especially if they do intend to be compatible with common distros.

The openssl issue was just the result of openssl being unnecessarily complex and difficult to work with, though.

> This reminds me of the time Debian developers "knew better" with the openssh key handling...

This is a totally unfair comparison. The upstream OpenSSL code was broken: it was invoking undefined behaviour. Moreover, the Debian maintainer had asked upstream whether it was OK to remove the code, because it was causing Valgrind memory warnings.

> The upstream OpenSSL code was broken: it was invoking undefined behaviour.

No it wasn't. It was reading indeterminate character values, which has defined behaviour (char cannot have a trap representation).

> the Debian maintainer had asked upstream whether it was OK to remove the code

They hadn't asked the correct mailing list, and they only asked at all for one of the two cases where they removed similar code, which wasn't the one taht caused the problem.

Reading an indeterminate value is its own undefined behaviour. See the second bottom paragraph on page 492: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

That's a change in C11. It was not undefined behaviour in C99 (which was the live standard at the time).

I linked N1256, which is essentially C99 plus the errata (Tchnical Corrigendum 1, 2, & 3).

The standard did not state that at the time. Consider Defect Report #451 (as discussed in 2013 and 2014), and observe that the committee did not simply respond that the example therein is undefined behaviour.

> but given the relative "freshness" of your typical Rust package vs say... Debian stable

That's not how Debian development is done, fresh software is uploaded to unstable only and then eventually ends up in a stable release. As a maintainer, Debian stable is something you support, not something you develop against.

> If you compile my Rust library against dependencies that are not compatible as declared in Cargo.toml, the result is on you.

The annoying thing is that that was always supposed to be true. Users of distro packages are already supposed to report all bugs to the package maintainers, and then they deal with it. Sometimes part of dealing with it is finding that a bug did in fact originate upstream and reporting it, but that was never supposed to be step 1.

The thing is user's want a solution: if a user is reporting a bug then already two things are true: (1) they're experiencing it and it's blocking them from using the software and (2) it's significant enough to their process they didn't just install something else.

So "user reporting a bug" is already an unusually highly motivated individual compared to the alternatives. Which leads to (3) they were trying to use the software right then, and a response from package maintainers of "this is an upstream bug" doesn't solve the problem, and in fact barely implies that a solution might be being requested from upstream.

Which also leads to (4): the most common immediate resolution anyone is going to present that user is "use the latest version / master / whatever". Which means the user is already going to make the transition to "now I'm a direct upstream user" (and equally the high probability the bug might still exist in upstream anyway).

> If you want to regenerate a compatible Cargo.lock

I only read the comments here so far and not the article but it sounds to me that people are up-in-arms about the "how do we handles" related to:

* primarily C/GNU makefile ecosystem

then

you now want to add Rust to it

and

Cargo.lock on cares about Cargo.toml versions, not what other crates `build.rs` are linking against provided by the system external to Rust?

Reply on news.ycombinator.com