| Message ID | 1513098237-18245-1-git-send-email-sergio.prado@e-labworks.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | wolfssl: new package | expand |
Hi Sergio, On Tue, Dec 12, 2017 at 03:03:57PM -0200, Sergio Prado wrote: > The wolfSSL embedded SSL library is a lightweight and portable > SSL/TLS library. > > Tested on Beaglebone Black. How have you tested this library? > Build-tested with test-pkg script. > > Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com> > --- > DEVELOPERS | 1 + > package/Config.in | 1 + > package/wolfssl/Config.in | 9 +++++++++ > package/wolfssl/wolfssl.hash | 6 ++++++ > package/wolfssl/wolfssl.mk | 44 ++++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 61 insertions(+) > create mode 100644 package/wolfssl/Config.in > create mode 100644 package/wolfssl/wolfssl.hash > create mode 100644 package/wolfssl/wolfssl.mk > > diff --git a/DEVELOPERS b/DEVELOPERS > index 77e3344fa4dc..54ba8ceb2a64 100644 > --- a/DEVELOPERS > +++ b/DEVELOPERS > @@ -1541,6 +1541,7 @@ F: package/mongodb/ > F: package/stella/ > F: package/tunctl/ > F: package/ubus/ > +F: package/wolfssl/ > > N: Simon Dawson <spdawson@gmail.com> > F: boot/at91bootstrap3/ > diff --git a/package/Config.in b/package/Config.in > index cb2141b8f3c8..1455ca6ddc1a 100644 > --- a/package/Config.in > +++ b/package/Config.in > @@ -1046,6 +1046,7 @@ menu "Crypto" > source "package/tinydtls/Config.in" > source "package/trousers/Config.in" > source "package/ustream-ssl/Config.in" > + source "package/wolfssl/Config.in" > endmenu > > menu "Database" > diff --git a/package/wolfssl/Config.in b/package/wolfssl/Config.in > new file mode 100644 > index 000000000000..3c62db13c57b > --- /dev/null > +++ b/package/wolfssl/Config.in > @@ -0,0 +1,9 @@ > +config BR2_PACKAGE_WOLFSSL > + bool "wolfssl" > + help > + The wolfSSL embedded SSL library (formerly CyaSSL) is a > + lightweight, portable, C-language-based SSL/TLS library > + targeted at IoT, embedded, and RTOS environments primarily > + because of its size, speed, and feature set. > + > + https://www.wolfssl.com/ > diff --git a/package/wolfssl/wolfssl.hash b/package/wolfssl/wolfssl.hash > new file mode 100644 > index 000000000000..26534038f62d > --- /dev/null > +++ b/package/wolfssl/wolfssl.hash > @@ -0,0 +1,6 @@ > +# Locally computed: > +sha256 0e0750705ceb0b42d83e609a1c35c3203734af50a92b15e2706bc06a6e50a439 v3.12.2-stable.tar.gz > + > +# Hash for license files: > +sha256 8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643 COPYING > +sha256 74adaaef40b96c71378b6daa3feb8ccd4a1bfd9b76debf3f3f29cf3a0e86c9a0 LICENSING > diff --git a/package/wolfssl/wolfssl.mk b/package/wolfssl/wolfssl.mk > new file mode 100644 > index 000000000000..9f3362bf6a42 > --- /dev/null > +++ b/package/wolfssl/wolfssl.mk > @@ -0,0 +1,44 @@ > +################################################################################ > +# > +# wolfssl > +# > +################################################################################ > + > +WOLFSSL_VERSION = 3.12.2 > +WOLFSSL_SITE = https://github.com/wolfSSL/wolfssl/archive > +WOLFSSL_SOURCE = v$(WOLFSSL_VERSION)-stable.tar.gz > + > +WOLFSSL_LICENSE = GPL-2.0 > +WOLFSSL_LICENSE_FILES = COPYING LICENSING > + > +WOLFSSL_DEPENDENCIES = host-pkgconf > + > +WOLFSSL_AUTORECONF = YES Please add a comment explaining with autoreconf is needed. > +WOLFSSL_CONF_OPTS += --disable-examples > + > +ifeq ($(BR2_PACKAGE_NGINX),y) > +WOLFSSL_CONF_OPTS += --enable-nginx > +else > +WOLFSSL_CONF_OPTS += --disable-nginx > +endif > + > +ifeq ($(BR2_PACKAGE_LIGHTTPD),y) > +WOLFSSL_CONF_OPTS += --enable-lighty > +else > +WOLFSSL_CONF_OPTS += --disable-lighty > +endif > + > +ifeq ($(BR2_PACKAGE_WPA_SUPPLICANT),y) > +WOLFSSL_CONF_OPTS += --enable-wpas --enable-sha512 > +else > +WOLFSSL_CONF_OPTS += --disable-wpas > +endif This is strange. Usually a package using SSL/TLS library needs to be aware of the library, not the other way around. Can you explain what is the effect of these configure options? baruch > +ifeq ($(BR2_ARM_CPU_ARMV8A),y) > +WOLFSSL_CONF_OPTS += --enable-armasm > +else > +WOLFSSL_CONF_OPTS += --disable-armasm > +endif > + > +$(eval $(autotools-package))
Hi Baruch, > On Tue, Dec 12, 2017 at 03:03:57PM -0200, Sergio Prado wrote: > > The wolfSSL embedded SSL library is a lightweight and portable > > SSL/TLS library. > > > > Tested on Beaglebone Black. > > How have you tested this library? I have used a tool called testsuite that comes with wolfssl source code inside the testsuite/ directory. To build it, you have to pass --enable-examples in the configure, and then manually copy the binary to the rootfs. Also, to use this tool, you will probably need to copy the certs/* directory to the rootfs. > > +WOLFSSL_AUTORECONF = YES > > Please add a comment explaining with autoreconf is needed. OK, I will. > > +WOLFSSL_CONF_OPTS += --disable-examples > > + > > +ifeq ($(BR2_PACKAGE_NGINX),y) > > +WOLFSSL_CONF_OPTS += --enable-nginx > > +else > > +WOLFSSL_CONF_OPTS += --disable-nginx > > +endif > > + > > +ifeq ($(BR2_PACKAGE_LIGHTTPD),y) > > +WOLFSSL_CONF_OPTS += --enable-lighty > > +else > > +WOLFSSL_CONF_OPTS += --disable-lighty > > +endif > > + > > +ifeq ($(BR2_PACKAGE_WPA_SUPPLICANT),y) > > +WOLFSSL_CONF_OPTS += --enable-wpas --enable-sha512 > > +else > > +WOLFSSL_CONF_OPTS += --disable-wpas > > +endif > > This is strange. Usually a package using SSL/TLS library needs to be aware of > the library, not the other way around. Can you explain what is the effect of > these configure options? It depends on the option, but in general enables some extra library features that could be used by the specific application. For example, if you pass --enable-nginx, it will define OPENSSL_EXTRA that will enable the wolfSSL OpenSSL compatibility layer to ease porting wolfSSL into existing applications which had been designed to work with OpenSSL. Best regards, Sergio Prado Embedded Labworks <div dir="ltr">Hi Baruch,<br><br>> On Tue, Dec 12, 2017 at 03:03:57PM -0200, Sergio Prado wrote:<br>> > The wolfSSL embedded SSL library is a lightweight and portable<br>> > SSL/TLS library.<br>> ><br>> > Tested on Beaglebone Black.<br>><br>> How have you tested this library?<br><br>I have used a tool called testsuite that comes with wolfssl source code inside the testsuite/ directory. To build it, you have to pass --enable-examples in the configure, and then manually copy the binary to the rootfs. Also, to use this tool, you will probably need to copy the certs/* directory to the rootfs.<br><br>> > +WOLFSSL_AUTORECONF = YES<br>><br>> Please add a comment explaining with autoreconf is needed.<br><br>OK, I will.<br><br>> > +WOLFSSL_CONF_OPTS += --disable-examples<br>> > +<br>> > +ifeq ($(BR2_PACKAGE_NGINX),y)<br>> > +WOLFSSL_CONF_OPTS += --enable-nginx<br>> > +else<br>> > +WOLFSSL_CONF_OPTS += --disable-nginx<br>> > +endif<br>> > +<br>> > +ifeq ($(BR2_PACKAGE_LIGHTTPD),y)<br>> > +WOLFSSL_CONF_OPTS += --enable-lighty<br>> > +else<br>> > +WOLFSSL_CONF_OPTS += --disable-lighty<br>> > +endif<br>> > +<br>> > +ifeq ($(BR2_PACKAGE_WPA_SUPPLICANT),y)<br>> > +WOLFSSL_CONF_OPTS += --enable-wpas --enable-sha512<br>> > +else<br>> > +WOLFSSL_CONF_OPTS += --disable-wpas<br>> > +endif<br>><br>> This is strange. Usually a package using SSL/TLS library needs to be aware of<br>> the library, not the other way around. Can you explain what is the effect of<br>> these configure options?<br><br>It depends on the option, but in general enables some extra library features that could be used by the specific application.<div><br></div><div>For example, if you pass --enable-nginx, it will define OPENSSL_EXTRA that will enable the wolfSSL OpenSSL compatibility layer to ease porting wolfSSL into existing applications which had been designed to work with OpenSSL. </div><div><br></div><div>Best regards,</div><div><br></div><div>Sergio Prado</div><div>Embedded Labworks</div></div>
Hi Sergio, On Tue, Dec 12, 2017 at 05:58:18PM -0200, Sergio Prado wrote: > > On Tue, Dec 12, 2017 at 03:03:57PM -0200, Sergio Prado wrote: > > > The wolfSSL embedded SSL library is a lightweight and portable > > > SSL/TLS library. > > > > > > Tested on Beaglebone Black. > > > > How have you tested this library? > > I have used a tool called testsuite that comes with wolfssl source code > inside the testsuite/ directory. To build it, you have to > pass --enable-examples in the configure, and then manually copy the binary > to the rootfs. Also, to use this tool, you will probably need to copy the > certs/* directory to the rootfs. Having this information in the commit log would be useful. > > > +WOLFSSL_AUTORECONF = YES > > > > Please add a comment explaining with autoreconf is needed. > > OK, I will. > > > > +WOLFSSL_CONF_OPTS += --disable-examples > > > + > > > +ifeq ($(BR2_PACKAGE_NGINX),y) > > > +WOLFSSL_CONF_OPTS += --enable-nginx > > > +else > > > +WOLFSSL_CONF_OPTS += --disable-nginx > > > +endif > > > + > > > +ifeq ($(BR2_PACKAGE_LIGHTTPD),y) > > > +WOLFSSL_CONF_OPTS += --enable-lighty > > > +else > > > +WOLFSSL_CONF_OPTS += --disable-lighty > > > +endif > > > + > > > +ifeq ($(BR2_PACKAGE_WPA_SUPPLICANT),y) > > > +WOLFSSL_CONF_OPTS += --enable-wpas --enable-sha512 > > > +else > > > +WOLFSSL_CONF_OPTS += --disable-wpas > > > +endif > > > > This is strange. Usually a package using SSL/TLS library needs to be > > aware of the library, not the other way around. Can you explain what is > > the effect of these configure options? > > It depends on the option, but in general enables some extra library > features that could be used by the specific application. > > For example, if you pass --enable-nginx, it will define OPENSSL_EXTRA that > will enable the wolfSSL OpenSSL compatibility layer to ease porting wolfSSL > into existing applications which had been designed to work with OpenSSL. So --enable-nginx is not nginx specific. It would probably make sense to enable it for other packages as well. What about the --enable-lighty and --enable-wpas options? How large is the target size increase of these options? In any case we need a comment that explains all that. baruch
Hello, On Wed, 13 Dec 2017 08:03:08 +0200, Baruch Siach wrote: > > It depends on the option, but in general enables some extra library > > features that could be used by the specific application. > > > > For example, if you pass --enable-nginx, it will define OPENSSL_EXTRA that > > will enable the wolfSSL OpenSSL compatibility layer to ease porting wolfSSL > > into existing applications which had been designed to work with OpenSSL. > > So --enable-nginx is not nginx specific. It would probably make sense to > enable it for other packages as well. What about the --enable-lighty and > --enable-wpas options? How large is the target size increase of these options? > > In any case we need a comment that explains all that. I also agree that the way it's done in the current proposal is very confusing. I looked at the patch before looking at Baruch answer and was about to make the exact same comment. In addition, enabling those features currently doesn't make much sense, because none of lighttpd, wpa_supplicant or nginx have an optional dependency on wolfssl. Thomas
Hi Baruch, > > > How have you tested this library? > > > > I have used a tool called testsuite that comes with wolfssl source code > > inside the testsuite/ directory. To build it, you have to > > pass --enable-examples in the configure, and then manually copy the binary > > to the rootfs. Also, to use this tool, you will probably need to copy the > > certs/* directory to the rootfs. > > Having this information in the commit log would be useful. Sure. I'll add it in V2. > So --enable-nginx is not nginx specific. It would probably make sense to > enable it for other packages as well. What about the --enable-lighty and > --enable-wpas options? How large is the target size increase of these options? > > In any case we need a comment that explains all that. To be more precise, if you pass --enable-nginx it will define the following macros during the build process (if I'm not missing any): -DOPENSSL_EXTRA -DSESSION_CERTS -DHAVE_ECC -DHAVE_OCSP -DHAVE_TLS_EXTENSIONS -DHAVE_CERTIFICATE_STATUS_REQUESTENABLED_CRL -DHAVE_TLS_EXTENSIONS -DHAVE_SESSION_TICKET -DHAVE_TLS_EXTENSIONS -DHAVE_SNI -DHAVE_MAX_FRAGMENT -DHAVE_TRUNCATED_HMAC -DHAVE_ALPN -DWOLFSSL_NGINX -DWOLFSSL_ALWAYS_VERIFY_CB -DWOLFSSL_ALWAYS_KEEP_SNI -DKEEP_OUR_CERT -DKEEP_PEER_CERT -DHAVE_EXT_CACHE -DHAVE_EX_DATA If you pass --enable-lighty: -DOPENSSL_EXTRA -DHAVE_LIGHTY -DHAVE_WOLFSSL_SSL_H=1 If you pass --enable-wpas: -DHAVE_SECRET_CALLBACK -DWOLFSSL_STATIC_RSA -DWOLFSSL_PUBLIC_MP -DWOLFSSL_PUBLIC_ECC_ADD_DBL -DATOMIC_USER -DHAVE_EX_DATA -DWOLFSSL_KEEP_PEER_CERT -DHAVE_EXT_CACHE -DWOLFSSL_ALWAYS_VERIFY_CB -DOPENSSL_EXTRA -DWOLFSSL_AES_DIRECT -DWOLFSSL_DER_LOAD -DWOLFSSL_SHA512 -DWOLFSSL_SHA384 -DWOLFSSL_KEY_GEN -DWOLFSSL_WPAS -DHAVE_COMP_KEY -DHAVE_ANON -DWOLFSSL_CMAC -DWOLFSSL_AES_DIRECT -DHAVE_TLS_EXTENSIONS -DHAVE_SESSION_TICKET I'm not a crypto or wolfssl expert, but as far as I understood, passing these options will enable the inclusion or change the behaviour of some crypto algorithms. And that would make nginx, lighttpd and wpa_supplicant work with wolfssl. I know that this is strange, normally an application depends on a library, and not the other way around. I also discovered looking at wolfssl forums that they keep patches to be applied in these applications, so they would work with wolfssl. And these patches are not public [1]. So, from that point of view, it does not make sense to keep these options in the package's makefile, since it is not useful with the upstream version of nginx, lighttpd and wpa_supplicant. What do you think? [1] https://www.wolfssl.com/forums/topic1015-nginx-wolfssl.html Best regards, Sergio Prado Embedded Labworks <div dir="ltr">Hi Baruch,<br><br>> > > How have you tested this library?<br>> ><br>> > I have used a tool called testsuite that comes with wolfssl source code<br>> > inside the testsuite/ directory. To build it, you have to<br>> > pass --enable-examples in the configure, and then manually copy the binary<br>> > to the rootfs. Also, to use this tool, you will probably need to copy the<br>> > certs/* directory to the rootfs.<br>><br>> Having this information in the commit log would be useful.<div><br></div><div>Sure. I'll add it in V2.</div><div><br>> So --enable-nginx is not nginx specific. It would probably make sense to<br>> enable it for other packages as well. What about the --enable-lighty and<br>> --enable-wpas options? How large is the target size increase of these options?<br>><br>> In any case we need a comment that explains all that.</div><div><br></div><div>To be more precise, if you pass --enable-nginx it will define the following macros during the build process (if I'm not missing any):<br></div><div><br></div><div>-DOPENSSL_EXTRA<br></div><div>-DSESSION_CERTS<br></div><div>-DHAVE_ECC<br></div><div>-DHAVE_OCSP<br></div><div>-DHAVE_TLS_EXTENSIONS</div><div>-DHAVE_CERTIFICATE_STATUS_<wbr>REQUESTENABLED_CRL<br></div><div>-DHAVE_TLS_EXTENSIONS</div><div>-DHAVE_SESSION_TICKET<br></div><div>-DHAVE_TLS_EXTENSIONS</div><div>-DHAVE_SNI</div><div>-DHAVE_MAX_FRAGMENT</div><div>-DHAVE_TRUNCATED_HMAC</div><div>-DHAVE_ALPN<br></div><div>-DWOLFSSL_NGINX<br></div><div>-DWOLFSSL_ALWAYS_VERIFY_CB<br></div><div>-DWOLFSSL_ALWAYS_KEEP_SNI<br></div><div>-DKEEP_OUR_CERT -DKEEP_PEER_CERT<br></div><div>-DHAVE_EXT_CACHE -DHAVE_EX_DATA<br></div><div><br></div><div>If you pass --enable-lighty:</div><div><br></div><div>-DOPENSSL_EXTRA<br></div><div>-DHAVE_LIGHTY</div><div>-DHAVE_WOLFSSL_SSL_H=1<br></div><div><br></div><div>If you pass --enable-wpas:<br></div><div><br></div><div>-DHAVE_SECRET_CALLBACK</div><div>-DWOLFSSL_STATIC_RSA<br></div><div>-DWOLFSSL_PUBLIC_MP</div><div>-DWOLFSSL_PUBLIC_ECC_ADD_DBL<br></div><div>-DATOMIC_USER</div><div>-DHAVE_EX_DATA</div><div>-DWOLFSSL_KEEP_PEER_CERT<br></div><div>-DHAVE_EXT_CACHE<br></div><div>-DWOLFSSL_ALWAYS_VERIFY_CB</div><div>-DOPENSSL_EXTRA<br></div><div>-DWOLFSSL_AES_DIRECT</div><div>-DWOLFSSL_DER_LOAD<br></div><div>-DWOLFSSL_SHA512</div><div>-DWOLFSSL_SHA384</div><div>-DWOLFSSL_KEY_GEN<br></div><div>-DWOLFSSL_WPAS<br></div><div>-DHAVE_COMP_KEY<br></div><div>-DHAVE_ANON<br></div><div>-DWOLFSSL_CMAC</div><div>-DWOLFSSL_AES_DIRECT<br></div><div>-DHAVE_TLS_EXTENSIONS</div><div>-DHAVE_SESSION_TICKET<br></div><div><br></div><div>I'm not a crypto or wolfssl expert, but as far as I understood, passing these options will enable the inclusion or change the behaviour of some crypto algorithms. And that would make nginx, lighttpd and wpa_supplicant work with wolfssl. I know that this is strange, normally an application depends on a library, and not the other way around. </div><div><br></div><div>I also discovered looking at wolfssl forums that they keep patches to be applied in these applications, so they would work with wolfssl. And these patches are not public [1].</div><div><br></div><div>So, from that point of view, it does not make sense to keep these options in the package's makefile, since it is not useful with the upstream version of nginx, lighttpd and wpa_supplicant. What do you think?</div><div><br></div><div>[1] <a href="https://www.wolfssl.com/forums/topic1015-nginx-wolfssl.html" target="_blank">https://www.wolfssl.com/<wbr>forums/topic1015-nginx-<wbr>wolfssl.html</a><br></div><div><br></div><div>Best regards,</div><div><br></div><div>Sergio Prado</div><div>Embedded Labworks</div><div><br></div></div>
Hello, On Wed, 13 Dec 2017 15:21:37 -0200, Sergio Prado wrote: > I also discovered looking at wolfssl forums that they keep patches to be > applied in these applications, so they would work with wolfssl. And these > patches are not public [1]. > > So, from that point of view, it does not make sense to keep these options > in the package's makefile, since it is not useful with the upstream version > of nginx, lighttpd and wpa_supplicant. What do you think? > > [1] https://www.wolfssl.com/forums/topic1015-nginx-wolfssl.html Indeed, of you can't build wolfssl against nginx without out of tree patches that are not even public, I don't see the point of enabling "nginx support" in wolfssl. Best regards, Thomas
Hi Thomas, Sergio, On Thu, Dec 14, 2017 at 06:43:59AM +0100, Thomas Petazzoni wrote: > On Wed, 13 Dec 2017 15:21:37 -0200, Sergio Prado wrote: > > > I also discovered looking at wolfssl forums that they keep patches to be > > applied in these applications, so they would work with wolfssl. And these > > patches are not public [1]. > > > > So, from that point of view, it does not make sense to keep these options > > in the package's makefile, since it is not useful with the upstream version > > of nginx, lighttpd and wpa_supplicant. What do you think? > > > > [1] https://www.wolfssl.com/forums/topic1015-nginx-wolfssl.html > > Indeed, of you can't build wolfssl against nginx without out of tree > patches that are not even public, I don't see the point of enabling > "nginx support" in wolfssl. While I agree with Thomas, I think that if there is a convenient way to control the wolfssl configuration then we should expose it somehow. The list of HAVE_* options indicates that many, maybe even most, users will need more than the default minimal configuration. baruch
Hi Thomas, Baruch, 2017-12-14 4:43 GMT-02:00 Baruch Siach <baruch@tkos.co.il>: > > Hi Thomas, Sergio, > > On Thu, Dec 14, 2017 at 06:43:59AM +0100, Thomas Petazzoni wrote: > > On Wed, 13 Dec 2017 15:21:37 -0200, Sergio Prado wrote: > > > > > I also discovered looking at wolfssl forums that they keep patches to be > > > applied in these applications, so they would work with wolfssl. And these > > > patches are not public [1]. > > > > > > So, from that point of view, it does not make sense to keep these options > > > in the package's makefile, since it is not useful with the upstream version > > > of nginx, lighttpd and wpa_supplicant. What do you think? > > > > > > [1] https://www.wolfssl.com/forums/topic1015-nginx-wolfssl.html > > > > Indeed, of you can't build wolfssl against nginx without out of tree > > patches that are not even public, I don't see the point of enabling > > "nginx support" in wolfssl. > > While I agree with Thomas, I think that if there is a convenient way to > control the wolfssl configuration then we should expose it somehow. The list > of HAVE_* options indicates that many, maybe even most, users will need more > than the default minimal configuration. So I see two possible options: 1. Completely remove these options. 2. Keep these options, documenting that to be useful, it needs out of tree patches that are not public and should be requested via wolfssl website contact page. I'm okay with both options, but I think option 2 is better because it will give Buildroot users the possibility to use wolfssl with nginx/lighttpd/wpa_supplicant in a way the wolfssl project intended. What do you think? Best regards, Sergio Prado Embedded Labworks https://e-labworks.com/en <div dir="ltr">Hi Thomas, Baruch,<br><br>2017-12-14 4:43 GMT-02:00 Baruch Siach <<a href="mailto:baruch@tkos.co.il">baruch@tkos.co.il</a>>:<br>><br>> Hi Thomas, Sergio,<br>><br>> On Thu, Dec 14, 2017 at 06:43:59AM +0100, Thomas Petazzoni wrote:<br>> > On Wed, 13 Dec 2017 15:21:37 -0200, Sergio Prado wrote:<br>> ><br>> > > I also discovered looking at wolfssl forums that they keep patches to be<br>> > > applied in these applications, so they would work with wolfssl. And these<br>> > > patches are not public [1].<br>> > ><br>> > > So, from that point of view, it does not make sense to keep these options<br>> > > in the package's makefile, since it is not useful with the upstream version<br>> > > of nginx, lighttpd and wpa_supplicant. What do you think?<br>> > ><br>> > > [1] <a href="https://www.wolfssl.com/forums/topic1015-nginx-wolfssl.html">https://www.wolfssl.com/forums/topic1015-nginx-wolfssl.html</a><br>> ><br>> > Indeed, of you can't build wolfssl against nginx without out of tree<br>> > patches that are not even public, I don't see the point of enabling<br>> > "nginx support" in wolfssl.<br>><br>> While I agree with Thomas, I think that if there is a convenient way to<br>> control the wolfssl configuration then we should expose it somehow. The list<br>> of HAVE_* options indicates that many, maybe even most, users will need more<br>> than the default minimal configuration.<br><br><div>So I see two possible options:</div><div><br></div><div>1. Completely remove these options.</div><div>2. Keep these options, documenting that to be useful, it needs out of tree patches that are not public and should be requested via wolfssl website contact page.</div><div><br></div><div>I'm okay with both options, but I think option 2 is better because it will give Buildroot users the possibility to use wolfssl with nginx/lighttpd/wpa_supplicant in a way the wolfssl project intended. What do you think?</div><div><br></div><div>Best regards,</div><div><br></div><div>Sergio Prado</div><div>Embedded Labworks</div><div><a href="https://e-labworks.com/en">https://e-labworks.com/en</a></div></div>
>>>>> "Sergio" == Sergio Prado <sergio.prado@e-labworks.com> writes: Hi, > So I see two possible options: > 1. Completely remove these options. > 2. Keep these options, documenting that to be useful, it needs out of tree > patches that are not public and should be requested via wolfssl website > contact page. > I'm okay with both options, but I think option 2 is better because it will > give Buildroot users the possibility to use wolfssl with > nginx/lighttpd/wpa_supplicant in a way the wolfssl project intended. What > do you think? If these options cannot be tested in upstream Buildroot then they imho shouldn't be there, so +1 for option 1.
Hello, On Thu, 14 Dec 2017 17:31:47 +0100, Peter Korsgaard wrote: > > I'm okay with both options, but I think option 2 is better because it will > > give Buildroot users the possibility to use wolfssl with > > nginx/lighttpd/wpa_supplicant in a way the wolfssl project intended. What > > do you think? > > If these options cannot be tested in upstream Buildroot then they imho > shouldn't be there, so +1 for option 1. Agreed. Thomas
Hi Peter, Sergio, On Thu, Dec 14, 2017 at 05:31:47PM +0100, Peter Korsgaard wrote: > >>>>> "Sergio" == Sergio Prado <sergio.prado@e-labworks.com> writes: > > So I see two possible options: > > > 1. Completely remove these options. > > 2. Keep these options, documenting that to be useful, it needs out of tree > > patches that are not public and should be requested via wolfssl website > > contact page. > > > I'm okay with both options, but I think option 2 is better because it will > > give Buildroot users the possibility to use wolfssl with > > nginx/lighttpd/wpa_supplicant in a way the wolfssl project intended. What > > do you think? > > If these options cannot be tested in upstream Buildroot then they imho > shouldn't be there, so +1 for option 1. I agree that these package specific options are not useful for Buildroot. But judging from the list of HAVE_* defines and configure options in wolfssl build documentation chapter[1] it looks like the default build will not be useful to many users without customization. Is there a way to expose some of this flexibility to Buildroot users without forcing them to manually edit the .mk file? baruch [1] https://www.wolfssl.com/docs/wolfssl-manual/ch2/
Hi Peter, Thomas, Baruch, 2017-12-15 6:24 GMT-02:00 Baruch Siach <baruch@tkos.co.il>: > > Hi Peter, Sergio, > > On Thu, Dec 14, 2017 at 05:31:47PM +0100, Peter Korsgaard wrote: > > >>>>> "Sergio" == Sergio Prado <sergio.prado@e-labworks.com> writes: > > > So I see two possible options: > > > > > 1. Completely remove these options. > > > 2. Keep these options, documenting that to be useful, it needs out of tree > > > patches that are not public and should be requested via wolfssl website > > > contact page. > > > > > I'm okay with both options, but I think option 2 is better because it will > > > give Buildroot users the possibility to use wolfssl with > > > nginx/lighttpd/wpa_supplicant in a way the wolfssl project intended. What > > > do you think? > > > > If these options cannot be tested in upstream Buildroot then they imho > > shouldn't be there, so +1 for option 1. > > I agree that these package specific options are not useful for Buildroot. But > judging from the list of HAVE_* defines and configure options in wolfssl build > documentation chapter[1] it looks like the default build will not be useful to > many users without customization. Is there a way to expose some of this > flexibility to Buildroot users without forcing them to manually edit the .mk > file? Most features that are enabled when we pass --enabled-nginx can be individually selected in the configure script with other options like --enable-sessioncerts and --enable-opensslextra. We could create additional menu options in Buildroot so the user could enable these features without changing the .mk file. The wolfssl configure script supports more then 150 individual --enable-* options, so we would have to selected the most common ones. What do you think about this approach? Best regards, Sergio Prado Embedded Labworks https://e-labworks.com/en > > > baruch > > [1] https://www.wolfssl.com/docs/wolfssl-manual/ch2/ > > -- > http://baruch.siach.name/blog/ ~. .~ Tk Open Systems > =}------------------------------------------------ooO--U--Ooo------------{= > - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - <div dir="ltr"><div>Hi Peter, Thomas, Baruch,</div><div><br></div><div>2017-12-15 6:24 GMT-02:00 Baruch Siach <<a href="mailto:baruch@tkos.co.il">baruch@tkos.co.il</a>>:<br></div>><br>> Hi Peter, Sergio,<br>><br>> On Thu, Dec 14, 2017 at 05:31:47PM +0100, Peter Korsgaard wrote:<br>> > >>>>> "Sergio" == Sergio Prado <<a href="mailto:sergio.prado@e-labworks.com">sergio.prado@e-labworks.com</a>> writes:<br>> > > So I see two possible options:<br>> ><br>> > > 1. Completely remove these options.<br>> > > 2. Keep these options, documenting that to be useful, it needs out of tree<br>> > > patches that are not public and should be requested via wolfssl website<br>> > > contact page.<br>> ><br>> > > I'm okay with both options, but I think option 2 is better because it will<br>> > > give Buildroot users the possibility to use wolfssl with<br>> > > nginx/lighttpd/wpa_supplicant in a way the wolfssl project intended. What<br>> > > do you think?<br>> ><br>> > If these options cannot be tested in upstream Buildroot then they imho<br>> > shouldn't be there, so +1 for option 1.<br>><br>> I agree that these package specific options are not useful for Buildroot. But<br>> judging from the list of HAVE_* defines and configure options in wolfssl build<br>> documentation chapter[1] it looks like the default build will not be useful to<br>> many users without customization. Is there a way to expose some of this<br>> flexibility to Buildroot users without forcing them to manually edit the .mk<br>> file?<br><br>Most features that are enabled when we pass --enabled-nginx can be individually selected in the configure script with other options like --enable-sessioncerts and --enable-opensslextra.<div><br></div><div>We could create additional menu options in Buildroot so the user could enable these features without changing the .mk file. The wolfssl configure script supports more then 150 individual --enable-* options, so we would have to selected the most common ones.</div><div><br></div><div>What do you think about this approach?</div><div><br></div><div>Best regards,</div><div><br></div><div>Sergio Prado</div><div>Embedded Labworks</div><div><a href="https://e-labworks.com/en">https://e-labworks.com/en</a><br><div><div> <br>><br>><br>> baruch<br>><br>> [1] <a href="https://www.wolfssl.com/docs/wolfssl-manual/ch2/">https://www.wolfssl.com/docs/wolfssl-manual/ch2/</a><br>><br>> --<br>> <a href="http://baruch.siach.name/blog/">http://baruch.siach.name/blog/</a> ~. .~ Tk Open Systems<br>> =}------------------------------------------------ooO--U--Ooo------------{=<br>> - <a href="mailto:baruch@tkos.co.il">baruch@tkos.co.il</a> - tel: +972.52.368.4656, <a href="http://www.tkos.co.il">http://www.tkos.co.il</a> -</div></div></div></div>
Hi Sergio, On Fri, Dec 15, 2017 at 08:32:31AM -0200, Sergio Prado wrote: > 2017-12-15 6:24 GMT-02:00 Baruch Siach <baruch@tkos.co.il>: > > On Thu, Dec 14, 2017 at 05:31:47PM +0100, Peter Korsgaard wrote: > > > >>>>> "Sergio" == Sergio Prado <sergio.prado@e-labworks.com> writes: > > > > So I see two possible options: > > > > > > > 1. Completely remove these options. > > > > 2. Keep these options, documenting that to be useful, it needs out > of tree > > > > patches that are not public and should be requested via wolfssl > website > > > > contact page. > > > > > > > I'm okay with both options, but I think option 2 is better because > it will > > > > give Buildroot users the possibility to use wolfssl with > > > > nginx/lighttpd/wpa_supplicant in a way the wolfssl project intended. > What > > > > do you think? > > > > > > If these options cannot be tested in upstream Buildroot then they imho > > > shouldn't be there, so +1 for option 1. > > > > I agree that these package specific options are not useful for Buildroot. > But > > judging from the list of HAVE_* defines and configure options in wolfssl > build > > documentation chapter[1] it looks like the default build will not be > useful to > > many users without customization. Is there a way to expose some of this > > flexibility to Buildroot users without forcing them to manually edit the > .mk > > file? > > Most features that are enabled when we pass --enabled-nginx can be > individually selected in the configure script with other options like > --enable-sessioncerts and --enable-opensslextra. > > We could create additional menu options in Buildroot so the user could > enable these features without changing the .mk file. The wolfssl configure > script supports more then 150 individual --enable-* options, so we would > have to selected the most common ones. > > What do you think about this approach? That is the best we can do at the moment I guess. We can have like two or three build profiles that cover what most users would need. baruch
diff --git a/DEVELOPERS b/DEVELOPERS index 77e3344fa4dc..54ba8ceb2a64 100644 --- a/DEVELOPERS +++ b/DEVELOPERS @@ -1541,6 +1541,7 @@ F: package/mongodb/ F: package/stella/ F: package/tunctl/ F: package/ubus/ +F: package/wolfssl/ N: Simon Dawson <spdawson@gmail.com> F: boot/at91bootstrap3/ diff --git a/package/Config.in b/package/Config.in index cb2141b8f3c8..1455ca6ddc1a 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1046,6 +1046,7 @@ menu "Crypto" source "package/tinydtls/Config.in" source "package/trousers/Config.in" source "package/ustream-ssl/Config.in" + source "package/wolfssl/Config.in" endmenu menu "Database" diff --git a/package/wolfssl/Config.in b/package/wolfssl/Config.in new file mode 100644 index 000000000000..3c62db13c57b --- /dev/null +++ b/package/wolfssl/Config.in @@ -0,0 +1,9 @@ +config BR2_PACKAGE_WOLFSSL + bool "wolfssl" + help + The wolfSSL embedded SSL library (formerly CyaSSL) is a + lightweight, portable, C-language-based SSL/TLS library + targeted at IoT, embedded, and RTOS environments primarily + because of its size, speed, and feature set. + + https://www.wolfssl.com/ diff --git a/package/wolfssl/wolfssl.hash b/package/wolfssl/wolfssl.hash new file mode 100644 index 000000000000..26534038f62d --- /dev/null +++ b/package/wolfssl/wolfssl.hash @@ -0,0 +1,6 @@ +# Locally computed: +sha256 0e0750705ceb0b42d83e609a1c35c3203734af50a92b15e2706bc06a6e50a439 v3.12.2-stable.tar.gz + +# Hash for license files: +sha256 8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643 COPYING +sha256 74adaaef40b96c71378b6daa3feb8ccd4a1bfd9b76debf3f3f29cf3a0e86c9a0 LICENSING diff --git a/package/wolfssl/wolfssl.mk b/package/wolfssl/wolfssl.mk new file mode 100644 index 000000000000..9f3362bf6a42 --- /dev/null +++ b/package/wolfssl/wolfssl.mk @@ -0,0 +1,44 @@ +################################################################################ +# +# wolfssl +# +################################################################################ + +WOLFSSL_VERSION = 3.12.2 +WOLFSSL_SITE = https://github.com/wolfSSL/wolfssl/archive +WOLFSSL_SOURCE = v$(WOLFSSL_VERSION)-stable.tar.gz + +WOLFSSL_LICENSE = GPL-2.0 +WOLFSSL_LICENSE_FILES = COPYING LICENSING + +WOLFSSL_DEPENDENCIES = host-pkgconf + +WOLFSSL_AUTORECONF = YES + +WOLFSSL_CONF_OPTS += --disable-examples + +ifeq ($(BR2_PACKAGE_NGINX),y) +WOLFSSL_CONF_OPTS += --enable-nginx +else +WOLFSSL_CONF_OPTS += --disable-nginx +endif + +ifeq ($(BR2_PACKAGE_LIGHTTPD),y) +WOLFSSL_CONF_OPTS += --enable-lighty +else +WOLFSSL_CONF_OPTS += --disable-lighty +endif + +ifeq ($(BR2_PACKAGE_WPA_SUPPLICANT),y) +WOLFSSL_CONF_OPTS += --enable-wpas --enable-sha512 +else +WOLFSSL_CONF_OPTS += --disable-wpas +endif + +ifeq ($(BR2_ARM_CPU_ARMV8A),y) +WOLFSSL_CONF_OPTS += --enable-armasm +else +WOLFSSL_CONF_OPTS += --disable-armasm +endif + +$(eval $(autotools-package))
The wolfSSL embedded SSL library is a lightweight and portable SSL/TLS library. Tested on Beaglebone Black. Build-tested with test-pkg script. Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com> --- DEVELOPERS | 1 + package/Config.in | 1 + package/wolfssl/Config.in | 9 +++++++++ package/wolfssl/wolfssl.hash | 6 ++++++ package/wolfssl/wolfssl.mk | 44 ++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 61 insertions(+) create mode 100644 package/wolfssl/Config.in create mode 100644 package/wolfssl/wolfssl.hash create mode 100644 package/wolfssl/wolfssl.mk