Upstream has provided migration instructions from 2. to 3. to its downstreams, https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 so it's clear the revdeps of mbedtls need to be updated in Gentoo before =>3 can work. https://qa-reports.gentoo.org/output/genrdeps/dindex/net-libs/mbedtls
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=33cd33cd8fccba7b9c4cdffdfc0b1b23226a2c7b commit 33cd33cd8fccba7b9c4cdffdfc0b1b23226a2c7b Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2021-07-29 10:39:12 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-07-29 10:46:05 +0000 profiles: mask >=net-libs/mbedtls Bug: https://bugs.gentoo.org/805011 Signed-off-by: Joonas Niilola <juippis@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
Here's a suggestion: re-introduce mbedtls-3.0.0-r1 with a SLOT="3/16" defined, revbump all rdeps to (R)DEPEND on :0 until a patched ebuild version is introduced to depend on :3.
(In reply to Joonas Niilola from comment #2) > Here's a suggestion: re-introduce mbedtls-3.0.0-r1 with a SLOT="3/16" > defined, revbump all rdeps to (R)DEPEND on :0 until a patched ebuild version > is introduced to depend on :3. I would rather do SLOT="3/10.16.4" Comments before I rev bump? (Its masked for now so we should be safe to play around a bit.)
There's some ongoing discussion happening in the linked pull request: https://github.com/gentoo/gentoo/pull/21820 I think the strongest suggestion now is to keep this masked, discover all broken rdeps, and add fixed rdeps one-by-one with their addition to package.mask. But please participate in the PR discussion, nothing's been decided yet.
As a new maintainer I'm thinking of splitting the package to mbedtls:2 and mbedtls:3 in order to keep both versions in the tree. Some packages are unable or not willing to migrate to slowly deprecating mbedtls:2 branches, so we are forced to keep them both for a while. There two approaches to implement subslotting: 1. Placing installation into /usr/lib/mbedtls2/ with symlinks in /usr/lib/ (so we don't need to mess with LD_LIBRARY_PATH; Arch Linux chosen this way, see https://gitlab.archlinux.org/archlinux/packaging/packages/mbedtls2/-/blob/main/PKGBUILD?ref_type=heads). 2. Renaming libraries itself to libmbedtls{2,3}.so libmbedcrypto{2,3}.so and libmbedx509{2,3}.so with soversion symlinks (i.e. libmbedtls.so.2.18.7). Both approaches require adjusting their building in the configuration process. While option 1 is easy to implement, I think to go option 2 because MbedTLS 3 already has cmake config files for dependency discovery, and option 2 more fits for this. As for MbedTLS 2 I'm planning to backport that config generation. Upstream has some issues in build system that I intend to fix with these PRs in order to achieve subslotting features (https://github.com/Mbed-TLS/mbedtls/pull/8800 and https://github.com/Mbed-TLS/mbedtls/pull/8795).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59eca6456e672aa6e0ba39ee15a2fd449c80367d commit 59eca6456e672aa6e0ba39ee15a2fd449c80367d Author: Azamat H. Hackimov <azamat.hackimov@gmail.com> AuthorDate: 2024-11-30 22:46:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-05 20:26:24 +0000 net-libs/mbedtls: slotting version 3 MbedTLS breaks API compatibility between major versions, and some packages are unable or not willing to migrate from slowly deprecating mbedtls-2 branches, so we are forced to keep them both for a while. Upstream PR: https://github.com/Mbed-TLS/mbedtls/pull/8800 [sam: Note that: a) upstream are fine with us doing this (per the upstream PR), and b) consumers (almost?) always use CMake config files so they automatically pick up the slotting.] Bug: https://bugs.gentoo.org/805011 Signed-off-by: Azamat H. Hackimov <azamat.hackimov@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> ...ersion-suffix-for-all-installable-targets.patch | 79 +++++++++++++++ ...2-add-version-suffix-for-pkg-config-files.patch | 71 ++++++++++++++ ...low-install-headers-to-different-location.patch | 105 ++++++++++++++++++++ .../mbedtls-3.6.2-exclude-static-3dparty.patch | 22 +++++ net-libs/mbedtls/mbedtls-3.6.2-r100.ebuild | 109 +++++++++++++++++++++ 5 files changed, 386 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=604ef8645fd9c5c513b271dc59ef505b69ae5a0d commit 604ef8645fd9c5c513b271dc59ef505b69ae5a0d Author: Sam James <sam@gentoo.org> AuthorDate: 2025-01-05 21:49:11 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-05 21:49:11 +0000 profiles: unmask mbedtls-3 We have slotted mbedtls now (see 59eca6456e672aa6e0ba39ee15a2fd449c80367d). Bug: https://bugs.gentoo.org/805011 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 5 ----- 1 file changed, 5 deletions(-)
(In reply to Azamat H. Hackimov from comment #5) > As a new maintainer I'm thinking of splitting the package to mbedtls:2 and > mbedtls:3 in order to keep both versions in the tree. Some packages are > unable or not willing to migrate to slowly deprecating mbedtls:2 branches, > so we are forced to keep them both for a while. as it stands now, mbedtls-2.* installs ssl.h in /usr/include/mbedtls/ssl.h and mbedtls-3.* places the same file in /usr/include/mbedtls3/mbedtls/ssl.h am I to expect that every single package that depends on >=mbedtls-3 will need a patch for their build process? are there still packages that actually depend on <mbedtls-3? my reference point is that FreeBSD ports dopped mbedtls-2 entirely and autoconf for mbedtls (3) works without any extra patches.
(In reply to Petre Rodan from comment #8) > am I to expect that every single package that depends on >=mbedtls-3 will > need a patch for their build process? If package explicitly supports mbedtls 3 (developers made some efforts to fix breaking changes in API), then these patches are trivial. Proper CMake projects that calls `find_package(MbedTLS 3)` not requires changes at all. Some efforts should be done if they uses customized FindMbedTLS.cmake or relies to pkg-config output. > are there still packages that actually depend on <mbedtls-3? my reference > point is that FreeBSD ports dopped mbedtls-2 entirely and autoconf for > mbedtls (3) works without any extra patches. Particularly, games-emulation/dolphin explicitly requires mbedtls-2 as this is last version where TLS 1.0 still exists. Some legacy and ancient packages without active development also stuck on mbedtls-2 branch.
(In reply to Azamat H. Hackimov from comment #9) > Particularly, games-emulation/dolphin explicitly requires mbedtls-2 as this > is last version where TLS 1.0 still exists. Some legacy and ancient packages > without active development also stuck on mbedtls-2 branch. thank you for your reply. IMHO the default mbedtls provider (the one packages find when looking for the mbedtls headers and libs) should be the new version (3+) not the old one (2+). here are my arguments: - TLS 1.0 and 1.1 are marked as deprecated. RFC8996 specifies that "TLS 1.0 MUST NOT be used. Negotiation of TLS 1.0 from any version of TLS MUST NOT be permitted." "TLS 1.1 MUST NOT be used. Negotiation of TLS 1.1 from any version of TLS MUST NOT be permitted." packages should find the ssl provider that has the most advanced crypto algorihms available. - TLS 1.2 handshakes are marked as "no longer supported" by some software, see https://github.com/umurmur/umurmur/issues/193#issuecomment-2628023737 - TLS 1.3 is only supported since mbedtls-3.1.0, so no support in mbedtls-2.x - in the release notes of mbedtls-2.28.9 it's said that "Mbed TLS 2.28 is a long-time support branch. It will be supported with bug-fixes and security fixes until end of 2024.". not sure if there will be any other 2.x LTS version starting from 2025. - if there are legacy packages that do require deprecated crypto those should be the ones that would require a build patch to use a legacy library. which legacy library should not be found as the default include/lib under any circumstances. what is your opinion on this? I can help test some of the 32 packages that depend on mbedtls, I have a 3.x ebuild that pretends to be slot0 in my overlay https://github.com/rodan/overlay/tree/master/net-libs/mbedtls
(In reply to Petre Rodan from comment #10) > - if there are legacy packages that do require deprecated crypto those > should be the ones that would require a build patch to use a legacy library. > which legacy library should not be found as the default include/lib under > any circumstances. System legacy package is better than bundled. In case of system package at least we can control that dependent package is still uses latest version of EOL library. As long there packages in tree that are still using mbedtls-2 only libraries there no optimal solution. Some packages may be treecleaned or updated to use :3 branch, but this is long path that requires both slots in tree for awhile. Still, I want to preserve current versioning scheme, as there will be MbedTLS 4 and onward, and I want to ease pain with API breakage in packages again that may happens in distant future. > I can help test some of the 32 packages that depend on mbedtls, I have a 3.x > ebuild that pretends to be slot0 in my overlay > https://github.com/rodan/overlay/tree/master/net-libs/mbedtls I've already reviewed most of packages that currently depends on mbedtls-2:0, and most (but not all) can be switched to mbedtls-3 only version with some patches. It would be great if these patches will be upstreamed (like https://github.com/gentoo/gentoo/pull/39999).
I wonder if bug 947612 resolution solves this as well: https://bugs.gentoo.org/947612#c5
