A few can be made static. Move the rest of asn1_locl.h.
Update-Note: Code search says these are unused. If someone's using them,
we can reexport them.
Change-Id: Ib41fd15792b59e7a1a41fa6b7ef5297dc19f3021
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43893
Reviewed-by: Adam Langley <agl@google.com>
This was used to register custom primitive types, namely some INTEGER
variations. We have since removed them all.
Change-Id: Id3f5b15058bc3be1cef5e0f989d2e7e6db392712
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43891
Reviewed-by: Adam Langley <agl@google.com>
Sadly we need to keep ASN1_put_eoc. Ruby uses it.
OpenSSL's PKCS#7 implementation generated an "ndef" variant of the
encoding functions, to request indefinite-length encoding. Remove the
support code for this.
Update-Note: Types that use one of the NDEF macros in asn1t.h will fail
to compile. This CL should not affect certificate parsing.
Change-Id: I6e03f6927ea4b7a6acd73ac58bf49512b39baab8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43889
Reviewed-by: Adam Langley <agl@google.com>
This is a remnant of an older incarnation of OpenSSL's ASN.1 code.
Update-Note: Types using IMPLEMENT_COMPAT_ASN1 from openssl/asn1t.h will
fail to compile. This CL should not affect certificate parsing.
Change-Id: I59e04f7ec219ae478119b77ce3f851a16b6c038f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43888
Reviewed-by: Adam Langley <agl@google.com>
This is never used. Remove the logic so we can gradually simply the
legacy ASN.1 code.
Update-Note: Types using ASN1_BROKEN_SEQUENCE from openssl/asn1t.h will
fail to compile. This CL should not affect certificate parsing.
Change-Id: I06b61ae2656a657aed81cd467051a494155b0963
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43887
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This entire function is assuming all the STACK_OF(T) types are secretly
the same type, but best to consistently use the sk_ASN1_VALUE_*
wrappers. The raw sk_foo functions are an implementation detail of the
macros and we probably should rename them to be better prefixed (as
upstream did).
Change-Id: I62d910b93ca6be5e1c83ae269c7df6a437ffb316
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43884
Reviewed-by: Adam Langley <agl@google.com>
x509_rsa_ctx_to_pss returns an error when trying to make an X509_ALGOR
for an arbitrary RSA-PSS salt length. This dates to the initial commit
and isn't in OpenSSL, so I imagine this was an attempt to ratchet down
on RSA-PSS parameter proliferation.
If the caller explicitly passes in md_size, rather than using the -1
convenience value, we currently fail. Allow those too and add an error
to the error queue so it is easier to diagnose.
Change-Id: Ia738142e48930ef5a916cad5326f15f64d766ba5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43824
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These are a bit of a mess. Callers almost never handle the error
correctly.
Change-Id: I85ea6d4c03cca685f0be579459efb66fea996c9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43804
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When generating a signature with some external signing process, the
caller needs to fill in the TBSCertificate (including the signature
algorithms), serialize the TBSCertificate, and then fill in the
signature.
We have i2d_re_X509_tbs (originally from CT I believe), but there are no
setters for the signature algorithms or the signature. Add
X509_set1_signature_algo, which mirrors upstream's
X509_REQ_set1_signature_algo, and X509_set1_signature_value, which is
new. Upstream has X509_REQ_set0_signature, but that requires the caller
manually assemble an ASN1_BIT_STRING. Taking the byte string seems less
error-prone.
Additionally, add i2d_X509_tbs and i2d_X509_CRL_tbs, for the non-"re"
variants of those APIs. Conscrypt needs to extract the TBS portion of a
certificate and a CRL, to implement X509Certificate.getTBSCertificate()
and X509CRL.getTBSCertList(). There, the aim is to get the data to
verify on an existing immutable certificate. OpenSSL has avoided
exporting the X509_CINF type, which I think is correct, so instead this
mirrors i2d_re_X509_tbs. (This does mean mirroring the confusing i2d
calling convention though.)
These new functions should unblock getting rid of a bunch of direct
struct accesses.
Later on, we should reorganize this header into immutable APIs for
verification and mutable APIs for generation. Even though we're stuck
the mistake of a common type for both use cases, I think splitting up
them up will let us rationalize the caches in the X509 objects a bit.
Change-Id: I96e6ab5cee3608e07b2ed7465c449a72ca10a393
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43784
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
For FIPS reasons, one might wish to ensure that a random AES-GCM nonce
was generated entirely within the FIPS module. If so, then these are the
AEADs for you.
Change-Id: Ic2b7864b089f446401f700d7d55bfa6336c61e23
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43686
Commit-Queue: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
We use this constant a lot in e_aes.c, but we write it out every time.
Change-Id: Iaa92efb391def6640349940c682d9f70ddaa23d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43685
Reviewed-by: David Benjamin <davidben@google.com>
We already support this, but there wasn't a test for it.
Change-Id: I14304b99b312fcf729703cf175ec41e3e60db363
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43704
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
These booleans are a little hard to understand in context and adding
any more makes things even more complicated. Thus make them flags so
that the meaning is articulated locally.
Change-Id: I8cdb7fd5657bb12f28a73d7c6818d400c987ad3b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43684
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is a looser reland of
https://boringssl-review.googlesource.com/c/boringssl/+/41804, which was
reverted in
https://boringssl-review.googlesource.com/c/boringssl/+/42804.
Enforcing that the ECDSA parameters were omitted rather than NULL hit
some compatibility issues, so instead allow either forms for now. To
align with the Chromium verifier, we'll probably want to later be
stricter with a quirks flag to allow the invalid form, and then add a
similar flag to Chromium. For now, at least try to reject the completely
invalid parameter values.
Update-Note: Some invalid certificates will now be rejected at
verification time. Parsing of certificates is unchanged.
Bug: b/167375496,342
Change-Id: I1cba44fd164660e82a7a27e26368609e2bf59955
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43664
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The constructor parameter vs. method name one is a little unfortunate
given Google C++ style, but I think we've done this elsewhere in libssl,
so let's run with it for now.
Bug: 378
Change-Id: I31fb6b4b16e3248369dae6f47cc150de0e4f04fe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43545
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(Original CL by svaldez, reworked by davidben.)
Change-Id: I8570808fa5e96a1c9e6e03c4877039a22e73254f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42404
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL synchronizes bio->next_bio and ssl->rbio with a variety of
callbacks, so BIO_copy_next_retry worked. We do not, so attempting to
flush the BIO crashed.
The SSL BIO is a compatibility hack and intentionally much more limited,
so start by just copying things from the right BIO directly. Add a basic
unit test for SSL BIOs. If we need to, we can implement a more complex
synchronization later.
Additionally reject reconfiguring an SSL BIO because that will leak the
object right now.
Change-Id: I724c95ab6f1a3a1aa1889b0483c81ce3bdc534ae
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43424
Reviewed-by: Adam Langley <agl@google.com>
Sometimes the linker will generate rodata subsections even if we don't
have -fdata-sections enabled. That's ok, so include them in the FIPS
module. The other subsections continue to be discarded to ensure that
unexpected sections don't appear and escape the module.
Bug: b/142971559
Change-Id: Icebcf40bd3d0e63f20456e44f6c2564f4316b561
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43324
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
It's a lot easier to copy certificates to and from x509_test.cc when
there isn't an indent to worry about. Note this does stick a newline in
front of each string, but the PEM parsers don't care.
Change-Id: I06aff263a2470596e8c50564c198693cfdbf9c59
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43285
Reviewed-by: Adam Langley <agl@google.com>
See 309e73dfe067b3b774ef6f57bf665f41373a81ca from upstream, though note
that v3_alt.c's fix was rewritten. (We don't have sk_reserve, and I
don't think their fix was quite right anyway.)
Change-Id: Ieabd19d87d4628658324b212cce2ed3ce451ad22
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43284
Reviewed-by: Adam Langley <agl@google.com>
See b/169780122. This CL should be a no-op (the only other OPENSSL_LINUX
defines are in urandom/getrandom logic, which Trusty doesn't use), but
should be easier to work for future code.
Change-Id: I7676ce234a20ddaf54a881f2da1e1fcd680d1c78
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43224
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Trusty doesn't have madvise() or sysconf() and more importantly,
doesn't have fork() (confirmed chatting to ncbray), so the
no-op #if branch in fork_detect.c seems appropriate.
Change-Id: I41b41e79d59919bae6c6ece0e0efd3872105e9b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43204
Commit-Queue: Pete Bentley <prb@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Expect to reenable in January 2021.
Change-Id: I364ffcf235901398196c60c45ff1c07fcac3f801
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43024
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Looks like some toolchain updated recently and the bots are complaining
about copy vs reference. While I'm here, this is a test and just
declaring a pair of vectors is much less typing than an external array
and a pair of spans.
Change-Id: Iffc0beed99f5ef492d78bc58b5bb02d7c595a072
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43044
Reviewed-by: Adam Langley <agl@google.com>
In upstream, this returns a const pointer, so we should match.
Update-Note: Callers may need to update their calls of
X509_get0_extensions, but I believe everything affected has been fixed.
Change-Id: Ic92660e18868cc681399ba4fc3f47ea1796fb164
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42884
Reviewed-by: Adam Langley <agl@google.com>
Changes:
- Remove point prefixes.
- Don't verify SRR on the client.
TODO:
- Replace SRR generation with RR generation on issuer.
- Add finalized PrivacyPass version.
Change-Id: Ibfb04aaba2cf669639af77299da22ab668175edb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42824
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Conscrypt will need these functions. Also fix a bug in
X509_get_extension_flags's error-handling. While I'm here, add
X509_CRL_get0_extensions for completeness. Nothing uses this yet, but
this could later be an alternative to avoid Conscrypt's mess with
templates.
Change-Id: I9393b75fcf53346535e6a4712355be081baa630d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42744
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
X509_STORE_CTX_init is documented upstream to allow a NULL store and has
logic to account for it. However, attempting to use such an
X509_STORE_CTX crashes in X509_verify_cert due to the
additional_untrusted logic we added.
Moreover, before that change, it still crashes because
X509_STORE_CTX_get1_issuer (the default get_issuer hook) assumes
ctx->ctx (the store) is non-null. This was also true in upstream but
later fixed in https://github.com/openssl/openssl/pull/6001. However,
without a store, there is no trust anchor, so this is not very useful.
Reject NULL stores in X509_STORE_CTX_init and remove the logic allowing
for a NULL one.
Thanks to Danny Halawi for catching this.
Update-Note: X509_STORE_CTX_init will now fail when the store is NULL,
rather than report success, only to crash later in X509_verify_cert.
Breakage should thus be limited to code which was passing in a NULL
store but never used the resulting X509_STORE_CTX.
Change-Id: I9db0289612cc245a8d62d6fa647d6b56b2daabda
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42728
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is needed to fix all the config APIs to take const char *. I've
split it out as it's the only incompatible half of the change.
Update-Note: External definitions of X509V3_CONF_METHOD will need fix
the types of their functions. There should not be any of these (probably
hide this struct), but if there are, this aligns with upstream OpenSSL.
Change-Id: I6e760cfbca5d3f408215b8f3744acd1fd7f31391
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42727
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Cast between T* and ASN1_VALUE* directly, rather than messing with
unions. This is necessary to avoid UB in C++ and is a strict aliasing
violation in C too. (While C does allow type-punning in unions, pointers
to union fields have weird rules. I suspect most of our unions should be
reworked.)
Change-Id: Ibe274a7df5d5826f8c5f335255d196e9b7587105
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42726
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
With TLS 1.3 and Ed25519 support, we're much closer to OpenSSL 1.1.1
these days than OpenSSL 1.1.0. I've also added a test to keep
OPENSSL_VERSION_NUMBER and OPENSSL_VERSION_TEXT in sync.
Update-Note: Some OPENSSL_VERSION_NUMBER/OPENSSL_IS_BORINGSSL checks may
need to be updated. Hopefully even more can go away.
Bug: 367
Change-Id: Idaa238b74f35993c9c03fec31f1346c15cf82968
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42864
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This function is unused and quite unsafe.
Update-Note: Use ASN1_STRING_set instead, though this function appears
to be unused.
Change-Id: Ie6f4dec4b9e11ebde95b322ef91e1b8d63fbb8af
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42724
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit 9dd9d4fc24.
BUG=b/167375496,342
Original change's description:
> Check AlgorithmIdentifier parameters for RSA and ECDSA signatures.
>
> This aligns with the Chromium certificate verifier, which allows NULL or
> empty for RSA and requires empty for ECDSA.
>
> Bug: 342
> Change-Id: I34acf68f63b4d133dd47b73144b2f27224c499ee
> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41804
> Reviewed-by: Adam Langley <agl@google.com>
> Commit-Queue: David Benjamin <davidben@google.com>
TBR=agl@google.com,davidben@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: If8f136a09fea68e64c9f4f9ffae88b6209ede124
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42804
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Although extensions are accessible via X509_get_ext_d2i, OpenSSL's X509
object carries caches of a number of extensions. OpenSSL added accessors
for some of these in 1.1.0 (X509_get0_subject_key_id) and 1.1.1d (the
others), so mirror this. Note that, although they look like simpler
getters, the error-handling is tricky.
(For now I'm just looking to mirror OpenSSL's accessors and finally make
the structs opaque. Go's x509.Certificate structure also recognizes a
collection of built-in certificate fields, but error-handling is in the
parser. That could be one path out of this cached fields mess, at the
cost of making the parse operation do more work.)
Change-Id: I051512aa296bd103229ba6eb2b5639d79e9eb63f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42624
Reviewed-by: Adam Langley <agl@google.com>
These aren't used within the verifier and no one ever extracts them.
Update-Note: Parsers for these two extensions are removed. Parsing the
types directly or passing NID_sxnet and NID_pkey_usage_period into
X509V3_get_d2i, or *_get_ext_d2i will no longer work.
Change-Id: I359e64466fd0c042eda45c41cbc0843ebb04df9f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42585
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Actually making crypto/asn1 and crypto/x509 const-correct will be a tall
order, between all the hidden caches, non-const ASN.1 macros, and
ambiguity between mutable and immutable getters. But upstream
const-corrected a number of things, so align with them. (In particular,
it is not currently possible to usefully use a non-const X509_NAME.)
I think I've gotten most of x509.h. I started going through x509v3.h,
but all the conf bits take non-const char* pointers, which shows up in
the public (but probably unused) X509V3_CONF_METHOD, so I've left it
alone in this CL.
For some reason, OpenSSL made X509_get_subject_name a const-to-non-const
function but kept X509_get_serialNumber uniformly non-const while adding
a uniformly const X509_get0_serialNumber. I've just mirrored this for
compatibility's sake.
Change-Id: Ia33a7576165cf2da5922807fc065f1f114b0f84c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42584
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Adam Langley
Steven Valdez
Tamas Petz
Pete Bentley
Adam Langley
Daniel McArdle