Re: Rust policy for bcachefs-tools in Debian
On Fri, Sep 19, 2025, at 5:17 PM, Kent Overstreet wrote:
> 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.
Sure. You might have noticed that both major browsers are included in the
list of existing exceptions. Both have stable branches with upstream
security support which the packages for Debian stable are based upon.
The existence of those branches is pretty much a requirement for those
browser being in stable in the first place.
For a non-security example - both the kernel and systemd also provide
stable release branches upstream that are (from time to time!) imported
into Debian stable point releases.
> 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.
I just wanted to note - I am not involved in any capacity in the mentioned
teams, it's really them that you need to have this discussion with :)
> 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.
Yes. See above for kernel/systemd as examples of projects in a similar boat
(maybe less so w.r.t. hotfixes, but rather fixes for bugs affecting that
stable release train - but do note that upstream and distros, in particular
distros like Debian, often disagree about the urgency of fixing such issues,
something you upstream might consider a hotfix you want to release tomorrow
might very well be something that Debian considers to be okay to fix in the
next point release, which might be up to 2 months away).
> 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?
Both, I'd say. It's a want (because it has desirable properties, in
particular when using dynamic linking, archive-wide changes, ..) and a need
(because a lot of the infrastructure and work flows are not setup to handle
code copies well).
> 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.
Yes. Debian is also known for being the one major distro that actually cares
about licensing and copyright and similar idiosyncrasies (mostly joking ;)).
>> >> 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.
Will try to read (and take a look at that repo) and chime in once you do.
Reply to: