Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Baruch Siach via buildroot <buildroot@buildroot.org>
To: Nicola Di Lieto <nicola.dilieto@gmail.com>
Cc: buildroot@busybox.net
Subject: Re: [Buildroot] [RFC PATCH] package/uacme: requires TLS support in libcurl
Date: Wed, 13 Jul 2022 10:38:45 +0300	[thread overview]
Message-ID: <877d4he9ox.fsf@tarshish> (raw)
In-Reply-To: <Ys5vPCrxDXWvj+ok@einstein.dilieto.eu>

Hi Nicola,

On Wed, Jul 13 2022, Nicola Di Lieto wrote:
> On Wed, Jul 13, 2022 at 09:43:11AM +0300, Baruch Siach wrote:
>>This issue is already in current code. The line
>>
>>  select BR2_PACKAGE_OPENSSL if !(BR2_PACKAGE_GNUTLS || BR2_PACKAGE_MBEDTLS)
>>
>>does not guarantee that libcurl uses any of these as crypt back
>>end. libcurl might still have BR2_PACKAGE_LIBCURL_BEARSSL or
>>BR2_PACKAGE_LIBCURL_WOLFSSL set.
>
> It doesn't matter what libcurl is using, as long as it can do TLS. uacme needs
> one of OpenSSL, GnuTLS or mbedTLS and will work fine even when curl is using
> WolfSSL or BearSSL. Of course having two crypto libraries wouldn't be very
> efficient...

I see. So currently the 'select' statement is needed because uacme
itself needs one of these as a cryto back end regardless of libcurl. Is
that correct?

>>This patch only fixes the BR2_PACKAGE_LIBCURL_TLS_NONE case, but we can
>>easily add others for something like
>>
>>  depends on BR2_PACKAGE_LIBCURL && !BR2_PACKAGE_LIBCURL_TLS_NONE
>>          && !BR2_PACKAGE_LIBCURL_BEARSSL && !BR2_PACKAGE_LIBCURL_WOLFSSL
>
> That might work, as long as one of OpenSSL, GnuTLS or mbedTLS is
> selected.

One of them must be selected to satisfy libcurl need for crypto back
end. But it is not very user friendly.

>>The reason I marked this patch RFC is because we usually do not 'depend'
>>on non obvious dependencies like libcurl, but 'select' them
>>automatically to make it easier for the user. But I could not find a way
>>to avoid build failure using only 'select'.
>
> There was some discussion about this when I submitted the package:
>
> https://lists.buildroot.org/pipermail/buildroot/2019-April/551561.html
>
>>What do you think?
>
> I think your latest proposal might work but I'm not sure it complies with
> buildroot guidelines. Can someone more knowledgeable comment as well?

I hope so.

I'll try a combination of 'select' and 'depends' to see how far I get.

Thanks,
baruch

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

  reply	other threads:[~2022-07-13  7:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09 19:21 [Buildroot] [RFC PATCH] package/uacme: requires TLS support in libcurl Baruch Siach via buildroot
2022-07-13  6:38 ` Nicola Di Lieto
2022-07-13  6:43   ` Baruch Siach via buildroot
2022-07-13  7:07     ` Nicola Di Lieto
2022-07-13  7:38       ` Baruch Siach via buildroot [this message]
2022-07-13 10:02         ` Nicola Di Lieto

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=877d4he9ox.fsf@tarshish \
    --to=buildroot@buildroot.org \
    --cc=baruch@tkos.co.il \
    --cc=buildroot@busybox.net \
    --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