Skip to content

staging-next-25.05 iteration 1 - 2025-06-20#418358

Merged
vcunat merged 261 commits intorelease-25.05from
staging-next-25.05
Jul 1, 2025
Merged

staging-next-25.05 iteration 1 - 2025-06-20#418358
vcunat merged 261 commits intorelease-25.05from
staging-next-25.05

Conversation

@vcunat
Copy link
Copy Markdown
Member

@vcunat vcunat commented Jun 20, 2025

nixpkgs-ci bot and others added 30 commits May 16, 2025 08:47
This reverts commit 75d2d3c, after
multiple complains best summarized here:

#402318 (comment)
(cherry picked from commit 7377f9e)
(cherry picked from commit 9407b1d)
(cherry picked from commit 915a9a6)
(cherry picked from commit e76c689)
https://github.com/libsdl-org/SDL/releases/tag/release-3.2.14

Signed-off-by: misilelab <misileminecord@gmail.com>
(cherry picked from commit ea1ea5e)
To quote `getenv(3)`:

> The  GNU-specific  secure_getenv()  function  is just like
> getenv() except that it returns NULL in cases where "secure
> execution" is required.

One of these cases is running in setuid mode. In this case, one could
make `sudo` load an arbitrary file as locale archive by modifying the
LOCALE_ARCHIVE env variable accordingly.

After consultation with the security team we came to the conclusion that
this is not exploitable by itself since it'd need another issue that
can be triggered by a maliciously crafted locale archive. Since this is
a valid issue nonetheless[1], I decided to fix it, but go through the
normal PR & staging lifecycle.

This patch also adds another fallback to
`/run/current-system/sw/lib/locale/locale-archive`: otherwise `sudo`
would fail to load any locale archive since that would be in
LOCALE_ARCHIVE/LOCALE_ARCHIVE_2_27 and thus setuid programs would
regress on translated output.

Thank you to Elliot Cameron for reporting this.

[1] glibc's internal environment filtering also prevents setuid
    processes to use certain locale settings from the environment
    such as LOCPATH.

(cherry picked from commit 2f4c749)
(cherry picked from commit d721173)
@vcunat vcunat dismissed github-actions[bot]’s stale review June 22, 2025 09:14

It's non-sensical CI in this case, complaining about clean merges, etc.

github-actions[bot]

This comment was marked as resolved.

@vcunat
Copy link
Copy Markdown
Member Author

vcunat commented Jun 30, 2025

Qt tries to detect the running Xcode version through `xcrun xcodebuild
-version`.
This fails when xcbuild is not included in the dependencies, and is also
unnecessary as the value is only used for the Xcode min version check
that we explicitly disable already.

(cherry picked from commit e34775b)
https://hydra.nixos.org/build/300813628/nixlog/1/tail
@vcunat vcunat merged commit 39c739f into release-25.05 Jul 1, 2025
30 checks passed
@h0nIg
Copy link
Copy Markdown
Contributor

h0nIg commented Jul 15, 2025

@vcunat will we see another round of staging-next-25.05 soon?

@vcunat
Copy link
Copy Markdown
Member Author

vcunat commented Jul 15, 2025

In about 10 days. In chat the consensus was to do another staging-next first which started today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

1.severity: security Issues which raise a security issue, or PRs that fix one 4.workflow: staging A staging-next or staging-next-XX.YY branch 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-darwin-stdenv This PR causes stdenv to rebuild on Darwin and must target a staging branch. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. 10.rebuild-linux-stdenv This PR causes stdenv to rebuild on Linux and must target a staging branch.

Projects

None yet

Development

Successfully merging this pull request may close these issues.