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

Orphaning bcachefs-tools in Debian

jonathancarter.org

Post reply on HN
Print view View original

31–40 of 224 posts

Re: Orphaning bcachefs-tools in Debian

#31

Post by mananaysiempre »

1oooqooq wrote: post #15
mananaysiempre wrote: post #7

See also on the same general topic: “The modern packager’s security nightmare” (2021) [1] by Gentoo maintainer Michał Górny, and Drew DeVault’s posts on why FOSS developers should not distribute software directly or try to impose their will on distros[2,3]. [1] https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag... , discussed at https://news.ycombinator.com/item?id=26203853 (320 points, 278 comments) [2] ht…

exactly. the sad part is that this is being coopted into an aegument for flatpack! it's insane the discussions on some distros. they cannot see that by giving in to static libs you make every little application maintainer into a full-time distro maintainer responsible for it forever. ... good luck with that.

I actually don’t entirely agree with Górny’s argument that we should use the technical tool of shared libraries to solve the social problem of not organizing the package archive in a way that allows an automatic bump of every dependency on a static library change. But I do agree with a weakened version where “static libraries” is replaced with “vendored code”, and that’s the (part of) problem TFA describes.

(The rest of the problem is that the goals of Debian are incompatible with upstream refusing to support versions of their own code more than a couple of months old. Which they transparently are, so there isn’t much to argue about here.)

Re: Orphaning bcachefs-tools in Debian

#32

Post by rlpb »

cogman10 wrote: post #18
viraptor wrote: post #5

Earlier quoted context omitted.

This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level. It's an issue in Debian because they can't handle multiple concurrent versions (beyond renaming the package) and want every package built without internet access. But that same issue affects Ruby, Python, etc. if the project specifies strict versions. And if you deal with filesystems, you really wan…

It should be noted that, particularly for rust, it's a silly policy as rust does not support dynamic linking of rust libraries. All rust applications are statically linked. So trying to force all projects using foo onto the same version of foo is just a huge headache with no real benefit to anything.

> So trying to force all projects using foo onto the same version of foo is just a huge headache with no real benefit to anything.

It creates a security nightmare.

Distributions expect to be able to security patch without waiting for laggard upstreams to bump their pinned dependency versions. If the ecosystem insists that only upstream-sanctioned versions are acceptable, then that runs contrary to this expectation, because it blocks distributions from patching or bumping dependency versions. If this case should be an exception, then you end up with a security team having to patch myriad different versions. That's the security nightmare.

Re: Orphaning bcachefs-tools in Debian

#33

Post by viraptor »

1oooqooq wrote: post #11
viraptor wrote: post #5

Earlier quoted context omitted.

This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level. It's an issue in Debian because they can't handle multiple concurrent versions (beyond renaming the package) and want every package built without internet access. But that same issue affects Ruby, Python, etc. if the project specifies strict versions. And if you deal with filesystems, you really wan…

it is rust specific because rust is the first attemp to replace proper system engineering languages with one that while nicer on memory management and overall ergonomics, is worse in tooking. cargo brings many malpractices from java/JavaScript (maven, npm, etc) that were always shunned in systems engineering and, mark my words, will be a security nightmare for linux in the near future.

Go, D, Ocaml, Nim have the same issue, most are older than Rust and are arguably systems languages.

C/C++ built with Bazel or Conan will have the same issue too.

Re: Orphaning bcachefs-tools in Debian

#34

Post by aragilar »

JonChesterfield wrote: post #13
JackSlateur wrote: post #8

Earlier quoted context omitted.

if you deal with filesystems, you really want strict versions How are doing everybody else ? What is specific with filesystems, here ? This is a bad dependency management, nothing more. Vendoring is a PITA.

Filesystems are complicated and have nasty failure modes. Strict versioning reduces the impact of software development QoI properties, i.e. that basically all code is substantially wrong.

I would expect it to be the opposite (especially for a linux file system): you want to test with as wide a variety of versions as possible, because that what you're going to encounter in the real world. If your code only works in a limited set of cases, what happens when you mount the file system on a different system, is the file system going to be trashed?

Re: Orphaning bcachefs-tools in Debian

#35

Post by CJefferson »

frankjr wrote: post #28

The list of dependencies doesn't really seem crazy. Logging, parsing command line arguments, band-aiding error traits, working with uuids, reading binary data, "memset_s". All of those should be a part of the standard library as in any other programming language. The fact that you simply cannot build anything but trivial examples without taking a dependency on a third party library is just plain ridiculous and hinder…

Where are those things in the standard library of C or C++, which most software is written in?

Most C Debian packages have a few dependencies in my experience, they are just “standard”, because they are old and stable.

Re: Orphaning bcachefs-tools in Debian

#36

Post by viraptor »

JackSlateur wrote: post #29
viraptor wrote: post #12

Earlier quoted context omitted.

Level of potentially messing up. If you have a chat app, relax the deps and it crashes - oh well. But if you have a tool which can cause data loss, you really want to be sure everyone's running what you tested. It's similar to why restic (backup software) has official, static, reproducible binaries in their releases.

And if my kernel crashes ? And if whatever library bugged, oh well, random people can access my systems ? And if my bgpd bugged, oh well, we just inject random routes et forward data randomly ? Makes no sense.

Your kernel has no external library dependencies.

Relaxing library requirements can introduce security issues when the dependency behaviour changes, so I'm not sure what the argument is.

If your bgp is bugged, yeah it sucks, but it's recoverable. We're using encrypted traffic these days to ensure that even captured traffic is safe.

The difference here is that data corruption is not recoverable.

Re: Orphaning bcachefs-tools in Debian

#37

Post by ectospheno »

haileys wrote: post #10
JonChesterfield wrote: post #3

This would be a good one for Rust enthusiasts to weigh in on. The issue raised is that some program written in rust insists on a very specific version of various dependencies. If other people change the metadata, it builds and seems to run ok with different versions. (Developer on reddit clarifies that it builds and does the wrong thing, and recommends dropping Debian as a solution). Linux likes to pack a finite set…

I think this is the same shape of issue that I’ve experienced with Debian for as long as I’ve used it - close to 15 years now. Debian is a great OS, but it targets stability and long term support for its releases. That just isn’t compatible with newer, faster moving software that’s still working towards stability. I remember it being an issue when I was playing around with Mono around 2010 ish, and it’s an issue now…

I love Debian for this stability. It is a great host OS for all my VMs.

Re: Orphaning bcachefs-tools in Debian

#38

Post by viraptor »

frankjr wrote: post #28

The list of dependencies doesn't really seem crazy. Logging, parsing command line arguments, band-aiding error traits, working with uuids, reading binary data, "memset_s". All of those should be a part of the standard library as in any other programming language. The fact that you simply cannot build anything but trivial examples without taking a dependency on a third party library is just plain ridiculous and hinder…

> positions itself to be used in mission critical systems and yet essentially requires you to implicitly trust hundreds of maintainers

It doesn't require anything. You can write those things yourself if you want. And for some critical things you should.

But given the tiny number of languages with logging, uuids, and error reporting built in... what are you taking about? They're doing just fine.

Re: Orphaning bcachefs-tools in Debian

#40

Post by cogman10 »

rlpb wrote: post #32
cogman10 wrote: post #18

Earlier quoted context omitted.

It should be noted that, particularly for rust, it's a silly policy as rust does not support dynamic linking of rust libraries. All rust applications are statically linked. So trying to force all projects using foo onto the same version of foo is just a huge headache with no real benefit to anything.

> So trying to force all projects using foo onto the same version of foo is just a huge headache with no real benefit to anything. It creates a security nightmare. Distributions expect to be able to security patch without waiting for laggard upstreams to bump their pinned dependency versions. If the ecosystem insists that only upstream-sanctioned versions are acceptable, then that runs contrary to this expectation, b…

Fair point.

I do think we need to reevaluate how security is managed in terms of software. It's often the case that we say "this library version has a CVE, we need to update it!" However, it's not often the case that the CVE in the library is even exploitable from the parent application.

I'm thinking of a recent 9 CVE against zlib... But actually it was a rarely used extension API for working with compressed files.

Something like path tracing to see if a vulnerable API is even accessible from the parent application/library before instructing the universe to adopt a new version.

Post reply on HN