Orphaning bcachefs-tools in Debian • Hacker News Board

Re: Orphaning bcachefs-tools in Debian

#221

Post by hamandcheese » Sun, Sep 01, 2024, 8:16 PM UTC

tsimionescu wrote: post #153

hamandcheese wrote: post #71

Earlier quoted context omitted.

If the only way a security team can cope is with a single version policy, that sounds to me like a tooling problem. Take Nixpkgs, for example. They have this concept called "default crate overrides" which their rust builder uses, which offers the capability to patch all versions of a crate. That's not to say that Nixpkgs does rust perfectly, but just an example of the sort of tooling a security team should have at th…

How does it patch all versions automatically? If the library has been refactored, you still need to modify the patch for the pre-refactor and the post-refractor versions, for example. The closest you might get is a ChatGPT-based tool, but that is nowhere near safe enough for security patches.

I didn't say it's automatic. You can have overrides that target a more narrow range of versions, if you need. If there has been a major refactor, then you need two patches. But it's not rocket science, and you definitely don't need chatgpt.

You can also blend both strategies - you might have a version minimization strategy, where you only use, for example, one major version of a library at a time.

Re: Orphaning bcachefs-tools in Debian

#222

Post by kijin » Mon, Sep 02, 2024, 1:54 AM UTC

zamadatix wrote: post #217

kijin wrote: post #209

Earlier quoted context omitted.

Yes, and they chose to stop packaging it, again on their own accord. Except this time, they seem to have made the decision because upstream was bothering them too much.

No arguments there, I'm more talking what that means for the "build and distribute your own dev/rpm" part that follows. Why are the only options "do work for maintainers" or "provide a prebuilt package for the distro", what happened to "nobody said this needed to be done yet"?

No problem, if upstream doesn't want their software packaged for Distro X, nobody needs to do anything.

The thing about Linux filesystems, though, is that they consist of two parts: the kernel patch and the userspace tooling. Bcachefs is already in the kernel, so it's a bit awkward to leave out bcachefs-tools. Which is probably why it got packaged in the first place. Stable distros generally don't want loose ends flailing about in such a critical part of their system. If nobody wants to maintain bcachefs-tools for Debian, Debian will probably remove bcachefs entirely from their kernel as well.

Re: Orphaning bcachefs-tools in Debian

#223

Post by rlpb » Mon, Sep 02, 2024, 2:17 PM UTC

aseipp wrote: post #218

rlpb wrote: post #181

Earlier quoted context omitted.

Tooling to apply the patches is trivial. This isn't the problem I'm describing. As the sibling comment says, the issue is when the patch doesn't apply cleanly to some subset of versions in use, or even worse if they appear to apply cleanly but leave behind logic bugs. If distributions did approach this by "distro-patching" specific versions, then that would reintroduce the upstream complaint that distros are using ve…

Yeah, I don't think either of these are really big problems. People identify the vuln, the fix, and they tend to share the patches for backports across versions + across distros, and/or immediately update downstream users to fixed versions because, again, the nifty lockfiles literally tell you if they are vulnerable as they contain the dep graph. You query every package's dep graph and look at the bounds. Maintainers…

> in an effort to make a 35-year-old cultural rule about C/C++'s compilation model apply to them

> this is squarely a Debian dysfunction as far as I can see

Nothing I have said is specific to Debian or to C/C++. I've presented general arguments that hold regardless of distribution policies or the language toolchain used. Nothing you have said demonstrates why the general points I have made would apply to Debian or to C/C++ but not to Rust-based projects.

If you still believe that this is the case, then I think that demonstrates that you do not understand the matter deeply enough.

The only thing that Debian is insisting on is basic software supply chain hygiene. Every so often, there is a very public failure in ecosystems that don't bother with this hygiene, while Debian continues unaffected.

> You can apply patches to most versions of a crate

The point of the complaint that spawned this discussion is that there's an upstream that considers it unacceptable for downstreams to be doing this patching (or indeed running any dependency version that is not sanctioned by upstream). It is a contradictory position to justify downstream patches as a supposedly easy solution while at the same time complaining that downstreams patch at all.

The fact is that distributions users do not expect to be beholden to laggard upstreams while awaiting security fixes. This requires distributions to modify the dependency versions (or patch, which is the equivalent "off-piste" behaviour) used to build their packages.

Re: Orphaning bcachefs-tools in Debian

#224

Post by [deleted] » Sat, Sep 14, 2024, 2:19 PM UTC

complaintdept wrote: post #146

ants_everywhere wrote: post #89

Earlier quoted context omitted.

Hey at least it's not the worst behavior we've seen from a Linux file system creator... I thought Carl Thompson's response was very good and constructive: https://lore.kernel.org/lkml/1816164937.417.1724473375169@ma... What I don't understand is that IIUC Kent has his development git history well broken up into small tight commits. But he seems to be sending the Linux maintainers patches that are much larger than the…

> Hey at least it's not the worst behavior we've seen from a Linux file system creator... I think that dubious distinction would go to Hans Reiser.

[deleted]