| Message ID | 20211228153345.4087026-1-fontaine.fabrice@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/2] package/mbedtls3: new package | expand |
On Tue, 28 Dec 2021 16:33:44 +0100 Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: > mbedtls 3.x is incompatible with mbedtls 2.x: > https://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guide.md > > mbedtls3 was created from mbedtls package with the following changes: > - license file is now LICENSE > - zlib compression is not available anymore > - config.h renamed to mbedtls_config.h > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> An important (and unfortunate point) is that apparently mbedtls3 cannot be installed side-by-side with mbedtls. At least that's what your "depends on !BR2_PACKAGE_MBEDTLS" seems to hint. This is a major annoyance, and I'm not sure how Linux distributions will handle this migration if they cannot have mbedtls 2.x and mbedtls 3.x installed side by side. Have you talked with mbedtls upstream about this? It seems really odd that they didn't plan this possibility. Thanks! Thomas
Le mar. 28 déc. 2021 à 16:49, Thomas Petazzoni <thomas.petazzoni@bootlin.com> a écrit : > > On Tue, 28 Dec 2021 16:33:44 +0100 > Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: > > > mbedtls 3.x is incompatible with mbedtls 2.x: > > https://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guide.md > > > > mbedtls3 was created from mbedtls package with the following changes: > > - license file is now LICENSE > > - zlib compression is not available anymore > > - config.h renamed to mbedtls_config.h > > > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> > > An important (and unfortunate point) is that apparently mbedtls3 cannot > be installed side-by-side with mbedtls. At least that's what your > "depends on !BR2_PACKAGE_MBEDTLS" seems to hint. Indeed, both versions install their headers in include/mbedtls. > > This is a major annoyance, and I'm not sure how Linux distributions > will handle this migration if they cannot have mbedtls 2.x and mbedtls > 3.x installed side by side. 3.0 was released in July. To my knowledge, hiawatha is one of the first package that uses this new API and buildroot will probably be one of the first build system that will provide mbedts3. IMHO, being unable to install both versions side by side is pretty common: we had the same issue with libupnp 1.6.x and libupnp 1.8.x. Concerning libupnp, we even had to revert the possibility to install both versions side by side because it was a "burden to programs linking against libupnp": https://github.com/pupnp/pupnp/commit/07f504c61bd9e4d93eb3d373ffc8527cafe0b9af > > Have you talked with mbedtls upstream about this? It seems really odd > that they didn't plan this possibility. > > Thanks! > > Thomas > -- > Thomas Petazzoni, co-owner and CEO, Bootlin > Embedded Linux and Kernel engineering and training > https://bootlin.com Best Regards, Fabrice
Hello, On Tue, 28 Dec 2021 18:07:03 +0100 Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: > > An important (and unfortunate point) is that apparently mbedtls3 cannot > > be installed side-by-side with mbedtls. At least that's what your > > "depends on !BR2_PACKAGE_MBEDTLS" seems to hint. > Indeed, both versions install their headers in include/mbedtls. > > > > This is a major annoyance, and I'm not sure how Linux distributions > > will handle this migration if they cannot have mbedtls 2.x and mbedtls > > 3.x installed side by side. > 3.0 was released in July. > To my knowledge, hiawatha is one of the first package that uses this > new API and buildroot will probably be one of the first build system > that will provide mbedts3. > IMHO, being unable to install both versions side by side is pretty > common: we had the same issue with libupnp 1.6.x and libupnp 1.8.x. > Concerning libupnp, we even had to revert the possibility to install > both versions side by side because it was a "burden to programs > linking against libupnp": > https://github.com/pupnp/pupnp/commit/07f504c61bd9e4d93eb3d373ffc8527cafe0b9af I'm not sure to follow you here. The fact that it's pretty common doesn't make it a good solution. It makes the transition period absolutely awful. With the currently proposed approach, someone who today has a working configuration that has hiawatha and belle-sip can conveniently build both in the same image. With your patch applied, this is no longer possible, due to hiawatha now using mbedtls3, which cannot be installed side-by-side with mbedtls. This doesn't seem very acceptable for us, and probably is even less acceptable for major Linux distributions. Has this been discussed with upstream mbedtls ? Thomas
Hi everyone! On 12/28/21 6:14 PM, Thomas Petazzoni wrote: > On Tue, 28 Dec 2021 18:07:03 +0100 Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: >>> An important (and unfortunate point) is that apparently mbedtls3 cannot >>> be installed side-by-side with mbedtls. At least that's what your >>> "depends on !BR2_PACKAGE_MBEDTLS" seems to hint. >> Indeed, both versions install their headers in include/mbedtls. >>> This is a major annoyance, and I'm not sure how Linux distributions >>> will handle this migration if they cannot have mbedtls 2.x and mbedtls >>> 3.x installed side by side. >> 3.0 was released in July. >> To my knowledge, hiawatha is one of the first package that uses this >> new API and buildroot will probably be one of the first build system >> that will provide mbedts3. >> IMHO, being unable to install both versions side by side is pretty >> common: we had the same issue with libupnp 1.6.x and libupnp 1.8.x. >> Concerning libupnp, we even had to revert the possibility to install >> both versions side by side because it was a "burden to programs >> linking against libupnp": >> https://github.com/pupnp/pupnp/commit/07f504c61bd9e4d93eb3d373ffc8527cafe0b9af > I'm not sure to follow you here. The fact that it's pretty common > doesn't make it a good solution. It makes the transition period > absolutely awful. > With the currently proposed approach, someone who today has a working > configuration that has hiawatha and belle-sip can conveniently build > both in the same image. With your patch applied, this is no longer > possible, due to hiawatha now using mbedtls3, which cannot be installed > side-by-side with mbedtls. > This doesn't seem very acceptable for us, and probably is even less > acceptable for major Linux distributions. I looked into this, ever so briefly, and without checking with any of the packages that select BR2_PACKAGE_MBEDTLS. However, seeing as it is only Hiawatha that requires a version >= 3.0, for a transition period, we could change it to -DUSE_SYSTEM_MBEDTLS=OFF and let Hiawatha use its bundled mbedtls instead. Best regards /Joachim
Hi, Le ven. 31 déc. 2021 à 09:26, Joachim Wiberg <troglobit@gmail.com> a écrit : > > Hi everyone! > > On 12/28/21 6:14 PM, Thomas Petazzoni wrote: > > On Tue, 28 Dec 2021 18:07:03 +0100 Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: > >>> An important (and unfortunate point) is that apparently mbedtls3 cannot > >>> be installed side-by-side with mbedtls. At least that's what your > >>> "depends on !BR2_PACKAGE_MBEDTLS" seems to hint. > >> Indeed, both versions install their headers in include/mbedtls. > >>> This is a major annoyance, and I'm not sure how Linux distributions > >>> will handle this migration if they cannot have mbedtls 2.x and mbedtls > >>> 3.x installed side by side. > >> 3.0 was released in July. > >> To my knowledge, hiawatha is one of the first package that uses this > >> new API and buildroot will probably be one of the first build system > >> that will provide mbedts3. > >> IMHO, being unable to install both versions side by side is pretty > >> common: we had the same issue with libupnp 1.6.x and libupnp 1.8.x. > >> Concerning libupnp, we even had to revert the possibility to install > >> both versions side by side because it was a "burden to programs > >> linking against libupnp": > >> https://github.com/pupnp/pupnp/commit/07f504c61bd9e4d93eb3d373ffc8527cafe0b9af > > I'm not sure to follow you here. The fact that it's pretty common > > doesn't make it a good solution. It makes the transition period > > absolutely awful. > > With the currently proposed approach, someone who today has a working > > configuration that has hiawatha and belle-sip can conveniently build > > both in the same image. With your patch applied, this is no longer > > possible, due to hiawatha now using mbedtls3, which cannot be installed > > side-by-side with mbedtls. > > This doesn't seem very acceptable for us, and probably is even less > > acceptable for major Linux distributions. > > I looked into this, ever so briefly, and without checking with any of > the packages that select BR2_PACKAGE_MBEDTLS. > > However, seeing as it is only Hiawatha that requires a version >= 3.0, > for a transition period, we could change it to -DUSE_SYSTEM_MBEDTLS=OFF > and let Hiawatha use its bundled mbedtls instead. Indeed, this is also an alternative, even if I think that adding mbedtls3 would be a great addition. For example, libcurl supports mbedts 3.0 since its version 7.79 and https://github.com/curl/curl/commit/3f126138be3c459a2794d35f8170e92e65a50dad. Otherwise, as requested by Thomas, I sent an email to mbedtls mailing list: https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/HEHCNQZTBOZV56RTGRTGSQQRMEWYJPGI/ Here is an extract of their answer: "you need to install the header files and the libraries under different paths. At most one can be in the default include and lib directories. Since each program can only use one version, you need to pick the desired -I/-L paths at compile/link times." So basically, we can't really install them side by side in the context of buildroot except if you want to patch every single mbedtls package with custom CFLAGS and LDFLAGS ... If one of you wants to debate with them, feel free to do it. > > > Best regards > /Joachim Best Regards, Fabrice
>>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: Hi, > Indeed, this is also an alternative, even if I think that adding > mbedtls3 would be a great addition. > For example, libcurl supports mbedts 3.0 since its version 7.79 and > https://github.com/curl/curl/commit/3f126138be3c459a2794d35f8170e92e65a50dad. > Otherwise, as requested by Thomas, I sent an email to mbedtls mailing > list: > https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/HEHCNQZTBOZV56RTGRTGSQQRMEWYJPGI/ What is the plan from upstream regarding mbedtls 2.x? Will it be maintained in parallel with 3.x for some time (and for how long?) or is it effectively EOL already? If it is EOL then I guess we should just update the current mbedtls package to 3.x (and disable mbedtls support for packages not compatible with it yet), but if the plan is to support 2.x for quite some time then indeed a separate mbedtls3 package makes more sense.
Hi, Le sam. 8 janv. 2022 à 15:14, Peter Korsgaard <peter@korsgaard.com> a écrit : > > >>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: > > Hi, > > > Indeed, this is also an alternative, even if I think that adding > > mbedtls3 would be a great addition. > > For example, libcurl supports mbedts 3.0 since its version 7.79 and > > https://github.com/curl/curl/commit/3f126138be3c459a2794d35f8170e92e65a50dad. > > Otherwise, as requested by Thomas, I sent an email to mbedtls mailing > > list: > > https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/HEHCNQZTBOZV56RTGRTGSQQRMEWYJPGI/ > > What is the plan from upstream regarding mbedtls 2.x? Will it be > maintained in parallel with 3.x for some time (and for how long?) or is > it effectively EOL already? 2.16.x is EOL since December 2021: https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 The next LTS branch is 2.28 which will be maintained until end of 2024: https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md > > If it is EOL then I guess we should just update the current mbedtls > package to 3.x (and disable mbedtls support for packages not compatible > with it yet), but if the plan is to support 2.x for quite some time then > indeed a separate mbedtls3 package makes more sense. > > -- > Bye, Peter Korsgaard Best Regards, Fabrice
>>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: > Hi, > Le sam. 8 janv. 2022 à 15:14, Peter Korsgaard <peter@korsgaard.com> a écrit : >> >> >>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: >> >> Hi, >> >> > Indeed, this is also an alternative, even if I think that adding >> > mbedtls3 would be a great addition. >> > For example, libcurl supports mbedts 3.0 since its version 7.79 and >> > https://github.com/curl/curl/commit/3f126138be3c459a2794d35f8170e92e65a50dad. >> > Otherwise, as requested by Thomas, I sent an email to mbedtls mailing >> > list: >> > https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/HEHCNQZTBOZV56RTGRTGSQQRMEWYJPGI/ >> >> What is the plan from upstream regarding mbedtls 2.x? Will it be >> maintained in parallel with 3.x for some time (and for how long?) or is >> it effectively EOL already? > 2.16.x is EOL since December 2021: > https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 > The next LTS branch is 2.28 which will be maintained until end of > 2024: https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md Ok, so we should ideally move our mbedtls version to 2.28.x before 2022.02. What about 3.x, is that also a LTS or is that considered a not-yet-stable development version? For the question if we need to maintain both 2.28.x and 3.x in parallel I guess it really depends on if the packages we have depending on mbedtls (E.G. bctoolbox, bmx7, mongrel2, shadowsocks-libev) can (be patched to) work with mbedtls 3.x or not? If they can (or are no longer maintained upstream), then I would prefer to only support mbedtls 3.x going forward. If on the other hand mbedtls 3.x isn't really stable yet and only needed for hiawatha, then indeed we should perhaps just postpone it a bit and use the internal mbedtls copy in hiawatha or downgrade / drop TLS support.
Le sam. 8 janv. 2022 à 17:54, Peter Korsgaard <peter@korsgaard.com> a écrit : > > >>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: > > > Hi, > > Le sam. 8 janv. 2022 à 15:14, Peter Korsgaard <peter@korsgaard.com> a écrit : > >> > >> >>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: > >> > >> Hi, > >> > >> > Indeed, this is also an alternative, even if I think that adding > >> > mbedtls3 would be a great addition. > >> > For example, libcurl supports mbedts 3.0 since its version 7.79 and > >> > https://github.com/curl/curl/commit/3f126138be3c459a2794d35f8170e92e65a50dad. > >> > Otherwise, as requested by Thomas, I sent an email to mbedtls mailing > >> > list: > >> > https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/HEHCNQZTBOZV56RTGRTGSQQRMEWYJPGI/ > >> > >> What is the plan from upstream regarding mbedtls 2.x? Will it be > >> maintained in parallel with 3.x for some time (and for how long?) or is > >> it effectively EOL already? > > 2.16.x is EOL since December 2021: > > https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16 > > The next LTS branch is 2.28 which will be maintained until end of > > 2024: https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md > > Ok, so we should ideally move our mbedtls version to 2.28.x before > 2022.02. What about 3.x, is that also a LTS or is that considered a > not-yet-stable development version? > > For the question if we need to maintain both 2.28.x and 3.x in > parallel I guess it really depends on if the packages we have depending > on mbedtls (E.G. bctoolbox, bmx7, mongrel2, shadowsocks-libev) can (be > patched to) work with mbedtls 3.x or not? It is really unlikely that all these packages will be patched to work with mbedtls 3.x. To my knowledge, only hiawatha and curl have been patched to support mbedtls 3.x. and it should be noted that curl supports mbedtls 2.x and 3.x: https://github.com/curl/curl/commit/3f126138be3c459a2794d35f8170e92e65a50dad lighttpd is trying to migrate but has a lot of issues: https://github.com/ARMmbed/mbedtls/issues/5331 > > If they can (or are no longer maintained upstream), then I would prefer > to only support mbedtls 3.x going forward. If on the other hand mbedtls > 3.x isn't really stable yet and only needed for hiawatha, then indeed we > should perhaps just postpone it a bit and use the internal mbedtls copy > in hiawatha or downgrade / drop TLS support. 3.x is more "secure" because many obsolete cryptographic mechanisms and TLS protocol versions and options have been removed. However, it is probably ok to postpone the addition of mbedtls 3.x until more packages support it. It should be noted that we'll have the same issue/question with openssl 3.x ... > > -- > Bye, Peter Korsgaard Best Regards, Fabrice
>>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: Hi, >> For the question if we need to maintain both 2.28.x and 3.x in >> parallel I guess it really depends on if the packages we have depending >> on mbedtls (E.G. bctoolbox, bmx7, mongrel2, shadowsocks-libev) can (be >> patched to) work with mbedtls 3.x or not? > It is really unlikely that all these packages will be patched to work > with mbedtls 3.x. > To my knowledge, only hiawatha and curl have been patched to support > mbedtls 3.x. > and it should be noted that curl supports mbedtls 2.x and 3.x: > https://github.com/curl/curl/commit/3f126138be3c459a2794d35f8170e92e65a50dad > lighttpd is trying to migrate but has a lot of issues: > https://github.com/ARMmbed/mbedtls/issues/5331 Ok, thanks. >> If they can (or are no longer maintained upstream), then I would prefer >> to only support mbedtls 3.x going forward. If on the other hand mbedtls >> 3.x isn't really stable yet and only needed for hiawatha, then indeed we >> should perhaps just postpone it a bit and use the internal mbedtls copy >> in hiawatha or downgrade / drop TLS support. > 3.x is more "secure" because many obsolete cryptographic mechanisms and > TLS protocol versions and options have been removed. However, it is probably > ok to postpone the addition of mbedtls 3.x until more packages support it. Yes, I agree. What will we do about hiawatha? Patch it to work with 2.x as well, move to the internal mbedtls copy or revert the bump? Did you try contacting upstream about the issue? > It should be noted that we'll have the same issue/question with openssl 3.x ... Indeed, that is another can of worms that has been on my TODO list for a while...
Le sam. 8 janv. 2022 à 18:35, Peter Korsgaard <peter@korsgaard.com> a écrit : > > >>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes: > > Hi, > > >> For the question if we need to maintain both 2.28.x and 3.x in > >> parallel I guess it really depends on if the packages we have depending > >> on mbedtls (E.G. bctoolbox, bmx7, mongrel2, shadowsocks-libev) can (be > >> patched to) work with mbedtls 3.x or not? > > > It is really unlikely that all these packages will be patched to work > > with mbedtls 3.x. > > To my knowledge, only hiawatha and curl have been patched to support > > mbedtls 3.x. > > and it should be noted that curl supports mbedtls 2.x and 3.x: > > https://github.com/curl/curl/commit/3f126138be3c459a2794d35f8170e92e65a50dad > > lighttpd is trying to migrate but has a lot of issues: > > https://github.com/ARMmbed/mbedtls/issues/5331 > > Ok, thanks. > > >> If they can (or are no longer maintained upstream), then I would prefer > >> to only support mbedtls 3.x going forward. If on the other hand mbedtls > >> 3.x isn't really stable yet and only needed for hiawatha, then indeed we > >> should perhaps just postpone it a bit and use the internal mbedtls copy > >> in hiawatha or downgrade / drop TLS support. > > > 3.x is more "secure" because many obsolete cryptographic mechanisms and > > TLS protocol versions and options have been removed. However, it is probably > > ok to postpone the addition of mbedtls 3.x until more packages support it. > > Yes, I agree. What will we do about hiawatha? Patch it to work with 2.x > as well, move to the internal mbedtls copy or revert the bump? Did you > try contacting upstream about the issue? I didn't try to contact hiawatha but I think the easiest course of action would be to use the internal copy. I sent a patch. > > > > It should be noted that we'll have the same issue/question with openssl 3.x ... > > Indeed, that is another can of worms that has been on my TODO list for a > while... > > -- > Bye, Peter Korsgaard Best Regards, Fabrice
diff --git a/DEVELOPERS b/DEVELOPERS index 29390b0cc1..5604a1dd56 100644 --- a/DEVELOPERS +++ b/DEVELOPERS @@ -900,6 +900,7 @@ F: package/libupnp/ F: package/libv4l/ F: package/libxslt/ F: package/mbedtls/ +F: package/mbedtls3/ F: package/minissdpd/ F: package/minizip/ F: package/mongodb/ diff --git a/package/Config.in b/package/Config.in index 2635cc4b3c..422eff525d 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1419,6 +1419,7 @@ menu "Crypto" source "package/libuecc/Config.in" source "package/libxcrypt/Config.in" source "package/mbedtls/Config.in" + source "package/mbedtls3/Config.in" source "package/nettle/Config.in" source "package/openssl/Config.in" source "package/pkcs11-helper/Config.in" diff --git a/package/mbedtls3/Config.in b/package/mbedtls3/Config.in new file mode 100644 index 0000000000..83981bdf23 --- /dev/null +++ b/package/mbedtls3/Config.in @@ -0,0 +1,21 @@ +config BR2_PACKAGE_MBEDTLS3 + bool "mbedtls3" + depends on !BR2_PACKAGE_MBEDTLS + help + mbed TLS (formerly known as PolarSSL) makes it trivially easy + for developers to include cryptographic and SSL/TLS + capabilities in their (embedded) products, facilitating this + functionality with a minimal coding footprint. + + https://tls.mbed.org/ + +if BR2_PACKAGE_MBEDTLS3 + +config BR2_PACKAGE_MBEDTLS3_PROGRAMS + bool "mbedtls programs" + depends on BR2_USE_MMU # fork() + help + This option enables the installation and the build of + mbed TLS companion programs. + +endif diff --git a/package/mbedtls3/mbedtls3.hash b/package/mbedtls3/mbedtls3.hash new file mode 100644 index 0000000000..6da1030bff --- /dev/null +++ b/package/mbedtls3/mbedtls3.hash @@ -0,0 +1,4 @@ +# From https://github.com/ARMmbed/mbedtls/releases/tag/v3.1.0: +sha256 b02df6f68dd1537e115a8497d5c173dc71edc55ad084756e57a30f951b725acd mbedtls3-3.1.0.tar.gz +# Locally calculated +sha256 cfc7749b96f63bd31c3c42b5c471bf756814053e847c10f3eb003417bc523d30 LICENSE diff --git a/package/mbedtls3/mbedtls3.mk b/package/mbedtls3/mbedtls3.mk new file mode 100644 index 0000000000..c49b92aa9e --- /dev/null +++ b/package/mbedtls3/mbedtls3.mk @@ -0,0 +1,61 @@ +################################################################################ +# +# mbedtls3 +# +################################################################################ + +MBEDTLS3_VERSION = 3.1.0 +MBEDTLS3_SITE = $(call github,ARMmbed,mbedtls,v$(MBEDTLS3_VERSION)) +MBEDTLS3_CONF_OPTS = \ + -DENABLE_PROGRAMS=$(if $(BR2_PACKAGE_MBEDTLS3_PROGRAMS),ON,OFF) \ + -DENABLE_TESTING=OFF +MBEDTLS3_INSTALL_STAGING = YES +MBEDTLS3_LICENSE = Apache-2.0 +MBEDTLS3_LICENSE_FILES = LICENSE +MBEDTLS3_CPE_ID_VENDOR = arm +MBEDTLS3_CPE_ID_PRODUCT = mbed_tls + +# This is mandatory for hiawatha +ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y) +define MBEDTLS3_ENABLE_THREADING + $(SED) "s://#define MBEDTLS_THREADING_C:#define MBEDTLS_THREADING_C:" \ + $(@D)/include/mbedtls/mbedtls_config.h + $(SED) "s://#define MBEDTLS_THREADING_PTHREAD:#define MBEDTLS_THREADING_PTHREAD:" \ + $(@D)/include/mbedtls/mbedtls_config.h +endef +MBEDTLS3_POST_PATCH_HOOKS += MBEDTLS3_ENABLE_THREADING +ifeq ($(BR2_STATIC_LIBS),y) +MBEDTLS3_CONF_OPTS += -DLINK_WITH_PTHREAD=ON +endif +endif + +ifeq ($(BR2_STATIC_LIBS),y) +MBEDTLS3_CONF_OPTS += \ + -DUSE_SHARED_MBEDTLS_LIBRARY=OFF -DUSE_STATIC_MBEDTLS_LIBRARY=ON +else ifeq ($(BR2_SHARED_STATIC_LIBS),y) +MBEDTLS3_CONF_OPTS += \ + -DUSE_SHARED_MBEDTLS_LIBRARY=ON -DUSE_STATIC_MBEDTLS_LIBRARY=ON +else ifeq ($(BR2_SHARED_LIBS),y) +MBEDTLS3_CONF_OPTS += \ + -DUSE_SHARED_MBEDTLS_LIBRARY=ON -DUSE_STATIC_MBEDTLS_LIBRARY=OFF +endif + +define MBEDTLS3_DISABLE_ASM + $(SED) '/^#define MBEDTLS_AESNI_C/d' \ + $(@D)/include/mbedtls/mbedtls_config.h + $(SED) '/^#define MBEDTLS_HAVE_ASM/d' \ + $(@D)/include/mbedtls/mbedtls_config.h + $(SED) '/^#define MBEDTLS_PADLOCK_C/d' \ + $(@D)/include/mbedtls/mbedtls_config.h +endef + +# ARM in thumb mode breaks debugging with asm optimizations +# Microblaze asm optimizations are broken in general +# MIPS R6 asm is not yet supported +ifeq ($(BR2_ENABLE_DEBUG)$(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_ARM_INSTRUCTIONS_THUMB2),yy) +MBEDTLS3_POST_CONFIGURE_HOOKS += MBEDTLS3_DISABLE_ASM +else ifeq ($(BR2_microblaze)$(BR2_MIPS_CPU_MIPS32R6)$(BR2_MIPS_CPU_MIPS64R6),y) +MBEDTLS3_POST_CONFIGURE_HOOKS += MBEDTLS3_DISABLE_ASM +endif + +$(eval $(cmake-package))
mbedtls 3.x is incompatible with mbedtls 2.x: https://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guide.md mbedtls3 was created from mbedtls package with the following changes: - license file is now LICENSE - zlib compression is not available anymore - config.h renamed to mbedtls_config.h Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> --- DEVELOPERS | 1 + package/Config.in | 1 + package/mbedtls3/Config.in | 21 ++++++++++++ package/mbedtls3/mbedtls3.hash | 4 +++ package/mbedtls3/mbedtls3.mk | 61 ++++++++++++++++++++++++++++++++++ 5 files changed, 88 insertions(+) create mode 100644 package/mbedtls3/Config.in create mode 100644 package/mbedtls3/mbedtls3.hash create mode 100644 package/mbedtls3/mbedtls3.mk