[Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Fabrice Fontaine]

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

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))
-- 
2.33.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/2] package/hiawatha: needs mbedtls3

[Fabrice Fontaine]

hiawatha needs mbedtls3 since bump to version 11.1 in commit
24e4c888c3d36e3943206ea55894b84344cc8b2e:

/home/giuliobenetti/autobuild/run/instance-3/output-1/build/hiawatha-11.1/src/wigwam.c:39:10: fatal error: mbedtls/psa_util.h: No such file or directory
   39 | #include "mbedtls/psa_util.h"
      |          ^~~~~~~~~~~~~~~~~~~~

Fixes:
 - http://autobuild.buildroot.org/results/064af90aa95c28781d96d7eca0f14841fce0687a

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 package/hiawatha/Config.in   | 3 ++-
 package/hiawatha/hiawatha.mk | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/package/hiawatha/Config.in b/package/hiawatha/Config.in
index 8f1908f6f4..94737bf318 100644
--- a/package/hiawatha/Config.in
+++ b/package/hiawatha/Config.in
@@ -32,6 +32,7 @@ if BR2_PACKAGE_HIAWATHA
 
 config BR2_PACKAGE_HIAWATHA_SSL
 	bool "hiawatha TLS support"
-	select BR2_PACKAGE_MBEDTLS
+	depends on !BR2_PACKAGE_MBEDTLS
+	select BR2_PACKAGE_MBEDTLS3
 
 endif
diff --git a/package/hiawatha/hiawatha.mk b/package/hiawatha/hiawatha.mk
index 5618e6900d..8f975813a5 100644
--- a/package/hiawatha/hiawatha.mk
+++ b/package/hiawatha/hiawatha.mk
@@ -21,7 +21,7 @@ HIAWATHA_CONF_OPTS = \
 
 ifeq ($(BR2_PACKAGE_HIAWATHA_SSL),y)
 HIAWATHA_CONF_OPTS += -DUSE_SYSTEM_MBEDTLS=ON
-HIAWATHA_DEPENDENCIES += mbedtls
+HIAWATHA_DEPENDENCIES += mbedtls3
 else
 HIAWATHA_CONF_OPTS += -DENABLE_TLS=OFF
 endif
-- 
2.33.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Fabrice Fontaine]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Joachim Wiberg]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Fabrice Fontaine]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Fabrice Fontaine]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Fabrice Fontaine]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Peter Korsgaard]

>>>>> "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...

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/2] package/mbedtls3: new package

[Fabrice Fontaine]

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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot