wireguard-openbsd/lib/libcrypto/x509, branch master WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/lib/libcrypto/x509?h=master 2021-03-31T16:51:06Z Provide missing prototype for d2i_DSAPrivateKey_fp(3) 2021-03-31T16:51:06Z tb tb@openbsd.org 2021-03-31T16:51:06Z urn:sha1:c3ab052b76109c12233f48762776fa02fc490035 ok bcook inoguchi jsing Fix copy-paste error in previous 2021-03-19T18:52:14Z tb tb@openbsd.org 2021-03-19T18:52:14Z urn:sha1:74808df388a30d1f9ebf77719194a533f9041f83 Found the hard way by lists y42 org via an OCSP validation failure that in turn caused pkg_add over TLS to fail. Detailed report by sthen. ok sthen Use EXFLAG_INVALID to handle out of memory and parse errors in 2021-03-13T23:01:49Z tobhe tobhe@openbsd.org 2021-03-13T23:01:49Z urn:sha1:3746f1b0333604aabaa52b1065fb5be48e5d6292 x509v3_cache_extensions(). ok tb@ Zap a useless variable. 2021-03-12T15:57:30Z tb tb@openbsd.org 2021-03-12T15:57:30Z urn:sha1:e8085cf369534cbe18980f85f87ade79cbb383f4 suggested by jsing Missing void in function definition 2021-03-12T15:55:26Z tb tb@openbsd.org 2021-03-12T15:55:26Z urn:sha1:f2c079f18bd52a67cc7541ef4ec4aad35eb73503 ok jsing Fix checks of memory caps of constraints names 2021-03-12T15:53:38Z tb tb@openbsd.org 2021-03-12T15:53:38Z urn:sha1:42f3108a7d2860fcc392d6a69a9ad058abd50338 x509_internal.h defines caps on the number of name constraints and other names (such as subjectAltNames) that we want to allocate per cert chain. These limits are checked too late. In a particularly silly cert that jan found on ugos.ugm.ac.id 443, we ended up allocating six times 2048 x509_constraint_name structures before deciding that these are more than 512. Fix this by adding a names_max member to x509_constraints_names which is set on allocation against which each addition of a name is checked. cluebat/ok jsing ok inoguchi on earlier version Set is_trusted in x509_verify_ctx_add_chain() 2021-02-26T15:19:41Z tb tb@openbsd.org 2021-02-26T15:19:41Z urn:sha1:57f6d6df0d63d97b03e3a21985d780169e9bd905 If we're about to add a chain we have a trust path, so we have at least one trusted certificate. This fixes a thinko from r1.31 and fixes the openssl(1) cms verify test. ok jsing (who had the same diff) Fix two bugs in the legacy verifier 2021-02-25T17:29:22Z tb tb@openbsd.org 2021-02-25T17:29:22Z urn:sha1:77da1e57a26be2f7238e94b154addfc65dcc6445 To integrate the new X.509 verifier, X509_verify_cert() was refactored. The code building chains in the legacy verifier was split into a separate function. The first bug is that its return value was treated as a Boolean although it wasn't. Second, the return alone is not enough to decide whether to carry on the validation or not. Slightly rearrange things to restore the behavior of the legacy verifier prior to this refactoring. Issue found and test case provided by Anton Borowka and jan. ok jan jsing Rename depth to num_untrusted so it identifies what it actually represents. 2021-02-25T16:58:59Z jsing jsing@openbsd.org 2021-02-25T16:58:59Z urn:sha1:5d6c97755a6b6228e1f7931f69d0ade46cf92c99 ok tb@ Avoid passing last and depth to x509_verify_cert_error() on ENOMEM. 2021-02-25T16:57:10Z jsing jsing@openbsd.org 2021-02-25T16:57:10Z urn:sha1:d963395a74aa582487bb878f0de671997d3b9a09 In x509_verify_ctx_set_xsc_chain(), an ENOMEM case is currently passing the last certificate and depth (which is no longer actually depth) to x509_verify_cert_error(). Given we've hit an ENOMEM situation, neither of these are useful so remove both. ok tb@