Current code uses jal ra,AES_set_encrypt_key which breaks with lld
producing a shared lib. Just use call AES_set_encrypt_key to get
a relocation that lld agrees with. Input + ok tb@ (maintainer)
Fixes build of sysutils/borgbackup/2.0 on riscv64
Remove 3.3 and 3.4 ports. This removes the need of most of the patches
since all the atrocious perlasm stuff was upstreamed. Thanks again sashan
for doing the heavy lifting.
Apart from a minor issue with accidentally trusting certs that should be
rejected, this is a bugfix release with only a ~10k lines diff of churn.
Nothing special.
https://github.com/advisories/GHSA-v8qh-5c5w-48pp
This is a holdover from the initial port of OpenSSL 1.0.1h which fabien
found to be the culprit blocking progress on some node madness. This
is a tweaked version from a patch initially provided by fabien and then
volker. No concerns raised on ports@.
In addition to adding a missing pthread in WANTLIB compared to the initial
diff, switch sparc64 to ports-gcc, which provides the proper C11 atomics,
lacking in base-gcc 4.2.1. This avoids completely broken fallback code in
OpenSSL in at least their 3.3 and 3.4 branches that would require an insane
patch fest to work around problems from a PR that was not only poorly
written, tested and reviewed as per usual, but actually did not even
compile. Fortunately - otherwise our poor sparc64 OpenSSL users would run
a version of that crap now. For one thing the diff in question added a
wonderful and unused IMPL_fallback_atomic_compare_exchange_n() with
completely bogus arguments and chose to call the already existing
IMPL_fallback_atomic_exchange_n() instead but that's far from the only two
glaring problems in these 23 lines added.
Follow the bread crumbs in https://github.com/openssl/openssl/issues/26740
if you really must know more. A quick glance at the vertically aligned
backslashes should already set off all alarm sirens of the greenest of
all green reviewers.
The quictls/openssl repo is no longer actively maintained and security
issues already start piling up, as is to be expected since it contains
most of the careless and poorly reviewed churn that happened between
OpenSSL 1.1 and now.
We can reinstate quictls once there is a release of quictls that keeps
up with the security fixes from their upstream.
https://github.com/quictls/quictls/issues/244
Going forward, there will only be two OpenSSL releases in the ports tree:
the latest stable version for testing (currently 3.4) and the penultimate
stable version (currently 3.3) for ports to consume.
Soon after the release of 3.5.0, consumers will switch to 3.4 and 3.3 will
be removed, and so on. The idea is that this way, 3.4 will have had some
time to mature and the latest round of regressions should have been found
and addressed in 3.4.1 or 3.4.2 and it should be safe enough to switch.
Thanks to sashan for doing the heavy lifting upstreaming our asm patches.
The amd64 patches were merged but tom is still slacking on the aarc64 ones.
Passes regress on amd64, sparc64 and aarch64 (on an M1, so without bti).
https://www.openssl-library.org/news/openssl-3.4-notes/
To everyone's utmost surprise, this fixes another bug introduced with punycode support (OpenSSL should really look into adopting RFC 9598).
Plus, the SSL_select_next_proto() NPN issue is finally in a release.
PS: The punycode thing was an ASAN finding, public since 2021. It was
found because someone paid attention when old issues were marked inactive.
https://github.com/openssl/openssl/issues/16717
To everyone's utmost surprise, this fixes another bug introduced with
punycode support (OpenSSL should really look into adopting RFC 9598).
Plus, the SSL_select_next_proto() NPN issue is finally in a release.
PS: The punycode thing was an ASAN finding, public since 2021. It was
found because someone paid attention when old issues were marked inactive.
https://github.com/openssl/openssl/issues/16717
tb