rpki-client: do not provide IPAddrBlocks_{new,free}() unconditionally
After sitting on the issue for over four years, a last-minute addition to
OpenSSL 4.1 provided a somewhat incorrect version of IPAddrBlocks_new(),
and versions of IPAddrBlocks_free() ith i2d and d2i and the ASN.1 item.
Until LibreSSL provides the corresponding functions, we need this compat
code in base. After that the rfc3779.c file can move to portable where it
really belongs.
With this the rpki-client code is ready for OpenSSL 4.1, provided it uses
a fixed version of lib(re)tls.
ok claudio
rpki-client: fix valid_uri() to work with non-strings
valid_uri() takes a length parameter and should honor that. Most uris
passed are NUL terminated, but the ones coming from an ASN1_STRING are
not guaranteed to be. Calling strstr() on a non-terminated string with
no match is a buffer overread. So use memmem() instead.
This is needed for rpki-client to work with OpenSSL 4.1, who, in their
infinite disregard for downstreams chose to stop NUL-terminating ASN.1
strings. A massive breaking change in a minor release that will surely
cause lots of buffer overreads. It's also not mentioned in CHANGES.md,
only in their terrible migration guide. Of course it's been documented
since forever, but who reads OpenSSL's crappy documentation anyway?
ok claudio
Add a test, disabled for now, that tests $ORIGIN works when a program
is executed by a search of the PATH. Additional tests are needed for
other cases. okay deraadt@
x11/qt6/qtbase: Treat realpath(3) handling like macos/android
All components of pathname must exist when realpath() is called,
so make sure "entry" (*pathname) exists before we call realpath.
mpv: don't force a dep on yt-dlp, it is perfectly usable as a player
for local files without this (which pulls in restricted-arch packages
for solving javascript challenges). update the error message when
this is not found to mention yt-dlp as well as youtube-dl to give a
better clue to users. ok tb@, other feedback lraab
Enable jumbo frames in ogx(4)ogx(4) already handles buffer chaining. Raise the MTU limit to enable
the use of jumbo frames.
Use the same maximum MTU as cnmac(4). The limit 12288 (0x3000) is
somewhat arbitrary. It could be even higher, but it is already
higher than what many other network devices are capable of.
