Package optional or choice config symbols are usually prefixed with the
package config symbol name. Rename BR2_PACKAGE_CURL to
BR2_PACKAGE_LIBCURL_CURL to conform.
Update references to the old name.
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since we already have a choice to select the backend to do crypto, push
the limits even further and add an option to do no crypto.
Usually, we would have added that option first in the choice, but if we
were to do that now, existing defconfigs that previously used openssl
(the first item in the choice) would now default to non crypto, which is
not so nice. So we add the new option last in the choice.
Each crypto backend option is used in a conditional block, each of which
default to disabling said backend. So, selecting none will indeed
disable all.
We can now drop the blind intermediate option that would hide the choice
when no backend library was available; there will now always be at least
the none option in the choice, so we need not hide it.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Julien Grossholtz <julien.grossholtz@openest.io>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Libcurl recipe allows selecting between various TLS backends. Users can
already select between several options but WolfSSL was missing. WolfSSL
is an efficient TLS library, it supports TLS 1.3 and is used in many
embedded systems.
Add WolfSSL to libcurl "SSL/TLS library to use" choice list when WolfSSL
package is enabled. When selected in the list, use libcurl
--with-wolfssl configure option. Explicitly set --without-wolfssl
when it is not selected.
Signed-off-by: Julien Grossholtz <julien.grossholtz@openest.io>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Libcurl is more than 250 KiB (libcurl) / 100 KiB (curl binary) in size.
About 50 KiB / 15 KiB of this can be saved by disabling features/protocols
that are not commonly needed:
- proxy support: 15 KiB
- cookies support: 10 KiB
- various less common protocols: 25 KiB (libcurl) + 15 KiB (curl binary)
Note that the exact amount of space saved depends on the architecture,
toolchain, and other factors.
Other packages that are selecting libcurl might require protocols from the
'extra' set. But, there is no clear way to find out which packages are in
this situation, in particular because issues may only be visible at runtime.
Note: remove the text 'enable' on the option for 'verbose strings' as that
is more common in Buildroot.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Peter: unconditionally remove the libcurl-option to generate C code]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Instead of defaulting to OpenSSL, allow selection of package to use
through a choice in libcurl's config. The default will be to select the
first enabled TLS provider in the same preference order as is used now,
i.e. no change from current behavior.
Some of the alternative libraries have advantages over OpenSSL in
certain areas.
For example, gnutls has vastly superior PKCS11 support. One can use
client TLS private keys by supplying a PKCS11 URI instead of a private
key file name. The TLS server cert trust store can be a PKCS11 URI,
e.g. configure libcurl with a ca-bundle of "pkcs11:model=p11-kit-trust".
Now server certs can be stored in a software and/or hardware HSM(s).
This doesn't work with OpenSSL.
However, some software only supports OpenSSL for TLS or other crypto
functions. So it might be necessary to enable OpenSSL for that reason.
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
[Peter: add BR2_PACKAGE_LIBCURL_TLS_SUPPORT and use it to hide choice &
comment, explitly pass --without-foo if option is not enabled,
only do .pc fixup if BR2_PACKAGE_LIBCURL_OPENSSL is enabled]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The check-package script when ran gives warnings on text wrapping
on all of these Config files. This patch cleans up all warnings
related to the text wrapping for the Config files starting with
lib in the package directory.
The appropriate indentation is: <tab><2 spaces><62 chars>
See http://nightly.buildroot.org/#writing-rules-config-in for more
information.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In the Config.in file of package foo, it often happens that there are other
symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense
when foo itself is enabled. There are two ways to express this: with
depends on BR2_PACKAGE_FOO
in each extra symbol, or with
if BR2_PACKAGE_FOO
...
endif
around the entire set of extra symbols.
The if/endif approach avoids the repetition of 'depends on' statements on
multiple symbols, so this is clearly preferred. But even when there is only
one extra symbol, if/endif is a more logical choice:
- it is future-proof for when extra symbols are added
- it allows to have just one strategy instead of two (less confusion)
This patch modifies the Config.in files accordingly.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In 9229b82d63 ('libcurl: needs MMU'),
the libcurl package was disabled on non-MMU systems, due to the usage
of the fork() function in the library.
However, a deeper inspection reveals that fork() is only used in the
implementation of NTLM, an obscure, undocumented, Microsoft specific
authentication method that apparently isn't common anymore. See
http://curl.haxx.se/docs/manpage.html#--ntlm.
Therefore, this commit re-enables libcurl on non-MMU systems by
explicitly disabling the NTLM support. If someone ever needs NTLM
support in Buildroot's libcurl package, it will always be time to add
a libcurl sub-option to enable it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
