All of 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 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.