qemu: 9.0.2 -> 9.1.0 #338598
Merged
qemu: 9.0.2 -> 9.1.0 #338598
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ofborg
bot
added
11.by: package-maintainer
alyssais
added
the
1.severity: security
|
On macos 12 x86_64: |
|
Will look at patching CVE-2024-7409 for 24.05 unless you're ahead of me |
|
It looked complicated, like it was fixed over a number of commits. I assume it'll be in the next stable release anyway? |
@reckenrode suggested I try overriding the SDK, so I've pushed that now (not tested). |
|
I'm not sure it's that complicated beyond being split across two commits, but yes I'd hope it would be in a 9.0.3, though don't know when to expect that. |
|
I'm recalling all the sdk-overriding |
|
I recall some issues too. I’ll check on my SDK refactor branch once I have a working stdenv again. Once the Darwin refactor lands, you’ll be able to add See https://discourse.nixos.org/t/on-the-future-of-darwin-sdks-or-how-you-can-stop-worrying-and-put-the-sdk-in-build-inputs/50574 for more information on the Darwin refactor. |
|
It works for me. |
emilazy
force-pushed
the
qemu-9.1.0
branch
2 times, most recently
from
3343fa7 to
cfac202
Compare
|
I fixed it. Upstream only support alive macOS releases and aggressively remove conditionals, so I’ve bumped to their (effective) requirements rather than vendoring a bunch more patches to revert their changes and potentially remove features. |
emilazy
added a commit
to emilazy/nixpkgs
that referenced
this pull request
Aug 31, 2024
For a long time now, the SDK and minimum target version for `x86_64-darwin` has been stuck on macOS 10.12. In the past, the minimum SDK was updated quite regularly; at first, the current situation was just because updating the SDKs was excessively burdensome and nobody was up for doing the work, but the introduction of `aarch64-darwin` with its macOS 11 default SDK has resulted in a long‐term fracture of the two platforms. Per <https://endoflife.date/macos>, macOS 10.12 has not received an update since 2017 and went out of security support 5 years ago. Trying to support it in Nixpkgs has been a large burden on the Darwin maintainers, resulting in workarounds, porting work, and even patching functionality out of applications. The existence of Nix users using a macOS version this old is, to my knowledge, entirely theoretical, and we pay in both maintenance costs and functionality: for instance, applications built for `x86_64-darwin` do not support automatic dark mode switching by default. This situation has always been suboptimal, but it is now becoming untenable. Python, a critical component of the Nixpkgs standard environment for builds, is dropping support for versions older than 10.13 in 3.13: <https://www.python.org/downloads/release/python-3130rc1/>. Qt 6 only supports macOS 11 and newer. libuv only supports the versions Apple does, and is a ticking time bomb due to its use in the standard environment. QEMU only supports the last two macOS releases, and won’t build with an SDK older than macOS 12; we previously vendored a set of backporting changes and functionality‐removing reverts to keep it building for 10.12, but this also became overly onerous, and we gave up in <NixOS#338598>. `x86_64-darwin` is a platform with a limited upstream future. Apple no longer sells any hardware that runs it natively, and it is unclear how much longer they will support it in the operating system. There are still many users of the platform, myself included, so we shouldn’t drop support for it prematurely, but it’s unreasonable to try and patch the entire world to keep it supporting insecure versions of the OS that only run on hardware that is no longer sold. Therefore, this adds a release note to warn users ahead of time that 25.05 will only support macOS 11 and newer, as suggested by the 24.05 release team when the possibility of bumping the required version was raised. Why target Big Sur, rather than any other version? The reason is simple: it’s the same SDK and deployment target as `aarch64-darwin`. There are many packages that work on `aarch64-darwin` but not `x86_64-darwin`, and Darwin maintainers frequently need to be called in to fix things that work fine on the newer platform but not the older one. This change will increase the health of `x86_64-darwin` by aligning the SDK versions and support between the two platforms; the vast majority of packages that work on one will Just Work on the other. macOS 11 is almost four years old and has itself been out of security support for a year now, but as the first version to support Apple Silicon, it’s a far more compatible base for us to build our Darwin packages for. Any future change in supported versions should be synchronized between the two Darwin architectures. When 25.05 is released, users on old, unsupported versions of macOS will have the following options: * Update to a new macOS version. For users that are on hardware that Apple has dropped support for, OpenCore Legacy Patcher (<https://dortania.github.io/OpenCore-Legacy-Patcher/>) can enable the use of newer macOS versions on hardware even older than 10.12 supports. * Install NixOS. That obviously precludes the use of macOS software (though most of that software has already dropped support for 10.12), but will give users a secure, supported operating system that we can actually own the support for going forward. * Keep using 24.11 forever. Since they’re not getting updates to their OS and core applications anyway, this is likely to be acceptable to many users. * Switch to MacPorts. They support all the way back to 10.6 for `x86_64-darwin` by building packages separately for every OS release, though not every package is available for every version. * Send patches. We *may* accept non‐invasive patches to keep certain critical packages (such as the core `stdenv` packages) building for old OS versions, on a case‐by‐case basis, but we can’t guarantee it. This will ultimately have to be a decision made by package maintainers and personally I doubt this will be a viable path to sustainably support older versions.
13 tasks
|
I think this is a lovely move! |
|
(on nixos x86_64, |
|
|
The macOS deployment target has been set to 12.0, and the collection of patches and reverts to keep older macOS versions working has been dropped, as maintaining what is effectively a fork of QEMU solely for the sake of versions no longer supported by Apple has become untenable. It may or may not still work on older macOS versions, potentially with reduced functionality. Upstream only officially supports the latest two versions of macOS, so this is still extending support further back than QEMU will support. To continue supporting back to macOS 10.12, at least the following upstream commits would have to be reverted, and possibly more: * <https://gitlab.com/qemu-project/qemu/-/commit/2d27c91e2b72ac7a65504ac207c89262d92464eb> * <https://gitlab.com/qemu-project/qemu/-/commit/e9c9d8dc3ba993384bc9553b617120ad4717345c> * <https://gitlab.com/qemu-project/qemu/-/commit/7b60b971cc2f52ed2a69006a2ad709df2831cd67> However, if you want to do that, you should be prepared to take up the burden of maintaining the monotonically‐increasing set of patches that will be required to keep this working in future. Fixes: CVE-2024-7409 Co-authored-by: Emily <vcs@emily.moe>
|
@ofborg test cage cagebreak cloud-init-hostname cloud-init mtp os-prober phosh sway systemd-initrd-luks-fido2 tinywl virtualbox |
|
Hey, |
|
I've seen the same issue |
|
My understanding is that should have been fixed by #340131. |
|
@alyssais oh, I was on |
|
Ah yes, builds on master for me. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
Fixes: CVE-2024-7409
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.