This is far from all of it, but finishes a good chunk of bcm.c.
Bug: 516
Change-Id: If764e5af1c6b62e8342554502ecc4d563e44bc50
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54207
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I put them under convenience functions because they're just wrappers
over existing getters and comparison functions. Used very occasionally,
but probably not important enough to put in the front of the header.
I const-corrected all parameters except X509_NAME. X509_NAME is still a
little tricky const-wise. (X509_NAME_cmp actually does take const names,
so it would compile, but it's misleading because it would actually
mutate the names.)
While here, I tidied it up a little. X509_issuer_and_serial_cmp isn't
really pulling its weight here and is forcing
X509_find_by_issuer_and_serial to stack-allocate a fake, mostly
uninitialized X509 object. The NULL check is also redundant because
STACK_OF(T) treats NULL as the empty list anyway.
With that, X509_issuer_and_serial_cmp is unused (I found no external
callers), so remove it. It's not a particularly problematic function, so
we can easily put it back, but if unused, one less to document.
Update-Note: Removed X509_issuer_and_serial_cmp as it's unused.
Bug: 426
Change-Id: I8785dea9b96265c1fea0c3c7b59e2979e223d819
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54386
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
None of the built-in X509_LOOKUP functions support
X509_LOOKUP_by_fingerprint, X509_LOOKUP_by_issuer_serial, or
X509_LOOKUP_by_alias. We also made X509_LOOKUP_METHOD opaque and haven't
added the corresponding X509_LOOKUP_meth_set_* functions[*], so it is
currently impossible to usefully use these.
I found no callers which use or implement these, which makes sense. The
reason to implement X509_LOOKUP is to plug it into the X509_STORE, which
only cares about lookup by subject.
So just remove them. We can put it back later if it comes up.
[*] Actually it looks like we haven't added any way to make a custom
X509_LOOKUP_METHOD at all yet. I guess it hasn't come up yet.
Update-Note: Some unused functions were removed.
Change-Id: Ief8ba8ae9e5b339beeb59a7156e0258a7a9e70db
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54385
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Poison the EVP_CIPHER_CTX structure on failures, and indicate
that it is an error to re-use an EVP_CIPHER_CTX context in another
call after a failure.
Bug: 494
Change-Id: Ibcdf28b83a2e690f7aab789d908c076d844231c6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54185
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We don't support DSA EVP_PKEY_CTXs (trying to create one will just
fail), but to aid building projects that try to create them, add the
functions and make them always fail.
In particular, Node calls these two. It calls
EVP_PKEY_CTX_set_dsa_paramgen_q_bits via EVP_PKEY_CTX_ctrl, but I'll
send them a patch to use the wrapper function.
Change-Id: Ic134c50b6ea0b59dc8f15be77243b9ae9dfa6a61
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54310
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL added a separate "secure heap" to allocate some data in a
different heap. We don't implement this, so just act as if initializing
it always fails. Node now expects these functions to be available.
Change-Id: I4c57c807c51681b16ec3a60e9674583b193358c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54309
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Without this, Node expects SSL_trace and friends to be available.
Change-Id: Iaccb9fba819846a418e8f3cd4598dcbc1d62744d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54308
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Node calls these. OpenSSL renamed their APIs to align with the IETF
renaming NamedCurve to NamedGroup. (Ironically, with post-quantum
ciphers, that name turns out also to be wrong and it probably should
have been a reference to KEMs.)
To avoid churn for now, I haven't marked the old ones as deprecated, or
renamed any of the internal types yet. We can see about doing that
later.
Change-Id: I5765cea8398f3836611977805bf8ae7d6efc0a70
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54306
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Node just calls every function they can find. I've added the other ones
from RFC 3526 (although some of these are *quite* large) but, for now,
skipped the 768-bit and 1024-bit ones. Those are too small. See
https://github.com/nodejs/node/issues/44539.
I've also reordered so DH_get_rfc7919_2048 is first. In so far as we
want to recommend DH at all, that's probably the one to list first.
Change-Id: If101b32114cc631f80ac6696733c440e222d769a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54305
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This adds a boringssl interface to get up to 256 bytes of system
entropy from system entropy sources without going through
RAND_bytes. It should only be used for seeding custom prng's
or where malloc() should not be called from boringssl.
Just as with RAND_bytes(), this can abort the program on failure.
Bug: chromium:1295105
Change-Id: Ia55509702970608fe09cfee9809d02f107c15c8c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54045
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Among many many problems with renegotiation is it makes every API
ambiguous. Do we return the pending handshake's properties, or the most
recently completed handshake? Neither answer is unambiguously correct:
On the one hand, OpenSSL's API makes renegotiation transparent, so the
pending handshake breaks invariants. E.g., currently,
SSL_get_current_cipher and other functions can return NULL mid
renegotiation. See https://crbug.com/1010748.
On the other hand, OpenSSL's API is callback-heavy. During a handshake
callback, the application most likely wants to check the pending
parameters. Most notably, cert verify callbacks calling
SSL_get_peer_certificate.
Historically, only the pending state was available to return anyway.
We've since changed this
(https://boringssl-review.googlesource.com/8612), but we kept the public
APIs as-is. I was particularly worried about cert verify callbacks.
As of https://boringssl-review.googlesource.com/c/boringssl/+/14028/ and
https://boringssl-review.googlesource.com/c/boringssl/+/19665/, cert
verify is moot. We implement the 3-SHAKE mitigation in library, so the
peer cert cannot change, and we don't reverify the certificate at all.
With that, I think we should switch to returning the established
parameters. Chromium is the main consumer that enables renegotiation,
and it would be better off with this behavior. (Maybe we should try to
forbid other properties, like the cipher suite, from changing on
renegotiation. Unchangeable properties make this issue moot.)
This CL would break if the handshake internally used SSL_get_session,
but this is no longer true as of
https://boringssl-review.googlesource.com/c/boringssl/+/41865.
Update-Note: Some APIs will now behave differently mid-renegotation. I
think this is the safer option, but it is possible code was relying on
the other one.
Fixed: chromium:1010748
Change-Id: I42157ccd9704cde3eebf947136d47cda6754c36e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54165
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Some HPKE consumers call into the KDF directly. We don't have an EVP_KDF
abstraction and it's not clear to me how settled "KDF" is as an
interface. (HPKE specifically assumes an extract/expand pair.)
For now, just add EVP_HPKE_KDF_hkdf_md which is defined to only work for
HKDF KDFs. As we don't implement ID -> KDF lookup ourselves and expect
callers to decide which algorithms they want to export, any future
non-HKDF-based KDF won't affect existing callers anyway. If that
happens, we can make this return an EVP_KDF or just add
EVP_HPKE_KDF_{extract,expand} depending on universal this turns out to
be.
Change-Id: I93b9c8a5340472974a6f1bfc45154371d8971600
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54085
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
OHTTP concatenates enc to the ciphertext without any length prefix
(unlike ECH), so an implementation would want to know the length of enc
for the chosen KEM. Add an accessor to help with that.
While I'm here, fix a couple places where we assumed a specific KEM in
the HPKE implementation (although we still only support the one KEM so
this is all moot).
There's probably something to be said for lifting the length checks out
of the KEM-specific code and into the wrappers, as we're assuming
fixed-width fields anyway. But I've left it alone for now.
Change-Id: I634a053faa5e3b35d846b690140333bdc741f92a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54065
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I3f7026b982f8503fd814be6feb99725f8e60b274
Signed-off-by: Rebecca Chang Swee Fun <rebecca.chang@starfivetech.com>
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54005
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CPython uses this function.
Change-Id: I03ead7f54ad19e2a0b2ea3b142298cc1e55c3c90
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53967
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL renamed X509_STORE_CTX_trusted_stack to
X509_STORE_CTX_set0_trusted_stack. This name is a partially an
improvement as this is a setter, and partially a setback. The "set0"
name is a bit misleading.
set0 is narrowly correct, in that this function does not adjust
refcounts. But usually set0 functions don't adjust refcounts because
they take ownership of the input. This function does not. It simply
borrows the pointer and assumes it will remain valid for the duration of
X509_STORE_CTX.
OpenSSL also renamed X509_STORE_CTX_set_chain to
X509_STORE_CTX_set0_untrusted. I've declined to add that one for now, in
hopes that we can remove both functions. From what I can tell, there's
no point in ever using either function. It's redundant with the last
parameter to X509_STORE_CTX_init.
Change-Id: I0ef37ba56a2feece6f927f033bdcb4671225dc6f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53966
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This was added in OpenSSL 1.1.0. cryptography.io binds it. They don't
actually use it, but this is a useful feature to have anyway. Projects
like Envoy currently implement such a mode with
X509_STORE_set_verify_cb, which is a very problematic API to support.
Add this so we can move them to something more sustainable.
Change-Id: Iaff2d08daa743e0b5f4be261cb785fdcd26a8281
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53965
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
More OpenSSL compatibility functions.
Change-Id: I8e9429fcbc3e285f4c4ad9bdf4c1d9d3c73c3064
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53925
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Rather than documenting the private sk_new_null, etc., APIs and then
expecting callers to infer the real API, describe a real sample API
under #if 0.
Also rename the function pointers to sk_FOO_whatever, which both matches
OpenSSL and reduces the namespaces we squat. The generic callback types
I've renamed to OPENSSL_sk_whatever, to similarly match OpenSSL. We
should also rename plain sk_whatever, but that'll require fixing some
downstream code.
Bug: 499
Change-Id: I49d250958d40858cb49eeee2aad38a17a63add87
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53009
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This syscall is required by generatekey in keystore.
Signed-off-by: Liu Cunyuan <liucunyuan.lcy@linux.alibaba.com>
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Change-Id: I4dd0534daa6cfa52429e5bf398679fccb7d67e7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53765
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The C11 change has survived for three months now. Let's start freely
using static_assert. In C files, we need to include <assert.h> because
it is a macro. In C++ files, it is a keyword and we can just use it. (In
MSVC C, it is actually also a keyword as in C++, but close enough.)
I moved one assert from ssl3.h to ssl_lib.cc. We haven't yet required
C11 in our public headers, just our internal files.
Change-Id: Ic59978be43b699f2c997858179a9691606784ea5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53665
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
We only care about dates within years 0000 to 9999 for
RFC5280. timegm() is only semi-standard. Some things require the
setting awkward defines to get libc to give it to you. Other things
let you have it but make it stop working at year 3000. Still other
things have 32 bit time_t.....
Let's just make our own that actually works. all the time, does
everything with an int64_t, and fails if you want to send something
out that would overflow a 32 bit time_t.
In the process of doing this, we get rid of the old Julian date stuff
from OpenSSL, which while functional was a bit awkward dealing only
with days, and using the Julian calendar as the reference point instead of potentially something more useful. Julian seconds since Jan 1 1970
00:00:00 UCT are much more useful to us than Julian days since a
Julian epoch.
The OS implementations of timegm() and gmtime() also can be pretty
complex, due to the nature of needing multiple timezone, daylight
saving, day of week, and other stuff we simply do not need for
doing things with certificate times. A small microbenchmark of
10000000 of each operation comparing this implementation to
the system version on my M1 mac gives:
bbe-macbookpro:tmp bbe$ time ./openssl_gmtime
real 0m0.152s
user 0m0.127s
sys 0m0.018s
bbe-macbookpro:tmp bbe$ time ./gmtime
real 0m0.422s
user 0m0.403s
sys 0m0.014s
bbe-macbookpro:tmp bbe$ time ./openssl_timegm
real 0m0.041s
user 0m0.015s
sys 0m0.019s
bbe-macbookpro:tmp bbe$ time ./timegm
real 0m30.432s
user 0m30.383s
sys 0m0.040s
Similarly On a glinux machine:
bbe@bbe-glinux1:~$ time ./openssl_gmtime
real 0m0.157s
user 0m0.152s
sys 0m0.008s
bbe@bbe-glinux1:~$ time ./gmtime
real 0m0.336s
user 0m0.336s
sys 0m0.002s
bbe@bbe-glinux1:~$ time ./openssl_timegm
real 0m0.018s
user 0m0.019s
sys 0m0.002s
bbe@bbe-glinux1:~$ time ./timegm
real 0m0.680s
user 0m0.671s
sys 0m0.011s
bbe@bbe-glinux1:~$
Bug: 501
Change-Id: If445272d365f2c9673b5f3264d082af1a342e0a1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53245
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Follow-up work will add support for TLS 1.2 ticket decryption.
Bug: 504
Change-Id: Ieaee37d94562040f1d51227216359bd63db15198
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53525
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Nothing calls this function, it doesn't support most key types, and
accesses pkey.rsa without checking the type. Just remove it.
Change-Id: I073dfe74c545c7e08578b85105c88a19bbddf58a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53505
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
CPython uses this function. Our implementation is slightly weird since
it leaks the clamping behavior, but probably not a big deal.
Update-Note: When this is merged into the internal repository, we can
simplify the CPython patches.
Change-Id: I291ddf852fb463bf02998fe04d0d0e8cb358dc55
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53485
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Our TLS 1.3 stack predates OpenSSL's. We chose TLS1_TXT_* to align with
the existing names. OpenSSL made a new convention, TLS1_3_RFC_*. Match
them.
Similar to 53425
Change-Id: I8737d98c9c1d5c201c4726739ddcbe96123d9370
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53445
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Our TLS 1.3 stack predates OpenSSL's. We chose TLS1_CK_* to align with
the existing names. OpenSSL made a new convention, TLS1_3_CK_*. Match
them.
This means that, in the likely event that TLS 1.4 uses the same
constants, they'll have weird names, just as several of our constants
still say SSL3_* but it doesn't particularly matter.
Change-Id: I97f29b224d0d282e946344e4b907f2df2be39ce1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53425
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
I haven't done the i2d/d2i functions yet, since we haven't talked about
how extensions can be known to the library. Also X509_REVOKED still
needs a home.
Bug: 407
Change-Id: I19fb600ccfda5528728849a42a957803b350b5c5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53337
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Some of these were non-const because dup functions weren't
const-correct, but they are now. Once nuisance is the accessors. Ideally
they'd return non-const pointers, but that'll break OpenSSL consumers.
Bug: 407
Change-Id: I52b939a846b726d1d84dd2d5fdf71a7a7284d49e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53336
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Some don't have sections to go with yet, but will later.
Bug: 426
Change-Id: I903a8bf8c33cdc026a79601a8fd37469c839fa00
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53335
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Although it contains an X509_NAME (by way of GENERAL_NAME), the
GENERAL_NAME field does not participate in serialization, so it is
actually const.
Bug: 407
Change-Id: I299815789744597e2b355cb0b996ba90c3b6a72f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53334
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I can't find any users of these APIs. If we remove them, the only
publicly exposed operation on PKCS8_PRIV_KEY_INFO becomes
EVP_PKCS82PKEY. We can then parse it without a dependency on the legacy
ASN.1 stack.
While I'm here, remove the callback on the structure. OPENSSL_free
automatically calls OPENSSL_cleanse in BoringSSL, so the call is
redundant.
Update-Note: Removed some unused accessors.
Change-Id: I400748463abe3c28dfa42ae9de9be59cb76cd2b2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53332
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There's a lot of these, so toss them into a corner somewhere.
I've added a note to note to discourage using them with memory BIOs.
Memory BIOs are, by far, the most common use I've seen for i2d_*_bio and
d2i_*_bio. It works, but it's unnecessary.
Bug: 426
Change-Id: I8645207a4ac9f1223d0739b5351c99a55400195f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53331
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
It doesn't hash the SPKI, just the BIT STRING in it.
Bug: 426
Change-Id: Ib5b8f14f530cc8045a60ac1e9780779d90f5a3bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53330
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Update-Note: Suite B flags in the X.509 stack are no longer supported.
This isn't expected to affect anything but bindings wrapping unused
options.
Change-Id: Ia0770e545d34e041ab995e80ea11b4dd4a5e47ef
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53329
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This was originally added for the openssl command-line utility and
otherwise is not very useful. I found no callers, so drop it.
Update-Note: An unused function was removed.
Change-Id: I12aa314fd3d8f1dad79eb5a07e0dea662dd9b4a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53328
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL has a large exported API surface for exporting the policy tree
out of an X509_STORE_CTX. As far as I can tell, no one uses any of these
APIs. Remove them.
Update-Note: It is no longer possibly to see the policy tree after an
X.509 verification. As far as we can tell, this feature is unused.
Change-Id: Ieab374774805e90106555ce4e4155f8451ceb5b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53327
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Unfortunately, these functions are not const-correct, even the
accessors. Document what they should have been, especially since
mutating an X509_NAME_ENTRY directly won't even update the 'modified'
bit correctly.
Do a pass at adding consts to our code internally, but since the
functions return non-const pointers, this isn't checked anywhere. And
since serializing an X509_NAME is not always thread-safe, there's a
limit to how much we can correctly mark things as const.
Bug: 426
Change-Id: Ifa3d8bafb5396fbe7b91416f234de4585284c705
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53326
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL calls the timestamp on the CRL lastUpdate, but it's actually
called thisUpdate in RFC 5280.
Bug: 426
Change-Id: I8a34f3de24e1914eda17d300321febe0205b2ec1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53310
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
In particular, since mutating X509s (and X509_CRLs and X509_REQs) does
confusing things, I've split the mutation functions into their own
section, which discusses constructing new objects.
Bug: 426
Change-Id: I1f7dbc5e47f78433e34c74f0cd966803a213e59a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53309
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This only does a few of them for now, in preparation for the following
CL, which tries to group things into sections.
Bug: 426
Change-Id: I4604d458ff2d8e81c8c8f0361a519e5291b8e119
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53308
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
I found no uses of this. If we have to put it back, it's no big deal,
but one less group of functions to have to document. (SEQUENCE OF
AlgorithmIdentifier is mostly a weird PKCS#7 thing.)
Update-Note: X509_ALGORS is removed. If someone was relying on it, we
can re-export it.
Change-Id: I2b8e8d0d1d56d2debf99687023bc3621e92f6b08
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53307
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Types which do not contain an X509_NAME can be const. X509_NAME still
requires some thought. (i2d_X509_NAME can mutate the object and isn't
even thread-safe when modified.)
Bug: 407
Change-Id: Iceafa2b4ea9c4194cfcc3044d90393b5d91f7c11
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53305
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
No sense in keeping two around. This does cause the functions to reject
some previously accepted invalid inputs. These were intentionally
accepted by
https://boringssl-review.googlesource.com/c/boringssl/+/13082 for
an old version of M2Crypto, but I belive we no longer need to be
compatible with that.
Update-Note: ASN1_TIME_print, ASN1_UTCTIME_print, and
ASN1_GENERALIZEDTIME_print will no longer accept various invalid inputs.
Change-Id: I4606d0b39585a19eb4b984ac809706e497a3f799
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53090
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Certain applications of Trust Token need to be able to generate
a large number of keys, instead of storing them all, we provide
an API to take a secret that can be used to generate keys
in a deterministic manner.
Change-Id: I2b61958d1e949a3a47a3c91ab3a866c2e33a9d1d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53011
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
David Benjamin
Bob Beck
Rebecca Chang Swee Fun
Mao Han
Adam Langley
Steven Valdez