On 11/25/20 2:01 PM, Theo Buehler wrote: > On Wed, Nov 25, 2020 at 01:12:03PM -0500, Aisha Tammy wrote: >> On 11/25/20 12:34 PM, Stuart Henderson wrote: >>> On 2020/11/25 12:03, Aisha Tammy wrote: >>>> Hi, >>>> It has come to my attention that upstream does not support >>>> libressl and only wants to support openssl >>>> https://github.com/uNetworking/uWebSockets/issues/994 >>>> >>>> I am unsure on how to fix this port. >>>> There is no problem right now as the only consumer www/purritobin >>>> does not use the SSL functionality in 0.2.4 (the current version in tree). >>>> >>>> The new updated version www/purritobin-0.3.1 (not yet sent the diff) >>>> does use SSL functionality optionally during runtime, which will be broken >>>> if net/usockets doesn't get fixed. >>>> >>>> Can anyone help with fixing this linking? >>>> >>>> The updated version of usockets and purritobin do work correctly when >>>> linked with OpenSSL when used on linux (tested on gentoo). >>>> >>>> Thanks, >>>> Aisha >>> "LibreSSL seems to be just like most forks are; a joke." lovely. >> I know right :( >>> what is the actual breakage when trying to use it with libressl? >>> >> >> When doing a paste, with curl, using an SSL connection, the error is: > > The first thing getting in the way is unveil. You probably don't want to > have certificate and key in the storage directory. That won't be fixed > by a switch to OpenSSL: > > /* based and lit method to make sure that nothing goes wrong */ > #if defined(__OpenBSD__) > /* the only directory we need access to is the storage directory */ > int unveil_err = unveil(storage_directory.c_str(), "rwxc"); > if (unveil_err != 0) { > err(unveil_err, "Error: could not unveil storage folder: %s", > storage_directory.c_str()); > } > /* also we only need small amounts of net and socket access */ > (void)pledge("stdio rpath wpath cpath inet unix", NULL); > #endif > > The library still needs to load certificate and key correctly, which it > doesn't (the connection errors out since libssl can't load the cert), > but I haven't looked into why that is. > > https://github.com/openbsd/src/blob/master/lib/libssl/tls13_server.c#L625 > >> >> * Trying 73.215.141.174:42069... >> * Connected to epsilonknot.xyz (73.215.141.174) port 42069 (#0) >> * ALPN, offering h2 >> * ALPN, offering http/1.1 >> * successfully set certificate verify locations: >> * CAfile: /etc/ssl/certs/ca-certificates.crt >> * CApath: /etc/ssl/certs >> * TLSv1.3 (OUT), TLS handshake, Client hello (1): >> * TLSv1.3 (IN), TLS handshake, Server hello (2): >> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): >> * TLSv1.3 (IN), TLS alert, handshake failure (552): >> * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure >> * Closing connection 0 >> curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake >> failure >> >> Thanks a bunch, >> Aisha >
OMG!!!!! YOU ARE A GENIUS! It worked with commenting out the unveil :D :D :D That is amazing!! It seems I am dumb about not knowing what I write myself... Sorry about this :( Fixing up the unveil is easy enough now that I know the problem. On a side note, am curious about this not being an error during runtime. I thought wrong read access would terminate the program :O On a side side note: While this consumer is correctly working now, the upstreams horrible statement still does exist... Do we want/need to link it to OpenSSL instead? There doesn't seem to be an immediate need but yea... I have no clue what internal shenanigans happen in OpenSSL vs LibreSSL. Thanks so much, Aisha
