We should also remove 3.4, as it will become unsupported in a week (one
year after the OpenBSD 7.0 release), but some packages explicitly depend
on it, so I'm not removing it yet.
This addresses https://github.com/NixOS/nixpkgs/issues/68286
When `-R` (CA file location) is not specified, nc tries to fall back to
a default location. In 2.8 this was still configurable at compile time,
but was changed somewhere after. This replaces `/etc/ssl/cert.pem`
with `${cacert}/etc/ssl/cert.pem` in the code directly.
For a discussion of this, see https://github.com/NixOS/nixpkgs/pull/68456
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
It turns out that libcrypto had an exectuable stack, because it linked
some objects without a .note.GNU-stack section. Compilers add this
section by default, but the objects produced from .S files did not
contain it. The .S files do include a directive to add the section, but
guarded behind an #ifdef HAVE_GNU_STACK. So define HAVE_GNU_STACK, to
ensure that all objects have a .note.GNU-stack section.
For some reasons, libcrypto would be built with the executable stack
flag set. I found out about this when Nginx failed to load the shared
library, because I was running it with MemoryDenyWriteExecute=true,
which does not permit executable stacks.
I am not sure why the stack ends up executable; the other shared
libraries which are part of LibreSSL do not have this flag set. You can
verify this with 'execstack -q'. Non-executable stacks should be the
default, and from checking some other files, that does appear to be the
case. The LibreSSL sources do not contain the string "execstack", so
I am not sure what causes the default to be overridden.
Adding '-z noexecstack' to the linker flags makes the linker unset the
flag. Now my Nginx can load the library, and so far I have not run into
other issues.
Without setting BUILD_SHARED_LIBS, the package would build file, but
when linking it into acme-client or nginx, I got the following error:
libressl-2.9.1/lib/libtls.a(tls.c.o): undefined reference to symbol 'pthread_once@@GLIBC_2.2.5'
binutils-2.31.1/bin/ld: glibc-2.27/lib/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
After looking at the CMakeLists.txt in libressl/tls, I noticed the
BUILD_SHARED_LIBS option, and setting it resolves the linking error.