On 2020/11/25 14:19, Aisha Tammy wrote: > 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?
Not if it works. Since the only thing using usockets/uwebsockets in ports at the moment is purritobin it doesn't much matter anyway, but if it was more common then by switching it to linking against OpenSSL would mean that ports using usockets could not be linked to other libraries that pull in libssl/libcrypto (for example most database client libraries) as they would conflict. Switching a build to OpenSSL is really only for special cases where a port really needs something that LibreSSL doesn't/won't support and usually only desirable for 'leaf' ports. Currently only done for nrpe, nsca-ng and sslscan which have particular reasons. > There doesn't seem to be an immediate need but yea... I have no clue > what internal shenanigans happen in OpenSSL vs LibreSSL. Library users shouldn't rely on internals anyway, just use the published API. OpenSSL has some APIs that LibreSSL doesn't - if usockets starts to use one of these then either look at whether the usockets feature requiring it is necessary, maybe it can be disabled in usockets, whether it might make sense to add to libressl, or to stick with an older version of usockets.
