build: Drop support for EOL macOS 13

maflcko commented at 5:31 am on September 29, 2025: member

Now that macOS 13 is EOL (https://en.wikipedia.org/wiki/MacOS_Ventura), it seems odd to still support it.

(macOS Ventura 13.7.8 received its final security update on 20 Aug 2025: https://support.apple.com/en-us/100100)

This patch will only be released in version 31.x, another 6 months out from now.

So:

Update the depends build and release note template to drop EOL macOS 13.
As a result, update the earliest Xcode to version 16 in CI.
Also, bump the macOS CI runner to version 15, to avoid issues when version 14 will be at its EOL in about 1 year.

This also allows to drop a small workaround in the fuzz tests and unlocks libcpp hardening (https://github.com/bitcoin/bitcoin/pull/33462)

DrahtBot added the label Tests on Sep 29, 2025

DrahtBot commented at 5:31 am on September 29, 2025: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33489.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	hodlinator, stickies-v, l0rinc, hebasto
Stale ACK	katesalazar

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#32380 (Modernize use of UTF-8 in Windows code by hebasto)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

LLM Linter (✨ experimental)

Possible typos and grammar issues:

const auto [it, ins]{FuzzTargets().try_emplace(name, std::move(target), std::move(opts))}; -> const auto [it, ins] = FuzzTargets().try_emplace(name, std::move(target), std::move(opts)); [structured bindings require ‘=’; the braced form is invalid C++]

drahtbot_id_5_m

maflcko force-pushed on Sep 29, 2025

in .github/workflows/ci.yml:108 in fab9ddaf55 outdated

104@@ -105,7 +105,7 @@ jobs:
105     name: ${{ matrix.job-name }}
106     # Use any image to support the xcode-select below, but hardcode version to avoid silent upgrades (and breaks).
107     # See: https://github.com/actions/runner-images#available-images.
108-    runs-on: macos-14
109+    runs-on: macos-15

hodlinator commented at 8:02 am on September 29, 2025:

Seems fine to push GH CI one version ahead of supported OS. Then again, it would be nice to have test coverage of minimum version as well?

maflcko commented at 8:43 am on September 29, 2025:

No strong opinion, but:

Such test coverage did not exist before either.
I am not aware of this ever finding an issue. The version that matters most is the xcode toolchain version, as documented in the lines above.

hodlinator commented at 12:28 pm on September 29, 2025:

I guess the amount of Mac-specific code we have that behaves differently between 14 and 15 is minimal.

If it hasn’t been a problem previously I’m okay with bumping it so we don’t need to re-touch in 1 year - Although if we are going to keep bumping the minimum supported version and CI version every year anyway… I would lean towards keeping them in sync. (GitHub deprecating and removing older versions would then also serve as an extra reminder if we are late to update).

maflcko commented at 1:02 pm on September 29, 2025:

If the version is too low here, backport branches would have to bump it as well at some point. But either way should be equally fine. Happy to push any version, but for now I’ll leave as-is to not invalidate the two acks.

maflcko commented at 1:29 pm on September 30, 2025:

Added minimum CI check (for the cross-build) in #33509 (draft), but not sure if this is worth it to review/merge/maintain. Feel free to leave a comment there.

hodlinator commented at 7:43 am on October 1, 2025:

nit: This change to ci.yml in this PR should probably be broken out to a separate commit or mentioned in the commit message as now it’s just “Drop support for EOL macOS 13”.

Cheers, will check out 33509.

maflcko commented at 7:13 am on October 2, 2025:

nit: This change to ci.yml in this PR should probably be broken out to a separate commit or mentioned in the commit message as now it’s just “Drop support for EOL macOS 13”.

Thx, I’ll adjust the commit message on the next push, if there is one. Leaving as-is for now.

in .github/workflows/ci.yml:126 in fab9ddaf55 outdated

122@@ -123,10 +123,10 @@ jobs:
123         include:
124           - job-type: standard
125             file-env: './ci/test/00_setup_env_mac_native.sh'
126-            job-name: 'macOS 14 native, arm64, no depends, sqlite only, gui'

hodlinator commented at 8:03 am on September 29, 2025:

nit: Noticed 15 still technically supports x86: https://en.wikipedia.org/wiki/MacOS_Sequoia - so could keep arm64.

maflcko commented at 8:43 am on September 29, 2025:

I think the meaningless bloat is just frustrating when glancing at and selecting CI results, because it makes it impossible to differentiate tasks on a glance:

Also, it is unclear what value it adds. Has the macOS version or the macOS architecture ever influenced the CI result? IIRC, what matters most is the toolchain version (xcode). If someone cares, they can trivially find the details in the CI config, or it can be added back later, if there is a reason.

Finally, none of the other tasks mention the OS version or native arch.

Aa777263100 commented at 3:58 pm on September 29, 2025:

fab9ddaf554837624fa8f388e046a30d5bf7626f

hodlinator commented at 8:05 am on September 29, 2025: contributor

Reviewed fab9ddaf554837624fa8f388e046a30d5bf7626f

katesalazar commented at 9:22 am on September 29, 2025: contributor

ACK fab9ddaf554837624fa8f388e046a30d5bf7626f

hodlinator approved

hodlinator commented at 12:31 pm on September 29, 2025: contributor

ACK fab9ddaf554837624fa8f388e046a30d5bf7626f

in .github/workflows/ci.yml:149 in fab9ddaf55 outdated

144@@ -145,8 +145,8 @@ jobs:
145           # Use the earliest Xcode supported by the version of macOS denoted in
146           # doc/release-notes-empty-template.md and providing at least the
147           # minimum clang version denoted in doc/dependencies.md.
148-          # See: https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes
149-          sudo xcode-select --switch /Applications/Xcode_15.0.app
150+          # See: https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes
151+          sudo xcode-select --switch /Applications/Xcode_16.0.app

stickies-v commented at 3:08 pm on September 29, 2025:

For my understanding: because Xcode 15 supports macOS 14 this change is unrelated to dropping macOS 13 support, and instead could/should have been part of #30263 since Xcode 15 doesn’t satisfy our minimum clang version anymore, right? If that’s correct, it looks like there’s lingering usage of Xcode 15 that can be bumped up, but orthogonal to this PR.

maflcko commented at 3:28 pm on September 29, 2025:

Heh, that’s a bit confusing, as the Apple versioning here is horrible. Xcode 15.0 ships with llvm 16.0 but the clang version string is 15.0 (https://en.wikipedia.org/wiki/Xcode#Toolchain_versions)

Xcode 16 ships with llvm 17.0 and clang 16.0.

However, I don’t know if the Apple clang version string corresponds to the vanilla Clang version scheme.

In any case, you may be right that the workaround may be possible to drop:

0src/test/fuzz/fuzz.cpp:78:    const auto [it, ins]{FuzzTargets().try_emplace(name, FuzzTarget /* temporary can be dropped after Apple-Clang-16 ? */ {std::move(target), std::move(opts)})};

I’ll attempt this in a follow-up to keep this ci/doc-only and not to invalidate the review.

stickies-v commented at 5:17 pm on September 29, 2025:

Oh, right, I was confused about the apple clang version indeed.

Since Xcode 15 satisfies our minimum macOS and clang versions, I’m not sure why we’re bumping it here? The above docstring states:

      # Use the earliest Xcode supported by the version of macOS denoted in
      # doc/release-notes-empty-template.md and providing at least the
      # minimum clang version denoted in doc/dependencies.md.

It seems like the documentation is at conflict with the Xcode version now?

maflcko commented at 5:52 am on September 30, 2025:

Ah, I guess I could have written the comment clearer. I meant Use the earliest Xcode requiring at least the version of macOS denoted in .... Otherwise, we’d unnecessarily limit our Xcode features to EOL versions of macOS.

Whether to pick the earliest minor version of Xcode or earliest major version of Xcode is not specified, but I think going with the earliest major version here seems fine, to be able to remove the fuzz.cpp workaround.

hebasto commented at 8:02 am on September 30, 2025:

So people on macOS 14.4 with Xcode 15.4 and Apple Clang 1500.3.9.4 based on LLVM 16.0 will fail to compile fuzz.cpp, right?

maflcko commented at 8:15 am on September 30, 2025:

Yes. My guess is that it should be easy and harmless to upgrade Xcode, but I haven’t verified this or tried it.

hebasto commented at 8:29 am on September 30, 2025:

Upgrading Xcode 15.4 on macOS 14.4 requires updating macOS itself, at least to 14.5.

Therefore, the effective minimum supported macOS version becomes 14.5, not 14.0.

maflcko commented at 8:46 am on September 30, 2025:

Upgrading Xcode 15.4 on macOS 14.4 requires updating macOS itself, at least to 14.5.

Correct. This should be no problem, because running on insecure minor releases is no different from running on EOL versions. See also the auto-upgrade: https://support.apple.com/guide/mac-help/software-update-settings-on-mac-mchla7037245/15.0/mac/15.0

Therefore, the effective minimum supported macOS version becomes 14.5, not 14.0.

Correct. However, I don’t think it is beneficial to micro-manage the insecure minor macOS versions in this repo. It should be implicit and common sense that only the latest supported security release of each major version is supported.

Also, this is unrelated to the changes here, because the current Xcode 15.0 requires a macOS 13.5, not 13.0. So this is a pre-existing thing.

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

File	commit 25212dfdb4cd7291392b6a94130f658c5bfa0a48(master)	commit b69d999325fa687606c9d3973c96ebd307f56b35(pull/33489/merge)
*-aarch64-linux-gnu-debug.tar.gz	`2c56d77595dccdf3...`	`bdddbd7e622ca838...`
*-aarch64-linux-gnu.tar.gz	`9f0916a36cb9c82b...`	`ac62ee0f433f65f8...`
*-arm-linux-gnueabihf-debug.tar.gz	`d288a590cc72104a...`	`e9d7f23c6f8e85b2...`
*-arm-linux-gnueabihf.tar.gz	`cfebbd7cc439171a...`	`9f6fefd6ffff24bc...`
*-arm64-apple-darwin-codesigning.tar.gz	`f3dfb6b92522f348...`
*-arm64-apple-darwin-unsigned.tar.gz	`d8c439aba5230f0e...`
*-arm64-apple-darwin-unsigned.zip	`81a1f905cd3e8389...`
*-powerpc64-linux-gnu-debug.tar.gz	`57f006139be92591...`	`c3938c9af83200a8...`
*-powerpc64-linux-gnu.tar.gz	`3350960e5a37dfce...`	`e3d470c638dca037...`
*-riscv64-linux-gnu-debug.tar.gz	`aad4594dbaacb444...`	`da13c7aa38148521...`
*-riscv64-linux-gnu.tar.gz	`50a9ca7aa56f7787...`	`197e32f59e65093c...`
*-x86_64-apple-darwin-codesigning.tar.gz	`0cc8b72f029ddcaf...`
*-x86_64-apple-darwin-unsigned.tar.gz	`91e7e882c35a3f30...`
*-x86_64-apple-darwin-unsigned.zip	`058d461790e90df9...`
*-x86_64-linux-gnu-debug.tar.gz	`88de3a19603c413c...`	`4a0170d30d91d5e6...`
*-x86_64-linux-gnu.tar.gz	`52c8471f79f62023...`	`6c9f415a4006524b...`
*.tar.gz	`519150aed6da5f1b...`	`054311ccbe246b6b...`
SHA256SUMS.part	`210bd14fc7210e8a...`	`dd518a279543dd5e...`
guix_build.log	`bdff2fe226e41677...`	`7f7d0af0ae5679f1...`
guix_build.log.diff		`80efb0867c82240f...`

DrahtBot removed the label DrahtBot Guix build requested on Sep 30, 2025

fanquake commented at 10:31 pm on September 30, 2025: member

This will likely fix the Guix build:

0--- a/contrib/guix/symbol-check.py
1+++ b/contrib/guix/symbol-check.py
2@@ -249,7 +249,7 @@ def check_MACHO_libraries(binary) -> bool:
3     return ok
4 
5 def check_MACHO_min_os(binary) -> bool:
6-    if binary.build_version.minos == [13,0,0]:
7+    if binary.build_version.minos == [14,0,0]:
8         return True
9     return False

Drop support for EOL macOS 13 fadad7a494

fuzz: Drop unused workaround after Apple-Clang bump 1aaaaa078b

maflcko force-pushed on Oct 1, 2025

maflcko added the label DrahtBot Guix build requested on Oct 1, 2025

hodlinator approved

hodlinator commented at 7:46 am on October 1, 2025: contributor

re-ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818

Bumped version in 3 more places and dropped fuzz-workaround.

0a9cdca5dc929d3c6c937e0a9069f2607552283087c51c4fac7921531a4b97bbf  guix-build-1aaaaa078bb2/output/arm64-apple-darwin/SHA256SUMS.part
1673dcca25defb6d09d5ffb9aa9bec86884d445bc15c94d191bb81b06bc13b0a1  guix-build-1aaaaa078bb2/output/arm64-apple-darwin/bitcoin-1aaaaa078bb2-arm64-apple-darwin-codesigning.tar.gz
2674cfe724d57aeb2afaff18195347c90b347565d800ede2842d42ca04b1a9023  guix-build-1aaaaa078bb2/output/arm64-apple-darwin/bitcoin-1aaaaa078bb2-arm64-apple-darwin-unsigned.tar.gz
33a6d025c52f0a8eca3303dc95c844eb51a1dfcdaec8afd80b218c152e3103dd4  guix-build-1aaaaa078bb2/output/arm64-apple-darwin/bitcoin-1aaaaa078bb2-arm64-apple-darwin-unsigned.zip
44d15a5d8bde45e21f84909200d09ebf3f13672f2242dac9578734553b124719d  guix-build-1aaaaa078bb2/output/dist-archive/bitcoin-1aaaaa078bb2.tar.gz
5e9c7bc519fc6ffc72409fd1db424f9f82e7b19342f6be0bc59c6ec81e6ea98b6  guix-build-1aaaaa078bb2/output/x86_64-apple-darwin/SHA256SUMS.part
66d26fc4c9856d99704822e6eadf957847c6f8d0e2ec9b38a1e2fdc617a43be9e  guix-build-1aaaaa078bb2/output/x86_64-apple-darwin/bitcoin-1aaaaa078bb2-x86_64-apple-darwin-codesigning.tar.gz
7e872ed94793168eb2035c6ce90c25a9848871c1ea02cf88510a0f7c880445874  guix-build-1aaaaa078bb2/output/x86_64-apple-darwin/bitcoin-1aaaaa078bb2-x86_64-apple-darwin-unsigned.tar.gz
8844f540e732d1985f64aedd2ebbdc67e6aa2c544834bf5f9e5cca2f02c3a8239  guix-build-1aaaaa078bb2/output/x86_64-apple-darwin/bitcoin-1aaaaa078bb2-x86_64-apple-darwin-unsigned.zip

DrahtBot requested review from stickies-v on Oct 1, 2025

stickies-v commented at 10:27 am on October 1, 2025: contributor

re-ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818

DrahtBot commented at 2:58 am on October 2, 2025: contributor

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

File	commit f41f97240c06fbb1a70c3462dcc8d3d6734e4199(master)	commit 5352a0db57c280fab68650783ccae43713c1fed3(pull/33489/merge)
*-aarch64-linux-gnu-debug.tar.gz	`35b7c2fec31a2b9f...`	`1021218f357b26bf...`
*-aarch64-linux-gnu.tar.gz	`f207135286722f5b...`	`a85d037ec9c98fc5...`
*-arm-linux-gnueabihf-debug.tar.gz	`ee501f6f8e721ef9...`	`3520bbf0b8ff4416...`
*-arm-linux-gnueabihf.tar.gz	`0e7b094ff22affc3...`	`c96ac9a49487a3ca...`
*-arm64-apple-darwin-codesigning.tar.gz	`dd78b12a869d1e8f...`	`bf74c81a6836991c...`
*-arm64-apple-darwin-unsigned.tar.gz	`14c891899b0433e3...`	`d078c173a03d7255...`
*-arm64-apple-darwin-unsigned.zip	`483d4096c0a2c0f6...`	`2702a90b87e83857...`
*-powerpc64-linux-gnu-debug.tar.gz	`bf50aeda683016e9...`	`8df5378ef504cd36...`
*-powerpc64-linux-gnu.tar.gz	`c7de6894e0e05c29...`	`3017ff0e24a74990...`
*-riscv64-linux-gnu-debug.tar.gz	`bd3d8226c66ab628...`	`18870901a2b6f5b7...`
*-riscv64-linux-gnu.tar.gz	`a76c0590e27ee802...`	`d89a3a1cead6aac0...`
*-x86_64-apple-darwin-codesigning.tar.gz	`91e535145d5f1ff9...`	`0e9de811589b9954...`
*-x86_64-apple-darwin-unsigned.tar.gz	`ac192ccd08539550...`	`795bd6806a4b5e23...`
*-x86_64-apple-darwin-unsigned.zip	`61886daf83664eb5...`	`5ed306083344545a...`
*-x86_64-linux-gnu-debug.tar.gz	`9d8354e25bb71c19...`	`4ad5caa7b7a8ebe2...`
*-x86_64-linux-gnu.tar.gz	`62e9e1084e7cb454...`	`d4a17af8a92b0ef7...`
*.tar.gz	`8ac413d7387a3587...`	`78b333af90fcfe26...`
SHA256SUMS.part	`27b9516ad575bc4e...`	`f831c31d0d3d5992...`
guix_build.log	`388b38082c568be2...`	`f8fa1141cc33b34d...`
guix_build.log.diff		`43c2dd987dd6e080...`

DrahtBot removed the label DrahtBot Guix build requested on Oct 2, 2025

l0rinc approved

l0rinc commented at 2:29 pm on October 2, 2025: contributor

Concept ACK for the version bump

Looking around for more versions and checking https://github.com/bitcoin/bitcoin/commit/446e73cc0bb7cd628039eaf9b1bcc93db23b924f it seem to me we could update a few more places:

Note that latest AppleClang doesn’t play well with latest Clang regarding fuzzing: #32084 (comment)

maflcko commented at 2:46 pm on October 2, 2025: member

Looking around for more versions and checking 446e73c it seem to me we could update a few more places:

This is about something else: The sdk and xcode version used for the depends/guix build. So it should be a separate pull request. Generally, bumping the sdk/xcode in depends is a lengthy/tedious process, so it should be done only when needed. My recommendation would be to bump it to 26.x within the next year, or to 27.x in one year.

Whereas, this pull request is about increasing the min macos version to exclude the EOL macos version(s). This also allows to bump the xcode when self-compiling, e.g. in CI.

Note that latest AppleClang doesn’t play well with latest Clang regarding fuzzing: #32084 (comment)

Thx, but I don’t see how this is related to this pull?

l0rinc commented at 2:53 pm on October 2, 2025: contributor

This is about something else:

What’s the reason for keeping a version in the bug issue template that we don’t support?

I don’t see how this is related to this pull?

If we recommend a newer AppleClang version, it may not work with fuzzing, that’s all.

maflcko commented at 2:57 pm on October 2, 2025: member

This is about something else:

What’s the reason for keeping a version in the bug issue template that we don’t support?

It is just a placeholder, so shouldn’t matter. I can bump it on the next push, if there is one, or it can be done as a follow-up.

l0rinc commented at 3:19 pm on October 2, 2025: contributor

code review ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818

hebasto approved

hebasto commented at 1:32 pm on October 5, 2025: member

ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818.

glozow merged this on Oct 6, 2025

glozow closed this on Oct 6, 2025

maflcko deleted the branch on Oct 7, 2025

TheCharlatan referenced this in commit 5f9d179b8d on Oct 8, 2025

TheCharlatan referenced this in commit 845b93d99e on Oct 8, 2025

yuvicc referenced this in commit ccce70c31a on Oct 8, 2025

Sjors commented at 8:33 am on October 10, 2025: member

I just retired my 27" iMac from 2017, which happens to only support macOS 13. I was only using it for its great 5K monitor though, connecting my IDE to a faster computer for compilation.

That means it will be more work for me to test things on that machine, since even booting it takes several minutes. If I was still using that machine I would have preferred to maintain support for it a bit longer, until something actually breaks or blocks progress.

maflcko commented at 8:46 am on October 10, 2025: member

I just retired my 27" iMac from 2017, which happens to only support macOS 13. I was only using it for its great 5K monitor though, connecting my IDE to a faster computer for compilation.

That means it will be more work for me to test things on that machine, since even booting it takes several minutes. If I was still using that machine I would have preferred to maintain support for it a bit longer, until something actually breaks or blocks progress.

I don’t think this pull request changes anything about your workflow, if you connect to a different computer to compile and run.

Also, I am sure as a developer you can trivially still compile on your old machine, if you want to. You’ll have to carry a patch to revert the src/test/fuzz/fuzz.cpp changes (or skip compiling it), but that is trivial for you as a developer. (It may also be possible to use the clang package from brew or nix to compile, but that isn’t supported or documented IIRC)

The goal here is to drop support for an insecure base operating system, so that users are not exposing themselves to unfixed security vulnerabilities on an internet-connected machine.

Not sure what should be done differently here exactly to have a net benefit, but there are still 6 months until this even hits a release, so if there is something I am missing, there is plenty of time to re-visit.

Sjors commented at 9:01 am on October 10, 2025: member

I don’t think this pull request changes anything about your workflow, if you connect to a different computer to compile and run.

I’m not worried about my own workflow for running a node, I was talking about us supporting it as a project. For that I need to compile it to occasionally test things, which is more work since I no longer have that machine on all day.

The goal here is to drop support for an insecure base operating system

(macOS Ventura 13.7.8 received its final security update on 20 Aug 2025: https://support.apple.com/en-us/100100)

That article doesn’t say it’s the “final” update, it’s just the most recent one. I can’t find an official statement by Apple themselves that this version of macOS is unsupported, that seems to be an interpretation by others. It seems to be an extrapolation based on their hardware support.

There are more recent security updates for other versions of macOS, but it could simply be that these issues don’t impact 13. If on the other hand we know those bugs do apply to macOS 13, then that’s a clear sign they actually stopped maintaining it.

maflcko commented at 9:42 am on October 10, 2025: member

I’m not worried about my own workflow for running a node, I was talking about us supporting it as a project.

I think dropping support for an OS that hasn’t received security updates for 6 months is fine. Also, you can still run a 30.x node until the release of 33.0 (https://bitcoincore.org/en/lifecycle/), which is 1.5 years. Also, you can compile and run any version yourself at your own risk (not using xcode).

Though, I am happy to review a pull request with the improvements you have in mind, if there are some.

build: Drop support for EOL macOS 13 #33489

Code Coverage & Benchmarks

Reviews

Conflicts

LLM Linter (✨ experimental)

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]