From: Baruch Siach via buildroot <buildroot@buildroot.org>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: buildroot@buildroot.org, Nicola Di Lieto <nicola.dilieto@gmail.com>
Subject: Re: [Buildroot] [PATCHv4] package/uacme: requires TLS support in libcurl
Date: Mon, 18 Jul 2022 06:38:54 +0300 [thread overview]
Message-ID: <87edyjxdkm.fsf@tarshish> (raw)
In-Reply-To: <20220717201831.GY2249625@scaer>
Hi Yann,
On Sun, Jul 17 2022, Yann E. MORIN wrote:
> On 2022-07-17 22:41 +0300, Baruch Siach via buildroot spake thusly:
>> On Sun, Jul 17 2022, Yann E. MORIN wrote:
>> > From: Baruch Siach <baruch@tkos.co.il>
>> >
>> > uacme configure script fails when libcurl does not support TLS. This
>> > means that BR2_PACKAGE_LIBCURL_TLS_NONE is incompatible with uacme.
>> >
>> > Add a kconfig knob to libcurl so that no_TLS is not an option. Select
>> > that from uacme.
>> Looks much more elegant. Thanks.
>
> Cool! If you prefer my patch, I'll let you mark yours as superseded in
> patchwork, then. Otherwise, I'll let another maintainer pick their
> preferred one. :-)
>
> [--SNIP--]
>> > +# Packages must select that if they require a SSL/TLS-enabled libcurl
>> Said package must also select one of the crypto back ends that libcurl
>> supports.
>
> Absolutely valid point.
>
>> This part is somewhat fragile as libcurl might remove support
>> for any given back end like it recently did for NSS.
>
> I guess openssl will always be a safe default, as it has no architecture
> dependency. However, that would need further change in libcurl, such as:
>
> @@ -47,10 +47,11 @@ config BR2_PACKAGE_LIBCURL_EXTRA_PROTOCOLS_FEATURES
>
> choice
> prompt "SSL/TLS library to use"
> + default BR2_PACKAGE_LIBCURL_TLS_NONE
>
> config BR2_PACKAGE_LIBCURL_OPENSSL
> bool "OpenSSL"
> - depends on BR2_PACKAGE_OPENSSL
> + select BR2_PACKAGE_OPENSSL
> select BR2_PACKAGE_LIBOPENSSL_ENABLE_DES if BR2_PACKAGE_LIBOPENSSL
>
> config BR2_PACKAGE_LIBCURL_BEARSSL
>
> which changes the way we handle crypto backends...
Maybe, if we go down this path of 'depends -> select' for all other
libcurl crypto backends, we can solve the original uacme problem with a
simple !BR2_PACKAGE_LIBCURL_TLS_NONE dependency without recursion. Is
that correct?
But I'm not sure what can of recursion worms that would open.
I only meant to say that the comment above should mention that the
package must select a crypto backend. uacme is a special case and it
already selects a crypto backend. BR2_PACKAGE_LIBCURL_FORCE_SSL_TLS use
is unlikely to become very common in the foreseeable future. So I don't
think we need to optimize of this corner case.
> Maybe just not default the choice to BR2_PACKAGE_LIBCURL_TLS_NONE...
> After all, we want to promote best practices, and enabled TLS in libcurl
> is better than not enabling it... Meh...
I think this is too heavy handed. TLS takes much more than a crypto
backend after all. It should be an explicit user choice. And if we do
default to crypto enabled, then a more lightweight option is probably
better.
>
> Not sure what's the best, and it is starting to become more complex than
> my quickly whipped-up patch...
>
>> > +config BR2_PACKAGE_LIBCURL_FORCE_SSL_TLS
>> [Bikeshed] Why not just BR2_PACKAGE_LIBCURL_FORCE_TLS ?
>
> The prompt of the choice is "SSL/TLS library to use" so I reflected that
> in the symbol name, although I do agree that SSL is something we should
> definitely forget about! :-)
>
> If you feel so-inclined, you can grab this patch and adapt it to ensure
> a crypto backend is always enabled. Otherwise, I'll try to see what I
> can o a bit later...
I'm fine with the patch as is.
baruch
> Thanks for the quick feedback! :-)
>
> Regards,
> Yann E. MORIN.
>
>> baruch
>>
>> > + bool
>> > +
>> > choice
>> > prompt "SSL/TLS library to use"
>> >
>> > @@ -77,6 +81,7 @@ comment "WolfSSL needs a toolchain w/ dynamic library"
>> >
>> > config BR2_PACKAGE_LIBCURL_TLS_NONE
>> > bool "None"
>> > + depends on !BR2_PACKAGE_LIBCURL_FORCE_SSL_TLS
>> >
>> > endchoice
>> >
>> > diff --git a/package/uacme/Config.in b/package/uacme/Config.in
>> > index 58b7c534e7..1458e74d28 100644
>> > --- a/package/uacme/Config.in
>> > +++ b/package/uacme/Config.in
>> > @@ -3,6 +3,7 @@ config BR2_PACKAGE_UACME
>> > depends on BR2_USE_MMU # fork()
>> > select BR2_PACKAGE_OPENSSL if !(BR2_PACKAGE_GNUTLS || BR2_PACKAGE_MBEDTLS)
>> > select BR2_PACKAGE_LIBCURL
>> > + select BR2_PACKAGE_LIBCURL_FORCE_SSL_TLS
>> > help
>> > uacme is a client for the ACMEv2 protocol described in
>> > RFC8555, written in plain C with minimal dependencies
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-07-18 4:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-17 19:37 [Buildroot] [PATCHv4] package/uacme: requires TLS support in libcurl Yann E. MORIN
2022-07-17 19:41 ` Baruch Siach via buildroot
2022-07-17 20:18 ` Yann E. MORIN
2022-07-18 3:38 ` Baruch Siach via buildroot [this message]
2022-07-18 20:29 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87edyjxdkm.fsf@tarshish \
--to=buildroot@buildroot.org \
--cc=baruch@tkos.co.il \
--cc=nicola.dilieto@gmail.com \
--cc=yann.morin.1998@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.