aboutsummaryrefslogtreecommitdiffstats
path: root/package/libs/wolfssl/Config.in
Commit message (Collapse)AuthorAgeFilesLines
* wolfssl: fix Config.in typoTony Butler2022-11-271-1/+1
| | | | | | Fix simple typo `/crytpo/crypto/` in a description string Signed-off-by: Tony Butler <spudz76@gmail.com>
* wolfssl: prefer regular libwolfssl over cpu-cryptoEneas U de Queiroz2022-09-251-2/+2
| | | | | | | | | | | | | | | | | Rename libwolfssl-cpu-crypto to libwolfsslcpu-crypto so that the regular libwolfssl version comes first when running: opkg install libwolfssl Normally, if the package name matches the opkg parameter, that package is preferred. However, for libraries, the ABI version string is appended to the package official name, and the short name won't match. Failing a name match, the candidate packages are sorted in alphabetical order, and a dash will come before any number. So in order to prefer the original library, the dash should be removed from the alternative library. Fixes: c3e7d86d2b (wolfssl: add libwolfssl-cpu-crypto package) Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: add libwolfssl-cpu-crypto packageEneas U de Queiroz2022-09-161-35/+28
| | | | | | | | | | | | | | libwolfssl-cpu-crypto is a variant of libwolfssl with support for cryptographic CPU instructions on x86_64 and aarch64. On aarch64, wolfSSL does not perform run-time detection, so the library will crash when the AES functions are called. A preinst script attempts to check for support by querying /proc/cpuinfo, if installed in a running system. When building an image, the script will check the DISTRIB_TARGET value in /etc/openwrt_release, and will abort installation if target is bcm27xx. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: make shared againJo-Philipp Wich2022-07-301-1/+0
| | | | | | | | | | | | | | Disable the usage of target specific CPU crypto instructions by default to allow the package being shared again. Since WolfSSL does not offer a stable ABI or a long term support version suitable for OpenWrt release timeframes, we're forced to frequently update it which is greatly complicated by the package being nonshared. People who want or need CPU crypto instruction support can enable it in menuconfig while building custom images for the few platforms that support them. Signed-off-by: Jo-Philipp Wich <jo@mein.io>
* wolfssl: Do not activate HW acceleration on armvirt by defaultHauke Mehrtens2022-07-201-1/+1
| | | | | | | | | | | | | The armvirt target is also used to run OpenWrt in lxc on other targets like a Raspberry Pi. If we set WOLFSSL_HAS_CPU_CRYPTO by default the wolfssl binray is only working when the CPU supports the hardware crypto extension. Some targets like the Raspberry Pi do not support the ARM CPU crypto extension, compile wolfssl without it by default. It is still possible to activate it in custom builds. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* wolfssl: re-enable AES-NI by default for x86_64Eneas U de Queiroz2022-07-081-6/+1
| | | | | | | | | | Apply an upstream patch that removes unnecessary CFLAGs, avoiding generation of incompatible code. Commit 0bd536723303ccd178e289690d073740c928bb34 is reverted so the accelerated version builds by default on x86_64. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: WOLFSSL_HAS_WPAS requires WOLFSSL_HAS_DHPascal Ernster2022-07-061-0/+1
| | | | | | | | | Without this, WOLFSSL_HAS_DH can be disabled even if WOLFSSL_HAS_WPAS is enabled, resulting in an "Anonymous suite requires DH" error when trying to compile wolfssl. Signed-off-by: Pascal Ernster <git@hardfalcon.net> Reviewed-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: add config flag for Curve448Joel Low2022-07-031-0/+3
| | | | | | | | | | | | | This enables building WolfSSL with Curve448, which can be used by Strongswan. This has been tested on a Linksys E8450, running OpenWrt 22.03-rc4. This allows parity with OpenSSL, which already supports Curve448 in OpenWrt 21.02. Fixes openwrt/packages#18812. Signed-off-by: Joel Low <joel@joelsplace.sg>
* wolfssl: disable AES-NI by default for x86_64Eneas U de Queiroz2022-06-271-1/+6
| | | | | | | | | | | | WolfSSL is crashing with an illegal opcode in some x86_64 CPUs that have AES instructions but lack other extensions that are used by WolfSSL when AES-NI is enabled. Disable the option by default for now until the issue is properly fixed. People can enable them in a custom build if they are sure it will work for them. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: make WOLFSSL_HAS_OPENVPN default to yEneas U de Queiroz2022-06-091-1/+1
| | | | | | | | | | | | | Openvpn forces CONFIG_WOLFSSL_HAS_OPENVPN=y. When the phase1 bots build the now non-shared package, openvpn will not be selected, and WolfSSL will be built without it. Then phase2 bots have CONFIG_ALL=y, which will select openvpn and force CONFIG_WOLFSSL_HAS_OPENVPN=y. This changes the version hash, causing dependency failures, as shared packages expect the phase2 hash. Fixes: #9738 Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: enable CPU crypto instructionsEneas U de Queiroz2022-06-071-0/+12
| | | | | | | | | | | | | | | | | | This enables AES & SHA CPU instructions for compatible armv8, and x86_64 architectures. Add this to the hardware acceleration choice, since they can't be enabled at the same time. The package was marked non-shared, since the arm CPUs may or may not have crypto extensions enabled based on licensing; bcm27xx does not enable them. There is no run-time detection of this for arm. NOTE: Should this be backported to a release branch, it must be done shortly before a new minor release, because the change to nonshared will remove libwolfssl from the shared packages, but the nonshared are only built in a subsequent release! Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* libs/wolfssl: add SAN (Subject Alternative Name) supportSergey V. Lobanov2021-12-291-0/+4
| | | | | | | | | x509v3 SAN extension is required to generate a certificate compatible with chromium-based web browsers (version >58) It can be disabled via unsetting CONFIG_WOLFSSL_ALT_NAMES Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
* wolfssl: enable ECC Curve 25519 by defaultStan Grishin2021-10-241-1/+1
| | | | | | | * fixes https://github.com/openwrt/packages/issues/16652 see https://github.com/openwrt/packages/issues/16674#issuecomment-934983898 Signed-off-by: Stan Grishin <stangri@melmac.net>
* wolfssl: add support for OpenVPNIvan Pavlov2021-05-231-0/+4
| | | | | | | | | | Support for wolfSSL has been upstreamed to the master OpenVPN branch in f6dca235ae560597a0763f0c98fcc9130b80ccf4, so we can use wolfSSL directly in OpenVPN. So no more needed differnt SSL engine for OpenVPN in systems based on wolfSSL library Compiled && tested on ramips/mt7620, ramips/mt7621 Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
* wolfssl: fix Ed25519 typo in config promptChristian Lamparter2021-02-201-1/+1
| | | | Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* wolfssl: add certgen config optionPaul Spooren2020-08-311-0/+4
| | | | | | The option allows to generate certificates. Signed-off-by: Paul Spooren <mail@aparcar.org>
* wolfssl: allow building with hw-crytpo and AES-CCMEneas U de Queiroz2019-09-201-19/+18
| | | | | | | | Hardware acceleration was disabled when AES-CCM was selected as a workaround for a build failure. This applies a couple of upstream patches fixing this. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: bump to 4.1.0-stableEneas U de Queiroz2019-08-171-9/+5
| | | | | | | | | | | | | | | | | Always build AES-GCM support. Unnecessary patches were removed. This includes two vulnerability fixes: CVE-2019-11873: a potential buffer overflow case with the TLSv1.3 PSK extension parsing. CVE-2019-13628 (currently assigned-only): potential leak of nonce sizes when performing ECDSA signing operations. The leak is considered to be difficult to exploit but it could potentially be used maliciously to perform a lattice based timing attack. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: update to 4.0.0-stableEneas U de Queiroz2019-07-071-15/+36
| | | | | | | | | | | | | | | Removed options that can't be turned off because we're building with --enable-stunnel, some of which affect hostapd's Config.in. Adjusted the title of OCSP option, as OCSP itself can't be turned off, only the stapling part is selectable. Mark options turned on when wpad support is selected. Add building options for TLS 1.0, and TLS 1.3. Add hardware crypto support, which due to a bug, only works when CCM support is turned off. Reorganized option conditionals in Makefile. Add Eneas U de Queiroz as maintainer. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: update to 3.15.7, fix MakefileEneas U de Queiroz2019-07-071-1/+1
| | | | | | | | | This includes a fix for a medium-level potential cache attack with a variant of Bleichenbacher’s attack. Patches were refreshed. Increased FP_MAX_BITS to allow 4096-bit RSA keys. Fixed poly1305 build option, and some Makefile updates. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
* wolfssl: change defaults to cover wpa_supplicant needsDaniel Golle2018-05-311-9/+9
| | | | | | | | | | | | | Implicetely selecting the required options via Kconfig snippet from hostapd worked fine in local builds when using menuconfig but confused the buildbots which (in phase1) may build wpad-mini and hence already come with CONFIG_WPA_WOLFSSL being defined as unset which then won't trigger changing the defaults of wolfssl. Work around by explicitely reflecting wpa_supplicant's needs in wolfssl's default settings to make buildbots happy. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* wolfssl: fix options and add support for wpa_supplicant featuresDaniel Golle2018-05-021-0/+12
| | | | | | | | Some options' default values have been changed upstream, others were accidentally inverted (CONFIG_WOLFSSL_HAS_DES3). Also add options needed to build hostapd/wpa_supplicant against wolfssl. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* cyassl,curl,libustream-ssl: rename every `cyassl` to `wolfssl`Alexandru Ardelean2017-09-171-0/+48
This is to eliminate any ambiguity about the cyassl/wolfssl lib. The rename happened some time ago (~3+ years). As time goes by, people will start to forget cyassl and start to get confused about the wolfSSL vs cyassl thing. It's a good idea to keep up with the times (moving forward). Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-04 05:17:09 +0000