Skip to content

[experiment] Unify mbedtls dependants #27581

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

AbrilRBS
Copy link
Member

@AbrilRBS AbrilRBS commented Jun 1, 2025

From https://github.com/Mbed-TLS/mbedtls/blob/development/BRANCHES.md, we should probably try to align mbedtls. This also readies us for the next LTS to be released late this year

Currently there are 19 requirements, where only a few are there by default. 7 in 2.x, the rest in 3.x, where major version releases break API compatibility.
Note that some of these requirements belong to the same recipe, which got upgraded support for mbedtls in newer versions

If not mentioned below, all changes here compile successfully for both shared/static in both the oldest and newest versions

  • As the 2.x branch does not get any more updates, we should try to converge on the latest if possible

    • This would entail creating 2.28.10 (See Add MbedTLS 2.28.10 #26978 which could be closed) as the last LTS release for 2.28, and then move the 7 recipes to this version over a version range of [~2.28]. Only one recipe is already using the LTS version, so try not to break the others
      • cose-c is not compatible with the 2.28 LTS, it needs to stay in 2.16
      • nng versions which uses 2.25 has never worked with &:tls=True enabled
        • Remove old versions that use it, they are 5 years old without CCI requirements
        • No reason popularity wise not to remove them
      • Yojimbo is a Conan 1 recipe that has not yet been ported, not updating it
  • For the 3.x branch, the current LTS is 3.6, so those that use it might want to see a version range for the patch releases of said version, and we should prefer that version in recipes above others unless necessary

    • Create the newest release for 3.6 (3.6.3.1 as of 1/6/2025)
    • First port the 3 recipes in 3.6 already to it with [~3.6]
      • libarchive needed some changes to make older versions cmake 4 compatible
      • libdatachannel validates out when using mbedtls due to compilation issues
      • libssh needed some changes to make oldest version cmake 4 compatible, not removing it because we only provide 2
    • The other 8 recipes should be tried on a per case basis, but it’s expected that most if not all recipes work
      • libcoap has never compiled with dtls_backend=mbedtls, keeping 3.2.1 but removing from mbedtls
        • TODO, what should we do with this one?
      • libgit2 has never found mbedtls
        • Fixed by adding a cmakedeps cmake_file_name proper filename
        • But old versions did’t work regardless of changes, as it would need more changes to the recipe
        • Keep new version range that works for newer versions, don’t bother with the failing ones
      • libssh2 does not support mbedtls 3.6 api changes
        • Keep in 3.5, but upgrade to 3.5.2, only version we’re keeping
      • libwebsockets does not support mbedtls 3.6 api changes
        • Keep in 3.5, but upgrade to 3.5.2, only version we’re keeping
        • Add missing transitive_headers to it
      • libzip needed some changes to make older versions cmake 4 compatible
      • lief oldest version does not support mbedtls 3.6 api changes
        • Removing it might not be an option as it's popular enough
        • Bump to 3.5.2 which is supported by both versions
      • nng supports mbedtls 3.6 from 1.7.3, but old versions do not
        • As per the same as above , 1.5.2 has enough popularity not to remove them
        • Keep in 3.52

This PR won’t create new missing binaries downstream as it modifies the revisions of all recipes that get their mbedtls version bumped

Would close #23762 mbedtls side, would still need to bump openssl, leaving it for that PR (There are probably more PRs that would be a subset of this one, I'll note them here once I find them, but they should already show up in the Related PR check)

@AbrilRBS
Copy link
Member Author

AbrilRBS commented Jun 1, 2025

Ci skipped for this one until I discuss it with the team as to not waste unnecessary cycles

@AbrilRBS AbrilRBS marked this pull request as ready for review June 5, 2025 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant