Updating setuptools to patch CVE-2025-47273

[aaronmaxlevy]

Updating setuptools to patch CVE-2025-47273

Also updated Bazel to 7.4.0 due to bazelbuild/bazel#4327

Fixes #22165

[aaronmaxlevy]

@mkruskal-google Can you allow tests to run again? I believe that my latest commit updating Bazel to 7.4.0 should fix this, at least partially. The reason why it wasn't working properly appears to have been bazelbuild/bazel#4327 , which was fixed in Bazel 7.4.0 .

[aaronmaxlevy]

@mkruskal-google Can you allow tests to run again? I believe that my latest commit updating Bazel to 7.4.0 should fix this, at least partially. The reason why it wasn't working properly appears to have been bazelbuild/bazel#4327 , which was fixed in Bazel 7.4.0 .

Actually — scratch that. The culprit seems to be a new bug that I seem to have found in Bazel bazelbuild/bazel#26255 :(

I'll move this PR to Draft status while that Bazel bug is outstanding

[aaronmaxlevy]

@mkruskal-google can you allow tests to run for this again? Per a suggestion from the Bazel team at bazelbuild/bazel#26255 (comment) I added an sh_binary wrapper and the build now succeeds locally for me.

[aaronmaxlevy]

@acozzette Thanks — looks like there are still some test failures here for a few reasons.

1. GitHub CI is running using Bazel 7.1.2 still, despite my having updated the .bazeliskrc to use Bazel 7.4.0 (which is required due to Runfiles: support paths with spaces bazelbuild/bazel#4327 ). I can reproduce the failures locally on 7.1.2 but moving to 7.4.0 does fix it for me locally.

I believe that this can be updated in the files within .github/workflows, however from what I can tell, PRs from external forks (such as mine) that update the GitHub workflow files are not allowed as per https://github.com/protocolbuffers/protobuf/blob/main/.github/workflows/forked_pr_workflow_check.yml . What would the preferred path forward be here? Should / could someone from Google file a separate PR to update to Bazel 7.4.0 (both .bazeliskrc and in the GitHub workflow files)?

2. The setup_wrapper.sh script that I added for the Python build doesn't seem to correctly find the setuptools path on Windows. I will work on a fix for this, as I only tested with macOS and Linux on my end :)

3. Unknown C++ / CMake build errors that don't seem related to anything I've changed (especially since the CI tests are still running with Bazel 7.2.1, which is the only non-Python change on my branch). I just updated my fork branch with the latest commits from upstream so I'm hoping these will pass next time and were caused by staleness of my fork.

[acozzette]

@aaronmaxlevy Thank you for all your work on this!

Unfortunately upgrading our Bazel version is a non-trivial process, because there are a handful of Docker images that need to be rebuilt in addition to updating .bazeliskrc and the .yml files. I will try to find time to do that later this afternoon or tomorrow, though.

Let me rerun the tests now to see if the CMake issue build error goes away.

[aaronmaxlevy]

No problem :) Happy to help. Looks like the CMake issue has resolved now, which is good.

[aaronmaxlevy]

@acozzette the Windows test should pass now if you re-run it. Turns out that the Pip package installation stuff doesn't actually work on Windows. The current build process ends up falling back to the system python's installed version of setuptools on Windows from what I can tell, which is what I changed the new wrapper script to also do.

See

protobuf/python/dist/system_python.bzl

Line 176 in 960e790

if "win" in ctx.os.name:

— if you look at recent successful Windows test / build output, you will see WARNING: could not install pip dependencies in the output, e.g. https://github.com/protocolbuffers/protobuf/actions/runs/16047228021/job/45281342761?pr=22509#step:4:566

[aaronmaxlevy]

@acozzette thank you so much for your help in getting this merged / rolled out!

[acozzette]

You're welcome and thank you for sending us the fix!

[aaronmaxlevy]

No problem!