[pm215]

I think that trust would be somewhat misplaced -- QEMU has historically not made particularly timely security fixes either on mainline or on branches. To the extent that our stable-branch situation is better today than it was some years ago, that is entirely because the person who does the downstream Debian packaging stepped up to do a lot more backporting work and stable-branch maintenance and releases. (I'm very grateful for that effort -- I think it's good for the project to have those stable branch releases but I certainly don't have time myself to do that work.)

As an upstream project, we really don't want to be in the business of making, providing and supporting binary releases. We just don't have the volunteer effort available and willing to do that work. It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams.

[vlovich123]

These two statements to me seem contradictory:

> QEMU has historically not made particularly timely security fixes either on mainline or on branches

> It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams

Am I correct that this is essentially saying "we're going to do a snapshot of the software periodically but end users are responsible for applying patches that are maintained by other users as part of building"? Where do these security patches come from and how do non-Debian distros pick them up? Are Arch maintainers in constant contact with Debian maintainers for security issues to know to apply those patches & rebuild?

[pm215]

Security patches are usually developed by upstream devs and get applied to mainline fairly promptly[1], but you don't want to run head-of-git in production. If you run a distro QEMU then the distro maintainers backport security fixes to whatever QEMU they're currently shipping and produce new packages. None of this is particularly QEMU specific. There's a whole infrastructure of security mailing lists and disclosure policies for people to tell distros about security bugs and patches, so if you're a distro you're going to be in contact with that and can get a headsup before public disclosure.

[1] and also to stable branches, but not day-of-cve-announcement level of urgency.

[vlovich123]

Sure, but then why does the mainline branch need to worry about supporting the rust that’s bundled with the last stable Debian release? By definition that’s not going into a distro (or the distro is building mainline with rusts latest release anyway).

Is it a precautionary concern that backporting patches gets more complicated if the vuln is in Rust code?

But then again Rust code isn’t even compiled by default so I guess I’m not sure why you’re bothering to support for old versions of the toolchain in mainline, at least this early in the development process. Certainly not a two year old toolchain.

[bonzini]

We already make an exception in that we don't support Debian bullseye (which is supported by the rest of QEMU until the April 2025 release), but not supporting Debian stable at all seemed too much.

That said we will probably switch to Debian rustc-web soon, and bump the lower limit to 1.75 or so.

[vlovich123]

I think I'm missing why you need to require using the toolchain bundled with the last stable Debian release vs having devs just rustup the latest version of the toolchain (or via a PPA [1] or however else they want to install it).

The current approach basically guarantees that you're always targeting a ~2-4 year old version of the toolchain and that feels like a particularly weird maintenance burden given how many workarounds you're putting in to do so.

[1] https://launchpad.net/~jonathonf/+archive/ubuntu/rustlang

[bonzini]

Because it's not about devs, it's about distro packagers. They are an extremely important audience for QEMU. As pm215 said above, we don't want to make their lives unnecessarily harder. For example Debian has the backports repository, and CentOS Stream has QEMU and Rust updates done by different teams.

Anyhow starting April (August release) we will be able to target 1.75.0 while being consistent with QEMU's (C-targeted) distro support policies, which is not that bad. Maybe newer than that depending on what Ubuntu 22.04 does between now and August.