Re: Rust policy for bcachefs-tools in Debian
On Fri, Sep 19, 2025 at 04:40:44PM +0200, Fabian Grünbichler wrote:
> On Sun, Sep 14, 2025, at 8:08 PM, Kent Overstreet wrote:
> > On Sun, Sep 14, 2025 at 07:33:56PM +0200, Matthias Geiger wrote:
> >> - Security issues: If they occur the can be easily migitated by a rebuild
> >> archive-wide for the packaged crates (not when vendored)
> >
> > For security issues, I think this is a solved problem; there are bots
> > that watch repositories and notify if there are out of date dependecies
> > (and I've got these notificiations once or twice in the past).
>
> Yeah, that's not how security updates are done in Debian (except sometimes
> in unstable ;)). For stable, you absolutely need a minimal fix targeting
> just the issue at hand, unless you have a proven track record and agreement
> with the security team which allows you to import collected security fix
> *releases* done upstream, or something like that. Wholesale updating of
> dependencies is only done as a last resort (see below).
You guys may have to constrain yourself to the realm of the possible :)
I've been scanning through past threads and noticing a lot of
commonality and similar stories in the problems that came up when
packaging web browsers, which is not too surprising; filesystems and web
browsers are both massive projects. Filesystems may not be able to
compete on raw amount of code (~150k loc for bcachefs), but the
reliability and correctness requirements are as high as it gets in
filesystem land (with commensuratily high QA requirements), which makes
us particularly sensitive to a lot of these issues; and we have to be
picky about where we spend our limited engineering cycles.
IOW - I don't think that backporting the "Debian" way is likely to be
very practical or a good fit for bcachefs, if the goal is to get users
the most reliable and best supported code we can.
I do think we'll be able to come up with something workable that will
make you guys happy if we can all try to be pragmatic and a bit
flexible, though.
One useful thing to note, both for the "how will backports work"
discussion and the "rust dependency" discussion is that, AFAIK, there's
only been one genuine security bug in the entire ~2 years since bcachefs
was merged upstream. Our actual attack surface is slightly smaller than
a web browser :)
Our main concern for backports is just normal bugs for
stability/robustness (i.e. repair) - but for those we are still
extremely concerned with being able to reliably get hotfixes out
quickly.
Unfortunately, filesystems and kernel programming being what there are,
the nastiest bugs we have to deal with are often things like "something
subtly changed in an entirely different subsystem, or a performance
improvement exposed a race" - meaning it's not a simple regression that
we can revert, we need to deploy a real fix and possibly new repair code
too. This isn't unique to bcachefs if you keep track of nasty bugs other
filesystems have had to deal with.
> It is, because we don't want to have 25 slightly different copies of the same
> code in the archive. We want to ideally have a single copy (per release), so
> that we only have to analyze and fix that one (and potentially rebuild things
> statically linking it).
Is this a want or a need, though?
I think it'd be helpful to keep the discussion grounded in our
underlying reasoning (workflows, etc.).
"Who's going to be responsible for responding to bugs (including
security bugs)" is a big one :)
> This is a fundamental clash between how distros like Debian, and some upstream
> ecosystems (like Rust/crates.io, but also npm, ..) operate.
Well, I've been involved with packaging bcachefs-tools for every major
distro and Debian's the only one where this has been a roadblock. Even
Fedora gave us an exception on unbundling.
> >> That being said, you can vendor all crates under debian/missing-sources and
> >> then build from there (see librsvg). ftp-masters *should* accept it even if
> >> it's vendored as long as you detail everything in d/copyright.
> >> Security-wise you are responsiblee though, and the release team might not be
> >> happy about this. Hope this helps.
> >
> > Ok, that sounds like some useful background - on IRC just now there was
> > question about how much scrutiny this would get from the ftpmasters.
> >
> > I hope this doesn't open up too big of a can of worms for you guys, from
> > what I've gathered there've been some past debates and I don't want to
> > reopen too much. But this is also a case of "once-burned, twice-shy" for
> > me, so... tricky stuff :)
>
> I'd advise giving them a heads-up before you spend significant time on such
> packaging efforts, unless you want to build and publish such a package on your
> own anyway in case it gets rejected. Basically outline your reasoning (I'd
> keep it a bit shorter than in this thread though) and give some numbers about
> the scale of vendoring (e.g., number of crates/LOC/files/bytes). Please be
> patient, it might take a while for them to get back (e.g., if they want to
> have an internal discussion and decide based on that).
Noted, thanks.
We needed to get something up fast to support existing users, so we've
got that external repository now - and this should give us something
more concrete to talk about and review:
https://apt.bcachefs.org/
I'll try to get something out to debian-devel next week.
Reply to: