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);
No comments:
Post a Comment