rpki-client: explain why we do what we do in ta_check_pubkey()
The base64-encoded SPKI blob in the TAL should really be matched against
the corresponding part of the cert's DER. Unfortunately, libcrypto only
stores internal representations in the X509's cert_info field, so what it
hands back via the X509_* and X509_PUBKEY_* API is at best re-encoded and
therefore unsuitable for this purpose. Document this so when I will have
forgotten this the day after tomorrow, I still have a chance of not wasting
as much time for a third or fourth time next time I revisit this.
ok claudio
rpki-client: rename ta_parse() to ta_validate() and document it
ta_parse() only parses the TAL's SPKI, so it is misnamed. What it really
does is it compares the TA's SPKI to the TAL's SPKI and checks that it is
a curently valid, self-signed cert.
ok claudio
Add CXXFLAGS_ports-gcc = -fdelete-null-pointer-checks to these ports which
needs it. qtgrpc needs it because it uses protobuf and abseil-cpp.
qtdeclarative is yet another C++ monster that needs it because of traits.
OK rsadowski@ tb@
Update to openssl 3.6.1
This fixes a gazillion of CVEs. Far too many to name and list and most of
which can be safely ignored by everyone except those who make their living
off CVE busywork. Unless you use CMS AuthEnvelopedData you're good. If you
don't use PKCS#12 either you're in excellent position to ignore all this.
Update to openssl 3.5.5
This fixes a gazillion of CVEs. Far too many to name and list and most of
which can be safely ignored by everyone except those who make their living
off CVE busywork. Unless you use CMS AuthEnvelopedData you're good. If you
don't use PKCS#12 either you're in excellent position to ignore all this.
Avoid type confusion in the timestamp response parsing
A malformed v2 signing cert can lead to a type confusion, and the result
is a read from an invalid memory address or NULL, so a crash. Unlike for
OpenSSL, v1 signing certs aren't affected since miod fixed this in '14.
Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-69420.
ok jsing
Avoid type confusion in PKCS#12 parsing
A type confusion can lead to a 1-byte read at address 0x00-0xff, so a
crash.
Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-22795
ok jsing
