These functions already don't go through tasn_*.c. Rewrite them to use
CBS and CBB. This removes some dependencies on ASN1_get_object and
ASN1_put_object.
Update-Note: d2i_ASN1_OBJECT and d2i_ASN1_BOOLEAN will no longer accept
non-minimal length prefixes (forbidden in DER). d2i_ASN1_BOOLEAN will
also no longer accept non-canonical representations of TRUE (also
forbidden in DER). This does not affect certificate parsing, as that
still goes through the old template system, though we will make a
similar change to those functions later.
Bug: 354, 548
Change-Id: I0b7aa96f47aca5c31ec4f702e27108b4106311f2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58145
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Change-Id: I59bcacf10a59ffdf9709785727f5f8b73c992f6e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58026
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
With EVP_PKEY and EVP_PKEY_CTX opaque, these symbols don't appear in any
public APIs anymore. Make them internal, which also opens the door to
renaming them:
- EVP_PKEY_METHOD is more accurately EVP_PKEY_CTX_METHOD
- EVP_PKEY_ASN1_METHOD is more accurately EVP_PKEY_METHOD
Or perhaps the split doesn't mean much and we should fold them together.
Change-Id: I8a0f7c2e07445dc981c7cef697263e59dba7784e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57885
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We do not expect to support this combination, but other consumers of
BoringSSL may choose to.
Change-Id: Ifdafa6a0032af078343bb9ecd80eea89eee582be
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57705
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
When the parameters are incorrect, all assumptions of (EC)DSA fly out
the window, including whether the retry loop actually terminates.
While ECDSA is broadly used with fixed, named groups, DSA was
catastrophically mis-specified with arbitrary parameters being the
default and only mode. Cap the number of retries in DSA_do_sign so
invalid DSA groups cannot infinite loop, e.g. if the "generator" is
really nilpotent.
This also caps the iteration count for ECDSA. We do, sadly, support
arbitrary curves via EC_GROUP_new_curve_GFp, to help Conscrypt remain
compatible with a badly-designed Java API. After
https://boringssl-review.googlesource.com/c/boringssl/+/51925, we
documented that untrusted parameters are not supported and may produce
garbage outputs, but we did not document that infinite loops are
possible. I don't have an example where an invalid curve breaks ECDSA,
but as it breaks all preconditions, I cannot be confident it doesn't
exist, so just cap the iterations.
Thanks to Hanno Böck who originally reported an infinite loop on
invalid DSA groups. While that variation did not affect BoringSSL, it
inspired us to find other invalid groups which did.
Thanks also to Guido Vranken who found, in
https://github.com/openssl/openssl/issues/20268, an infinite loop when
the private key is zero. That was fixed in the preceding CL, as it
impacts valid groups too, but the infinite loop is ultimately in the
same place, so this change also would have mitigated the loop.
Update-Note: If signing starts failing with ECDSA_R_INVALID_ITERATIONS,
something went horribly wrong because it should not be possible with
real curves. (Needing even one retry has probability 2^-256 or so.)
Change-Id: If8fb0157055d3d8cb180fe4f27ea7eb349ec2738
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57228
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
While hiding 'type' isn't such a huge deal, accessing 'pkey' without a
type check is very dangerous. The accessors are type-checked and avoid
this problem. It also gets us slightly closer to not needing to utter
CRYPTO_refcount_t in public headers, as we're currently not quite
declaring it right. And it allows us to remove another union:
https://boringssl-review.googlesource.com/c/boringssl/+/57106
This matches what upstream did in OpenSSL 1.1.0.
Update-Note: Code that reaches into the EVP_PKEY struct will no longer
compile, like in OpenSSL. I believe I've fixed all the cases. If I
missed any, the fix is to switch code to accessors. EVP_PKEY_id(pkey)
for pkey->type is the most common fix.
Change-Id: Ibe8d6b6cb8fbd141ea1cef0d02dc1ae3703e9469
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57105
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Nothing uses this, and the code is somewhat decrepit. Instead of
fixing it and continuing to maintain it as attack surface, we
send this off to the farm where it can run and play all day with
the other unused X.509 extensions.
Update-note: This removes the proxy certificate extension from
the recognized certificate extensions. Previously by default
a certificate with a critical proxy certificate extension would
have been rejected with "proxy certificate not allowed", but
will now be rejected with an unrecognized critical extension
error.
Fixed: 568
Change-Id: I5f838d69c59517254b4fa83f6e2abe6057fa66c7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57265
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Also add public APIs for this, now that the specification is no longer
expected to change, and because a project external to the library wishes
to use it.
For now, I've kept the P-256 version using the generic felem_exp, but we
should update that to use the specialized field arithmetic.
Trust Tokens will presumably move to this later and, in the meantime,
another team wants this.
Bug: chromium:1414562
Change-Id: Ie38203b4439ff55659c4fb2070f45d524c55aa2a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57147
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Remove all the other ERR_R_MALLOC_FAILURES from the
codebase.
Also changes cbb to push to the error stack, to correctly
report cbb failures instead of now only reporting
malloc failures. Previously it turned all cbb failures
into a malloc failure
Bug: 564
Change-Id: Ic13208bf9d9aaa470e83b2f15782fc94946bbc7b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57046
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Decoding from decimal takes quadratic time, and BN_dec2bn will happily
decode however large of input you pass in. This frustrates fuzzers.
I've added a cap to the input length in s2i_ASN1_INTEGER for now, rather
than BN_dec2bn, because we've seen people use BN for surprisingly large
calculator operations, and BN generally doesn't cap inputs to quadratic
(or worse) algorithms beyond memory limits. (We generally rely on
cryptography using fixed parameter sizes, though RSA, DSA, and DH were
misstandardized and need ad-hoc limits everywhere.)
Update-Note: The stringly-typed API for constructing X.509 extensions
now has (very generous) maximum input length for decimal integers of
8,192 digits. If anyone was relying on a higher input, this will break.
This is unlikely and should be caught by unit tests; if a project hits
this outside of tests, that means they are passing untrusted input into
this function, which is a security vulnerability in itself, and means
they especially need this change to avoid a DoS.
Bug: chromium:1415108
Change-Id: I138249d23ca6b1996f8437dba98633349bb3042b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57205
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This will let us call ERR and thread_local from OPENSSL_malloc
without creating a circular dependency. We also make
ERR_get_error_line_data add ERR_FLAG_MALLOCED to the returned
flags value, since some projects appear to be making
assumptions about it being there.
Bug: 564
Update-Note: Any recent documentation (in all OpenSSL forks) for the ERR functions
cautions against freeing the returned ERR "data" strings, as freeing them is handled
by the error library. This change can make an existing double free bug more
obvious by being more likely to cause a crash with the double free.
Change-Id: Ie30bd3aee0b506473988b90675c48510969db31a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57045
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
This includes an internal version which allows a flag to specify
the use of system malloc, or OPENSSL_malloc - this in turn allows
us to use this function in the ERR family of functions and allow
for ERR to not call OPENSSL_malloc with a circular dependency.
Bug: 564
Change-Id: Ifd02d062fda9695cddbb0dbef2e1c1db0802a486
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57005
Auto-Submit: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We still keep time_t stuff around for calling time() and
for external interfaces that are meant to give you time_t
values, but we stop using time_t internally. For publicly
exposed and used inputs that rely on time_t, _posix versions are
added to support providing times as an int64_t, and internal
use is changed to use the _posix version.
Several legacy functions which are extensivly used and
and use pointers to time_t are retained for compatibility,
along with posix time versions of them which we use exclusively.
This fixes the tests which were disabled on 32 bit platorms
to always run.
Update-Note: This is a potentially breaking change for things
that bind to the ASN1_[UTC|GENERALIZED]TIME_set and ASN1_TIME_adj
family of functions (and can not type convert a time_t to an
int64).
Bug: 416
Change-Id: Ic4daba5a299d8f35191853742640750a1ecc53d6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54765
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The "object reuse" mode in d2i_FOO is extremely problematic. See bug for
details. When we rewrite d2i_RSAPublicKey, etc., with CBS, we switched
dropped this fragile behavior and replaced it with freeing the old value
and replacing it with the new value. Extend this behavior to all functions
generated by crypto/asn1 templates too.
In particular, tasn_dec.c already frees the original object on error,
which means callers must already be prepared for OpenSSL to free their
reused object. The one caller I found that would be incompatible (via
both running tests and auditing callers) was actually broken due to this
error case, and has been fixed.
Update-Note: This slightly changes the calling convention of the d2i_FOO
functions. The change should be compatible with almost all valid calls.
If something goes wrong, it should hopefully be quite obvious. If
affected (or unaffected), prefer to set the output parameter to NULL
and use the return value instead.
Fixed: 550
Change-Id: Ie54cdf17f8f5a4d76fdbcddeaa27e6afd3fa9d8e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56647
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Our EVP_CIPHER_mode returns an unsigned value and including negative
numbers in switch/case when the value is unsigned causes some warnings.
This should avoid the need for https://github.com/nodejs/node/pull/46564
(Having them be positive shouldn't have compat impacts. CCM is 8, but no
cipher will report CCM, so any path checking for it will just be dead
code.)
Change-Id: I8dcf5ea55fad9732a09d6da73114cde5d69397d3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57025
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This function was involved in both CVE-2020-1971 and CVE-2023-0286. Both
times, we've had to confirm there were no external callers. Unexport it
so we can be sure of this.
Change-Id: I37b756f5bd66e389f03540872371001c85a0b5af
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56987
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This fixes CVE-2023-0286.
The main impact is that GENERAL_NAME_cmp, when given x400Addresses, can
interpret a pointer with the wrong type. Applications that set
X509_V_FLAG_CRL_CHECK and take CRLs from untrusted sources should take
this patch.
Change-Id: Ib76265fa098df3cb0db075646773c14d59d0ca75
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56985
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: I6fa17e204cb2003a6803e01604c0187420b4e39b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56945
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
The temporary X509_NAME wasn't destroyed if the section didn't exist.
Also document the weird 0 vs -1 convention (see callers), and revise the
NULL check added in
https://boringssl-review.googlesource.com/c/boringssl/+/56705. It
doesn't make a difference, but we should only apply the NULL check after
we've looked at the name, and return -1 because, after the name is
checked, it's a known syntax error.
Also fix a couple of comments that were wrong. It's that the RDNSequence
we take from X509_NAME must have one RDN, not that there's one
RDNSequence. (This is a consequence of X509_NAME's somewhat odd
in-memory representation.)
Bug: oss-fuzz:55700
Change-Id: I5745752bfa82802d361803868f962b2b0fa4bd32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56929
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
and isxdigit.
All of these can be affected by locale, and although we weren't using
them directly (except for isxdigit) we instead had manual versions inline
everywhere.
While I am here add OPENSSL_fromxdigit and deduplicate a bunch of code
in hex decoders pulling out a hex value.
Change-Id: Ie75a4fba0f043208c50b0bb14174516462c89673
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56648
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This feature is unused and, if I recall, doesn't actually work. (OpenSSL
1.1.0 or so had to rework the feature significantly.) It would actually
be nice to embed some fields, but I think that's better done by just
switching the parsers to imperative CBS/CBB calls.
One less feature to support in the new parsers.
Bug: 548
Change-Id: If10a0d9f1ba5eb09c7e570ab7327fb42fa2bd987
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56189
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Currently, the only EXTERN type is X509_NAME. Implicitly tagging an
X509_NAME didn't work anyway because of the cached encoding. Moreover,
even if it did work, it'd be invalid. Name in RFC 5280 is actually a
one-element CHOICE type, and CHOICE types can never be implicitly
tagged. So just remove support.
One thing of note: I'm thinking EXTERN can be used later to retain
ASN1_ITEM compatibility, once X509 and friends no longer use the
template machinery. That means we're not only assuming X509_NAME is
never implicitly tagged, but also that external callers using
<openssl/asn1t.h> won't implicitly tag a built-in type.
This removes a case we need to handle in the rewritten tasn_enc.c. (In
particular, crypto/asn1 and crypto/bytestring use a different tag
representation and I'd like to minimum the number of conversions we
need.)
Update-Note: IMPLEMENT_EXTERN_ASN1 can no longer be used outside the
library. I found no callers using this machinery, and we're better off
gradually migrating every <openssl/asn1t.h> user to CBS/CBB anyway.
Bug: 548
Change-Id: I0aab531077d25960dd3f16183656f318d78a0806
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56186
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
All evidence we have points to these devices no longer existing (or at
least no longer taking updates) for years.
I've kept CRYPTO_has_broken_NEON around for now as there are some older
copies of the Chromium measurement code around, but now the function
always returns zero.
Change-Id: Ib76b68e347749d03611d00caecb6b8b1fdbb37b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56765
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
While information is contradictory on this subject, investigation
of several implementaions and Posix appears to indicate that it
is possible to change the behaviour of isdigit() with locale.
Change-Id: I6ba9ecbb5563d04d41c54dd071e86b2354483f77
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56625
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Between the type being sometimes a tri-state and capturing the
underlying DER/BER representation, this type is a bit confusing. Add
constants for these.
I've left a case in ASN1_TBOOLEAN unconverted because it's actually
wrong. It will be fixed in a subsequent CL.
Change-Id: I75d846af14f6b4cd5278c3833b979e89c92c4203
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56487
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The real isspace may give locale-dependent results, so use our own.
This also lets us simplify some of the silliness asn1_string_canon needs
to go through to never pass high bytes into isspace and islower. (I'm
otherwise leaving that function alone because I plan to, later, convert
the whole thing to CBS/CBB.)
Change-Id: Idd349095f3e98bf908bb628ea1089ba05c2c6797
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56486
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This removes TRUST_TOKEN_ISSUER_redeem and renames
TRUST_TOKEN_ISSUER_redeem_raw to TRUST_TOKEN_ISSUER_redeem.
Change-Id: Ifc07c73a6827ea21b5f2b0469d4bed4d9bf8fa84
Update-Note: Callers of TRUST_TOKEN_ISSUER_redeem_raw should remove the _raw.
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56365
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Auto-Submit: Steven Valdez <svaldez@google.com>
We no longer have a need to support ppc64le, nor do we have any testing
story.
Update-Note: BoringSSL no longer supports ppc64le.
Change-Id: I016855e40e9a56f96d6d043fb4f970835eabe3b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56389
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Inline functions have type signatures, unlike macros. This seems to be
compatible with existing callers and matches OpenSSL 3.0. Additionally,
while Rust bindgen cannot deal with either inline functions or macros
right now, it seems a future version will fix the former.
Change-Id: I6966ff55910cf70e23117fe5f70a0bd286e26d56
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56405
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
ASN1_generate_v8 has a number of calls to strtoul. strtoul has two
problems for that function.
First, strtoul keeps reading until NUL, but all the functions in that
file act on pointer/length pairs. It's fine because the underlying
string is always NUL-terminated, but this is fragile.
Second, strtoul is actually defined to parse "-1" as
(unsigned long)(-1)! Rather than deal with this, extract the decimal
string parser out of the OID parser as a CBS strotul equivalent.
Change-Id: I1b7a1867d185e34e752be09f8c8103b82e364f35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56165
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Template operator() instead of the type. This fixes converting
subclasses with bssl::UniquePtr. std::unique_ptr<T, D> can be converted
to std::unique_ptr<U, E> requires either D == E or for D to be
implicitly convertable to E, along with other conditions. (Notably T*
must be convertible to U*.)
In the real std::unique_ptr, we rely on std::default_delete<T> being
convertable to std::default_delete<U> if T* is convertible to U*. But
rather than write all the SFINAE complexity, I think it suffices to
move the template down a later. This simplifies SSLKeyShare::Create a
little.
Change-Id: I431610f3a69a72dd9def190d3554c89c2d3a4c32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56385
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
The only callers of this function were reaching into RSA internals.
We cannot fix all the issues with RSA state management when callers do
this. Those have since been fixed, so unexport this function.
Update-Note: This removes a function that can only be used by accessing
one of BoringSSL's private locks.
Change-Id: I0f067b5650ead38d2dbb7302bad4ddd0b2512458
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56286
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/56109 tried to
simplify the X509V3_CTX story by automatically handling the second half
of initialization, but it turns out not all callers specify both values.
Instead, align with OpenSSL 3.0's behavior. Now X509V3_set_ctx
implicitly zeros the other fields, so it is the only mandatory init
function. This does mean callers which call X509V3_set_nconf before
X509V3_set_ctx will break, but that's true in OpenSSL 3.0 too.
I've retained the allowance for ctx being NULL, because whether
functions tolerate that or not is still a bit inconsistent. Also added
some TODOs about how strange this behavior is, but it's probably not
worth spending much more time on this code.
Change-Id: Ia04cf11eb5158374ca186795b7e579575e80666f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56265
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This reimplements policy handling using a similar DAG structure as in
https://chromium-review.googlesource.com/c/chromium/src/+/4111415. The
main difference is that, being C, we don't have std::set or std::map
easily available. But the algorithm can be implemented purely with
sorted lists, while remaining subquadratic.
This implementation relies on two assumptions:
1. We do not return the policy tree. This was removed in
https://boringssl-review.googlesource.com/c/boringssl/+/53327
2. We do not return the final set of certificate policies. I.e.,
certificate policy checking is only used for evaluating policy
constraints and X509_V_FLAG_EXPLICIT_POLICY.
The second assumption is not very important. It mostly simplifies
has_explicit_policy slightly.
In addition, this new implementation removes the per-certificate policy
cache. Instead, we just process the policy extensions anew on
certificate verification. This avoids a mess of threading complexity,
including a race condition in the old logic. See
https://boringssl-review.googlesource.com/c/boringssl/+/55762 for a
description of the race condition.
Change-Id: Ifba9037588ecff5eb6ed3c34c8bd7611f60013a6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56036
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This relaxes two caller requirements:
First, although one needs to initialize X509V3_CTX in two parts, some
callers forget to this. This works some of the time on accident,
because most codepaths read ctx->db. But if one were to read it, it'd
be uninitialized. Since all the entrypoints take a CONF anyway, and
always match them, just implicitly initialize the CONF half of the
X509V3_CTX with the provided one.
Second, allow X509V3_CTX to be NULL. Some codepaths in the library
check for NULL (or don't use it) and some do not. Enough codepaths
don't check that it really cannot be considered to work, but enough
do that a caller could mistakenly pass in NULL and have it mostly
work. I've seen one caller mistakenly do this. Since we have to copy
the X509V3_CTX for the first relaxation anyway, allow it to be NULL
and fill in an empty one when omitted.
Update-Note: If using different CONFs in the X509V3_CTX and the function
parameter, the function parameter is now always used. No callers do
this, and it's somewhat arbitrary which is used. (The generic code
always uses the one in ctx. The @section syntax uses the parameter. Then
the per-extension callbacks use the ctx.)
Change-Id: I9fc15a581ea375ea06c4b082dcf0d6360be8144f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56109
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Squat fewer unprefixed macros.
Update-Note: CTX_TEST appears to be unused. If affected, switch to using
X509V3_set_ctx_test instead.
Change-Id: I43b86c0b6f147bbca85b8bc6b43602fc4f6697c1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56108
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Our NCONF_get_section doesn't silently handle NULLs, so add a check to
the caller.
Change-Id: I133d10c7a5dec22469a80b78cb45f479f128ada2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56106
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There is no Kyber implementation in BoringSSL so these stubs assume that
you are locally patching such an implementation in.
Change-Id: I274b9a93e60f0eb74301c8d58f05c235687643e1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55930
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This aligns with upstream OpenSSL, so it's hopefully more compatible.
Code search says no one outside of the project uses this function, so
it's unlikely to break anyone.
Whether it makes things better is a bit of a wash: OBJ_dup and
OPENSSL_strdup loose a pointless wrapper. X509_NAME_dup gains one, but
hopefully that can be resolved once we solve the X509_NAME
const-correctness problem. CRYPTO_BUFFER_up_ref gains one... really
FOO_up_ref should have type const T * -> T *, but OpenSSL decided it
returns int, so we've got to cast.
Change-Id: Ifa6eaf26777ac7239db6021fc1eafcaed98e42c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56032
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These APIs should not be used, but far too many callers use them. In the
meantime, at least test this behavior (so it can be rewritten) and write
down why it should not be used.
In doing so, I noticed that we actually broke some cases in the
ASN1_generate_v3 logic. I think it broke in
https://boringssl-review.googlesource.com/c/boringssl/+/48825. But since
no one's noticed, I've just kept it broken.
Bug: 430
Change-Id: I80ab1985964fc506c8aead579c769f15291b1384
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56029
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
We've removed them in other files.
Change-Id: I14ea99c85fd3a21094beeac88cb669e7aa9e2763
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56028
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Constructing extensions from a config file should not modify the config
file or input certificates, so everything here should be const.
While I'm here, fix various missing sk_FOO_push malloc failure checks.
Change-Id: Ic29b21248a9d9243050c771fd0ce1e1d77f7ce7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56027
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In the X.509 policy rewrite, I'll be using sorted stacks to keep the
overall algorithm subquadratic. Fix up sk_FOO_is_sorted in these edge
cases so the asserts work more smoothly.
Change-Id: I369f53543f0c2219df6f62a81aead630a9dbcd8d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56031
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This adds function to allow for issuing and redeeming tokens derived
from a particular message rather than a completely random nonce.
Change-Id: Ia29ae06ca419405ffff79ab6defadbed4f184b29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55565
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Nothing external ever defines X509V3_CONF_METHOD. Removing this allows
us to remove X509V3_section_free altogether because the returned
sections are always owned by the CONF object anyway.
For ease of review, I've split out some of the const-correctness to a
follow-up CL.
Update-Note: X509V3_CONF_METHOD is removed. Code search says no one uses
this.
Change-Id: I66ed6e978b85d40c6849e9f4f45e1bcbf9a0f6a9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56026
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
David Benjamin
Robert Liu
Adam Langley
Bob Beck
Steven Valdez
Adam Langley
Piotr Sikora