From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Baruch Siach <baruch@tkos.co.il>
Cc: Nicola Di Lieto <nicola.dilieto@gmail.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCHv4] package/uacme: requires TLS support in libcurl
Date: Mon, 18 Jul 2022 22:29:44 +0200 [thread overview]
Message-ID: <20220718202944.GE2249625@scaer> (raw)
In-Reply-To: <87edyjxdkm.fsf@tarshish>
Baruch, All,
On 2022-07-18 06:38 +0300, Baruch Siach via buildroot spake thusly:
> On Sun, Jul 17 2022, Yann E. MORIN wrote:
> > On 2022-07-17 22:41 +0300, Baruch Siach via buildroot spake thusly:
[--SNIP--]
> >> 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:
[--SNIP--]
> 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?
Probably. I was wondering why the current choice was using depends on
rathwer than select, as that would have been the most logical solution,
but the commit message does not explain it.
Probably this was done to avoid propagating all the reverse
dependencies...
> But I'm not sure what can of recursion worms that would open.
I was also wondering the same...
> I only meant to say that the comment above should mention that the
> package must select a crypto backend.
Yes, this could also do the trick, but it is not nice that a pakcage
that does not have to use crypto for itself be in charge of selecting a
crypto backend for libcurl... This does not look nice.
> uacme is a special case and it
> already selects a crypto backend.
Yes, and I indeed leverage that condition to introduce _FORCE_SSL_TLS
> 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.
Valid.
[--SNIP--]
> > 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.
Ok, thanks for the feedback! :-)
I'll send an updated patch that tweaks the comment to also note that a
crupto backend needs to be selected.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
prev parent reply other threads:[~2022-07-18 20:29 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
2022-07-18 20:29 ` Yann E. MORIN [this message]
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=20220718202944.GE2249625@scaer \
--to=yann.morin.1998@free.fr \
--cc=baruch@tkos.co.il \
--cc=buildroot@buildroot.org \
--cc=nicola.dilieto@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox