openbsd/src/lib/libcrypto/x509, branch OPENBSD_7_3_BASEA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_7_3_BASE2023-03-10T16:44:07+00:00Expose various X509_STORE_*check_issued()2023-03-10T16:44:07+00:00tb2023-03-10T16:44:07+00:00urn:sha1:a42acc367632ae98365b131f71db2b6c99111fdeExpose X509_CRL_get0_sigalg() and X509_get0_uids2023-03-10T16:43:02+00:00tb2023-03-10T16:43:02+00:00urn:sha1:3d3ab6b39893dacfe89816e3de98c07f9817e196Introduce X509_get0_uids() accessor function2023-02-23T18:12:32+00:00job2023-02-23T18:12:32+00:00urn:sha1:45e10d130dd01f514cf8227acec3008ab3fa9b98
By introducing X509_get0_uids(), one can add RPKI profile compliance
checks to conform the absence of the issuerUID and subjectUID.
OK tb@ jsing@
zap stray empty line2023-02-16T10:18:59+00:00tb2023-02-16T10:18:59+00:00urn:sha1:d439245c6f8c6bd9c887a6926c9934052a12c16blibressl *_namespace.h: adjust *_ALIAS() to require a semicolon2023-02-16T08:38:17+00:00tb2023-02-16T08:38:17+00:00urn:sha1:24a27fd0d17d515b00097199de60fa85a76a95df
LCRYPTO_ALIAS() and LSSL_ALIAS() contained a trailing semicolon.
This does not conform to style(9), breaks editors and ctags and
(most importantly) my workflow. Fix this by neutering them with
asm("") so that -Wpedantic doesn't complain. There's precedent
in libc's namespace.h
fix suggested by & ok jsing
Fix arbitrary memory read in GENERAL_NAME_cmp()2023-02-07T15:46:58+00:00tb2023-02-07T15:46:58+00:00urn:sha1:718e2e26a755b26c2d89fde7f7cb78cc32178008
The ASN.1 template for GENERAL_NAME and its corresponding C structure
disagree on the type of the x400Address member. This results in an ASN.1
string to be considered as an ASN.1 type, which allows an attacker to read
(essentially) arbitrary memory. Fix this by forcing comparison as strings.
While the underlying type confusion has been present since time immemorial,
this particular bug came with the EdiPartyName fix (6.8/008_asn1.patch.sig).
Reported by David Benjamin, fix suggested by jsing.
Release date for this was set to be January 31. Unilaterally pushed back to
February 7 by OpenSSL by way of announcement of many completely unrelated
embargoed issues, some of which they had been sitting on since July 2020.
ok beck jsing
Stop relying on x509_verify.h being public2023-01-28T19:08:09+00:00tb2023-01-28T19:08:09+00:00urn:sha1:1075cb8e433aef7b2e557f6c37962e6068934e20
Use x509_verify.h from the libcrypto sources instead of the public copy.
The x509_verify.h header was installed as a public header since early on
we had ideas of using a public API in libtls, but we eventually decided
against that. It makes no sense to install a public header that hides
everything behind LIBRESSL_INTERNAL. The public API will not be exposed
anytime soon if at all.
ok jsing
Refactor x509v3_cache_extensions2023-01-20T22:00:47+00:00job2023-01-20T22:00:47+00:00urn:sha1:fe0fb84f8cd3d820f753cc1976fc23a382ee69b0
Simplify x509v3_cache_extensions() by using a wrapper to avoid
duplication of code for locking and checking the EXFLAG_INVALID flag.
OK tb@
Don't do policy checking unless we were asked to do so.2023-01-17T23:49:28+00:00beck2023-01-17T23:49:28+00:00urn:sha1:99aaa2e0dbd9b331bece18eca7ca3bf034d0c087
ok tb@
Prepare to provide X509_CRL_get0_sigalg()2022-12-26T16:00:36+00:00tb2022-12-26T16:00:36+00:00urn:sha1:ce75c4ecbbf25fd61f45058d3b7faf7e09627ac6
This is an obvious omission from the OpenSSL 1.1 and OpenSSL 3 API which
does not provide a way to access the tbs sigalg of a CRL. This is needed
in security/pivy.
From Alex Wilson
ok jsing