On 11/25/20 2:48 PM, Theo Buehler wrote: > On Wed, Nov 25, 2020 at 02:19:38PM -0500, Aisha Tammy wrote: >> 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!! > > Oh, great. So I messed up my testing when it didn't load the cert for > me...:) > >> It seems I am dumb about not knowing what I write myself... >> Sorry about this :( > > No worries. This happens to all of us :) > > I ran a test instance under ktrace. > > ktrace -di ./purrito -l -d localhost -s /tmp/purritobin/ -k > /tmp/localhost.key -c /tmp/localhost.crt -n localhost > > Then looking at the output of kdump showed that opening > /tmp/localhost.key gave ENOENT. The reason for this was then rather > obvious. > >> Fixing up the unveil is easy enough now that I know the problem. > > Indeed. > >> On a side note, am curious about this not being an error during runtime. >> I thought wrong read access would terminate the program :O > > Only pledge aborts. As mentioned above, unveil gives ENOENT on access of > hidden files. I'm not entirely sure why the server lib doesn't give a > meaningful error, though. It should... > >> 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? > > I don't think so. From a quick glance, usockets doesn't seem to do > anything particularly fancy libssl-wise. We use OpenSSL in ports only if > there really is no other way (missing API, or occasionally due to major > breakage). This should not happen with a relatively simple webserver. > Gotcha, that makes sense . Thanks for glancing over :)
>> There doesn't seem to be an immediate need but yea... I have no clue >> what internal shenanigans happen in OpenSSL vs LibreSSL. > > We strive to be a drop-in replacement as far as possible and reasonable. > Things certainly are a far cry from perfect for everyone needing to deal > with this. However, very commonly used things should work mostly the > same way. > > (My work on OpenBSD has been mainly in LibreSSL in the last few years, > so I'm somewhat biased). > And thanks for all the cool work on libressl XD. >> >> Thanks so much, >> Aisha >> Will send out the diffs for all three ports soon. Thanks a bunch, Aisha
