openbsd/src, branch OPENBSD_7_7_BASEA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_7_7_BASE2025-03-28T13:11:57+00:00x509_policy: zap an extra s2025-03-28T13:11:57+00:00tb2025-03-28T13:11:57+00:00urn:sha1:c3b500ab309a358fdb98b0f8e59b93f048d08b83x509_policy: certificats -> certificates2025-03-28T12:34:19+00:00tb2025-03-28T12:34:19+00:00urn:sha1:de7d7e36a30bf4dc5cdab5571ec7a8d8cb41e3adtypos: us -> is, te -> the (twice)2025-03-28T12:17:16+00:00tb2025-03-28T12:17:16+00:00urn:sha1:88db2f5852df3e02e139cc00bca104a07aa0a4eatypo: primtive -> primitive2025-03-28T12:13:03+00:00tb2025-03-28T12:13:03+00:00urn:sha1:34d4647beddb60ec830124d4fc67ee4b51155eddFix RETURN VALUES for EVP_CIPHER_CTX_ctrl(3)2025-03-25T11:54:34+00:00tb2025-03-25T11:54:34+00:00urn:sha1:1246a392e49ed859fbba9a9b3352aee5dca07e54
The current documentation was clearly incorrect since a return of -1 from
the methods is explicitly intercepted and translated to 0. schwarze and I
both audited the tree and concluded that only 0 and 1 is possible.
OpenSSL 3 broke this API contract and now has explicit return -1 in the
convoluted 200-line maze this simple function has become with recent
provider improvements. So add a small sentence hinting at that. Nobody
will be surprised to read that with OpenSSL's characteristic penchant
for needless inconsistency the return value checks in their tree are all
over the place and sometimes incorrect.
ok schwarze (with two tweaks)
Explicitly pass group generator to mul_double_nonct() from EC_POINT_mul().2025-03-24T13:07:04+00:00jsing2025-03-24T13:07:04+00:00urn:sha1:865465694bb9f7950a0710e8d7667d2540779602
EC_POINT_mul() has a complex multi-use interface - there are effectively
three different ways it will behave, depending on which arguments are NULL.
In the case where we compute g_scalar * generator + p_scalar * point, the
mul_double_nonct() function pointer is called, however only g_scalar,
p_scalar and point are passed - it is expected that the lower level
implementation (in this case ec_wnaf_mul()) will use the generator from
the group.
Change mul_double_nonct(), ec_mul_double_nonct() and ec_wnaf_mul() so that
they take scalar1, point1, scalar2 and point2. This removes all knowledge
of g_scalar and the generator from the multiplication code, keeping it
limited to EC_POINT_mul(). While here also consistently pass scalar then
point, rather than a mix of scalar/point and point/scalar.
ok tb@
Check group generator in EC_POINT_mul().2025-03-24T12:49:13+00:00jsing2025-03-24T12:49:13+00:00urn:sha1:572b48cb49edaff7e25c2a2130a6715142745223
When a non-NULL generator scalar is passed to EC_POINT_mul(), the group's
generator will be used in multiplication. Add a check that ensures that the
group generator is non-NULL, in order to avoid needing to handle this
elsewhere (currently in the lower level point multiplication code).
ok tb@
Plug a memory leak in x509_name_encode()2025-03-20T09:41:47+00:00tb2025-03-20T09:41:47+00:00urn:sha1:c909f83f696a43dda85d0bb327b00808387784cd
This is nearly identical to a leak fixed by miod 10 years ago in
x509_name_canon() but was missed in r1.30. This entire file needs
a metric ton of bleach, but my head currently spins too much for
tackling this, so go with the cheap one-liner.
From Niels Dossche
x509_param_set_hosts_internal: rename vpm to param for consistency2025-03-19T17:11:21+00:00tb2025-03-19T17:11:21+00:00urn:sha1:46618ac67e5680cdfb18cfaaf83e9cf4e0ba34c6X509_VERIFY_PARAM_lookup(): avoid passing stack garbage around2025-03-19T16:35:11+00:00tb2025-03-19T16:35:11+00:00urn:sha1:d24593fa36472f5cf8194072cdaeb4cf76f19bcc
ok jsing