Per RFC5280, section 5.1.1.2,
[signatureAlgorithm] MUST contain the same algorithm identifier as the
signature field in the sequence tbsCertList (Section 5.1.2.2).
This aligns with a check we already do on the X.509 side.
Update-Note: Invalid CRLs with inconsistent inner and outer signature
algorithms will now be rejected.
Change-Id: I9ef495a9b26779399c932903871391aacd8f2618
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45946
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This may as well be computed from block_size. This reduces the
per-EVP_CIPHER_CTX memory usage slightly.
Update-Note: It doesn't look like anyone is reading into this field. If
they are, we can ideally fix it, or revert this if absolutely necessary.
Change-Id: Ieef9177bed1671efca23d4f94d3d528f82568fc6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45884
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Get the up_ref functions and signature accessors.
Change-Id: Ie12e3a48ccc7e4c165ba08001232f5453e3dca11
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45945
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The X509 version APIs confuse everyone, including our own tests
(v3name_test.cc was using the wrong value). Introduce constants. Also
document which version to use for each type. It is extra confusing that,
although certificates and CRLs use the same Version enum, RFC5280
defines X.509 v3 certificates with X.509 v2 CRLs. (There are no v3
CRLs.)
I'll send a similar patch to OpenSSL to keep upstream aligned.
Change-Id: If096138eb004156d43df87a6d74f695b04f67480
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45944
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I85f0364b83440469c0d15c32dd96607be31fc1b7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45904
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
There are a few places where it is useful to run ECDSA with a specified
nonce:
- An ECDSA KAT in the module self-check
- Unit tests for particular test vectors
- Fuzzing the implementation (requested by the cryptofuzz project)
This replaces the fixed_k machinery with a separate function. Although
they are effectively the same, I've used two different functions.
One is internal and only used in the module self-check. The other is
exported for unit tests and cryptofuzz but marked with a for_testing.
(Chromium's presubmits flag uses of "for_testing" functions outside of
unit tests. The KAT version isn't in a test per se, so it's a separate
function.)
Bug: 391
Change-Id: I0f764d89bf0ac2081307e1079623d508fb0f2df7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45867
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CVE-2021-23840
(Imported from upstream's 6a51b9e1d0cf0bf8515f7201b68fb0a3482b3dc1.)
This differs slightly from upstream's version:
- EVP_R_OUTPUT_WOULD_OVERFLOW didn't seem necessary when ERR_R_OVERFLOW
already exists. (Also since we use CIPHER_R_*, it wouldn't have helped
with compatibility anyway. Though there's probably something to be
said for us folding CIPHER_R_* back into EVP_R_*.)
- For simplicity, just check in_len + bl at the top, rather than trying
to predict the exact number of bytes written.
Update-Note: Passing extremely large input lengths into EVP_CipherUpdate
will now fail. Use EVP_AEAD instead, which is size_t-based and has more
explicit output bounds.
Change-Id: I31835c89dcdecb6b112828f57deb798dc7187db5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45685
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Update-Note: No one uses this function. It had a NULL dereference in
some error cases. See CVE-2021-23841.
Change-Id: Ie1cc97615ac8b674147715d7d62e62faf218ae65
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45684
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This aligns with OpenSSL's behavior. RFC7301 says servers should return
no_application_protocol if the client supported ALPN but no common
protocol was found. We currently interpret all values as
SSL_TLSEXT_ERR_NOACK. Instead, implement both modes and give guidance on
whne to use each. (NOACK is still useful because the callback may be
shared across multiple configurations, some of which don't support ALPN
at all. Those would want to return NOACK to ignore the list.)
To match upstream, I've also switched SSL_R_MISSING_ALPN, added for
QUIC, to SSL_R_NO_APPLICATION_PROTOCOL.
Update-Note: Callers that return SSL_TLSEXT_ERR_ALERT_FATAL from the
ALPN callback will change behavior. The old behavior may be restored by
returning SSL_TLSEXT_ERR_NOACK, though see the documentation for new
recommendations on return values.
Change-Id: Ib7917b5f8a098571bed764c79aa7a4ce0f728297
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45504
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is largely some cleanup so the three features follow the same
patterns and is hopefully cleaner (no more separate static and
non-static paths). The practical impact is probably nil. (Linux-based
ARM builds with crypto extensions as a baseline, if any exist, save
binary size.)
Change-Id: I2214b1a54e2074024b8eeb51799a08b94646cbf3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45485
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
When a feature is enabled statically in the build config, the compiler
defines __ARM_NEON and also considers itself free to emit NEON code.
In this case, there is no need to check for NEON support at runtime
since the binary will not work without NEON anyway. Moving the check to
compile time lets us drop unused code.
Chrome has required NEON on Android for nearly five years now. However,
historically there was a bad CPU which broke on some NEON code, but not
others. See https://crbug.com/341598 and https://crbug.com/606629. We
worked around that CPU by parsing /proc/cpuinfo and intentionally
dropping the optimization. This is not a stable situation, however, as
we're hoping the compiler is not good enough at emitting NEON to trigger
this bug.
Since then, the number of affected devices has dropped, and Chrome has
raised the minimum Android requirement to L. The Net.HasBrokenNEON
metric from Chrome is now well in the noise.
This CL stops short of removing the workaround altogether because some
consumers of Cronet are unsure whether they needed this workaround.
Those consumers also build without __ARM_NEON, so gating on that works
out. We'll decide what to do with it pending metrics from them.
Update-Note: Builds with __ARM_NEON (-mfpu=neon) will now drop about
30KiB of dead code, but no longer work (if they even did before) on a
particular buggy CPU. Builds without __ARM_NEON are not affected.
Change-Id: Id8f7bccfb75afe0a1594572ea20c51d275b0a256
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45484
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
test_fips probably needs to exercise everything that we have self-tests
for.
(The following change will eliminate the duplication of the code to
create the FFDH group. For reasons, that can't be done in this change.)
Change-Id: Ia72064db77381e7cf396a34b4723b2607f26f00b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45404
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Our use-case for this does not require optimisation at the current time,
so a clean C implementation is fine.
Change-Id: I8f29572c33e8dbcc37961c099c71c14aafc8d0a3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45164
Reviewed-by: David Benjamin <davidben@google.com>
QUICHE currently does not know to call
SSL_set_quic_use_legacy_codepoint, picking up the current default of the
legacy code point. It then assumes that the
TLSEXT_TYPE_quic_transport_parameters constant may be used to extract
transport parameters, so after
https://boringssl-review.googlesource.com/c/boringssl/+/44704, it
breaks.
To smooth over the transition, we now define three constants:
TLSEXT_TYPE_quic_transport_parameters_legacy,
TLSEXT_TYPE_quic_transport_parameters_standard, and the old constant.
The old constant will match whatever the default is (for now, legacy) so
the default is self-consistent. Then plan is then:
1. BoringSSL switches to the state in this CL: the default code point
and constant are the legacy one, but there are APIs to specify the
code point. This will not affect QUICHE, which only uses the
defaults.
2. QUICHE calls SSL_set_quic_use_legacy_codepoint and uses the
corresponding _legacy or _standard constant. It should *not* use the
unsuffixed constant at this point.
3. BoringSSL switches the default setting and the constant to the
standard code point. This will not affect QUICHE, which explicitly
configures the code point it wants.
4. Optional: BoringSSL won't switch the default back to legacy, so
QUICHE can switch _standard to unsuffixed and BoringSSL
can remove the _standard alias (but not the function) early.
5. When QUICHE no longer needs both code points, it unwinds the
SSL_set_quic_use_legacy_codepoint code and switches back to the
unsuffixed constant.
6. BoringSSL removes all this scaffolding now that it's no longer
needed.
Update-Note: This this fixes a compatibility issue with
https://boringssl-review.googlesource.com/c/boringssl/+/44704.
Change-Id: I9f75845aba58ba93e9665cd6f05bcd080eb5f139
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45124
Reviewed-by: David Schinazi <dschinazi@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL has a fixed-width version of DH_compute_key nowadays. Searching
around callers of DH_compute_key, many of them go back and re-pad the
secret anyway. Uses of DH should migrate to modern primitives but, in
the meantime, DH_compute_key_padded seems worthwhile for OpenSSL
compatibility and giving fixed-width users a function to avoid the
timing leak.
Bump BORINGSSL_API_VERSION since one of the uses is in wpa_supplicant
and they like to compile against a wide range of Android revisions.
Update-Note: No compatibility impact, but callers that use
DH_compute_key and then fix up the removed leading zeros can switch to
this function. Then they should migrate to something else.
Change-Id: Icf8b2ace3972fa174a0f08ece39710f7599f96f2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45004
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
IETF QUIC draft 33 is replacing the TLS extension
codepoint for QUIC transport parameters from 0xffa5
to 57. To support multiple versions of Chrome, we
need to support both codepoints in BoringSSL. This
CL adds support for the new codepoint in a way that
can be enabled on individual connections.
Note that when BoringSSL is not in QUIC mode, it
will error if it sees the new codepoint as a server
but it will ignore the legacy codepoint as that could
be a different private usage of that codepoint.
Change-Id: I314f8f0b169cedd96eeccc42b44153e97044388c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44704
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I814f55742910c519e9b64aca1b15a4d754adc541
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44944
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
One of the comments in e56dfcf9f4 was worded awkwardly. Thanks to Zi Lin
for fixing this.
Change-Id: I7ee647716e0ee30145bdce5be35128058130e1ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44764
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
BER permits lengths to be non-minimal. Previously this was not supported
at all. This change brings greater support, allowing non-minimal lengths
so long as they fit in a uint32_t.
Change-Id: I002ed2375c78fdb326e725eb1c23eca71ef9ba4a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44684
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
IETF QUIC draft 33 is replacing the TLS extension
codepoint for QUIC transport parameters from 0xffa5
to 57. To support multiple versions of Chrome, we
need to support both codepoints in BoringSSL. This
CL adds support for the new codepoint in a way that
can be enabled on individual connections.
Change-Id: I3bf06ea0710702c0dc45bb3ff2e3d772e9f87f9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44585
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The headers aren't quite interchangeable. stdlib.h defines ::abort()
while cstdlib defines std::abort(). The Google style guide doesn't give
much guidance but says to match the existing style, so I've switched it
to stdlib.h.
See https://github.com/apple/swift-nio-ssl/issues/259
Change-Id: I19feb5213e123a88b381d6d8f8fe9d8e87c81e67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44625
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This involves adding a new function |DH_compute_key_hashed| that
combines the FFDH with the output hashing inside the FIPS module. This
new function uses the padded FFDH output, as newly specified in SP
800-56Ar3.
Change-Id: Iafcb7e276f16d39bf7d25d3b2f163b5cd6f67883
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44504
Reviewed-by: David Benjamin <davidben@google.com>
This change also drops ex_data from DH objects. The global would need
special handling in the FIPS module, which isn't hard, but just dropping
it saves some of the code-size costs of this change and I cannot find
any signs of use of this functionality.
Change-Id: I984bd70698c2ec329f340d294b3b9ec169cd0c4e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44524
Reviewed-by: David Benjamin <davidben@google.com>
Rather than the FIPS module actively collecting entropy from the CPU or
OS, this change configures Android FIPS to passively receive entropy.
See FIPS IG 7.14 section two.
Change-Id: Ibfc5c5042e560718474b89970199d35b67c21296
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44305
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This imports 1ecc76f6746cefd502c7e9000bdfa4e5d7911386 and
41d62636fd996c031c0c7cef746476278583dc9e from upstream. These would have
rejected the mistake in OpenSSL's EDIPartyName sturcture.
Change-Id: I4eb218f9372bea0f7ff302321b9dc1992ef0c13a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44424
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
See also CVE-2020-1971, f960d81215ebf3f65e03d4d5d857fb9b666d6920, and
aa0ad2011d3e7ad8a611da274ef7d9c7706e289b from upstream OpenSSL.
Unlike upstream's version, this CL opts for a simpler edipartyname_cmp.
GENERAL_NAME_cmp is already unsuitable for ordering, just equality,
which means there's no need to preserve return values from
ASN1_STRING_cmp. Additionally, the ASN.1 structure implies most fields
cannot be NULL.
(The change from other to x400Address is a no-op. They're the same type.
Just x400Address is a little clearer. Historical quirks of the
GENERAL_NAME structure.)
Change-Id: I4b0ffe8e931c8ef916794a486e6a0d6d684c0cc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44404
Reviewed-by: Adam Langley <agl@google.com>
<openssl/base.h> checks for a supported platform, but we don't check
endianness of ARM and MIPS, which are bi-endian. See
https://crbug.com/1153312#c7.
Switch this around. Documentation on which define is "official" is hard
to come by, so I mostly mimicked Chromium. Chromium detects
little-endian ARM and MIPS with __ARMEL__ and __MIPSEL__ respectively,
without looking at __arm__ or __mips__. It uses __aarch64__
instead of __AARCH64EL__, but I think that's an oversight. I can get
Clang to output for aarch64_be and that defines __aarch64__ with
__AARCH64EB__.
<openssl/arm_arch.h> (which we should simplify and align with base.h
once this CL sticks) also normalizes to __ARMEL__ over __BYTE_ORDER__
and friends. Although, interestingly, arm_arch.h defines its own
__ARMEL__ on GNUC aarch64, even though Clang does *not* define __ARMEL__
on aarch64. (I'm guessing this aligned for the benefit of the "armx"
bi-arch asm files.) This value is based on __BYTE_ORDER__, not
__ARMEL__, but it assumes GNUC arm always defines __ARMEL__, so I think
it's reasonable to assume GNUC aarch64 always defines __AARCH64EL__.
Given all this, probably the simplest thing that's most likely to work
is to use __ARMEL__, __MIPSEL__, and __AARCH64EL__. Note this does not
change the _M_* checks. _M_* are Windows's definitions, which I think we
can reasonably assume come with an endianness opinion. (Windows' ARM and
ARM64 ABIs mandate little-endian.) This aligns with Chromium.
Update-Note: CPU processor defines are a mess. If a little-endian ARM or
MIPS build breaks, some of the assumptions above may be wrong. In that
case, the output $CC -dM -E - < /dev/null on the offending toolchain
will be useful to fix it. If a big-endian ARM or MIPS build breaks, this
is working as intended. Any resulting binaries weren't producing the
right outputs.
Change-Id: I2a9e662d09df119a71226e91716d84e7ac3792aa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44324
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Almost everything in <openssl/asn1.h> uses ASN1_STRING, and there are a
lot of unspoken assumptions in the library about the type field, so it
needs quite a bit of text.
Change-Id: Ied56c9428069477da8ecb17a174da4320e573fa1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It's not even accurate. The term "master key" dates to SSL 2, which we
do not implement. (Starting SSL 3, "key" was replaced with "secret".)
The field stores, at various points, the TLS 1.2 master secret, the TLS
1.3 resumption master secret, and the TLS 1.3 resumption PSK. Simply
rename the field to 'secret', which is as descriptive of a name as we
can get at this point.
I've left SSL_SESSION_get_master_key alone for now, as it's there for
OpenSSL compatibility, as well as references to the various TLS secrets
since those refer to concepts in the spec. (When the dust settles a bit
on rfc8446bis, we can fix those.)
Change-Id: I3c1007eb7982788789cc5db851de8724c7f35baf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44144
Reviewed-by: Adam Langley <agl@google.com>
These APIs were used by Chromium to control the carve-out for the TLS
1.3 downgrade signal. As of
https://chromium-review.googlesource.com/c/chromium/src/+/2324170,
Chromium no longer uses them.
Update-Note: SSL_CTX_set_ignore_tls13_downgrade,
SSL_set_ignore_tls13_downgrade, and SSL_is_tls13_downgrade now do
nothing. Calls sites should be removed. (There are some copies of older
Chromium lying around, so I haven't removed the functions yet.) The
enforcement was already on by default, so this CL does not affect
callers that don't use those functions.
Change-Id: I016af8291cd92051472d239c4650602fe2a68f5b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44124
Reviewed-by: Adam Langley <agl@google.com>
I got that wrong. It passes ownership to the caller. It calls
X509_PUBKEY_get which bumps the refcount.
Change-Id: I46b7eabcf56f68bb1f745bc2f64091640e97c0bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44084
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We have several implementations of this internally, so consolidate them.
Chromium also has a copy in net/der/parse_values.cc which could call
into this.
(I'm also hoping we can make c2i_ASN1_INTEGER call this and
further tighten up crypto/asn1's parser, but I see Chromium still has an
allow_invalid_serial_numbers option, so perhaps not quite yet.)
Update-Note: This CL does not change behavior, but I'm leaving a note to
myself to make net/der/parse_values.cc call the new functions.
Change-Id: If2aae6574ba6a30e343e1308da6af543616156ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44051
Reviewed-by: Adam Langley <agl@google.com>
This still needs some overall documentation describing ASN1_STRING's
relationship to all the other types, but start with the easy bits.
Change-Id: I968d4b1b3d57a9b543b3db489d14cf0789e30eb3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44049
Reviewed-by: Adam Langley <agl@google.com>
The free and dup macros are fine and can be replaced with their function
counterparts, but the new macros call ASN1_STRING_type_new with a
representative type in the CHOICE. This does not match what the
corresponding functions (e.g. ASN1_TIME_new) do.
The functions go through tasn_new.c and end up at ASN1_primitive_new.
That ends up creating an ASN1_STRING with type -1 and the
ASN1_STRING_FLAG_MSTRING flag set. X509_time_adj_ex uses the flag to
determine whether to trigger X.509's UTCTime vs GeneralizedTime
switching.
Confusingly, ASN1_TIME_adj, ASN1_UTCTIME_adj, and
ASN1_GENERALIZEDTIME_adj trigger this behavior based on the function
itself. That seems more robust (X509_set1_notBefore might accidentally
lose the flag), so maybe we can remove this flag. In the meantime, at
least remove the old macros so we don't create the wrong type.
Update-Note: Some M_ASN1 macros were removed. Code search says there
were no uses, and OpenSSL upstream removed all of them.
Change-Id: Iffa63f2624c38e64679207720c5ebd5241da644c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44047
Reviewed-by: Adam Langley <agl@google.com>
At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.
This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:
- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
containing some set of string types) are weird because the M_FOO_new()
macro and the tasn_new.c FOO_new() function behave differently. I've
split those into a separate CL.
- ASN1_STRING_type, etc., call into the macro, which accesses the field
directly. This CL inverts the dependency.
- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
function is a no-op, but consistent.)
- The other macros like M_ASN1_BIT_STRING_dup largely do not have
corresponding functions. I've aligned with OpenSSL in just using the
generic ASN1_STRING_dup function. But some others, like
M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
function. OpenSSL retained these, so I have too.
Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.
Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
Reviewed-by: Adam Langley <agl@google.com>
Some of the X509 functions are hard to document without first
documenting the ASN.1 types themselves. (ASN1_TYPE's goofy
representation is leaked everywhere.)
Change-Id: I0adcf055414925f9e39c8293cbd42d29f0db3143
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44044
Reviewed-by: Adam Langley <agl@google.com>
During the upstream review process a leading dot got removed by
accident. Missing this single character renders BoringSSL
Armv8.5-A BTI incompatible.
Also added two semicolons, just to be consistent.
Change-Id: I6c432d1c852129e9c273f6469a8b60e3983671ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44024
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
At the time, we hadn't taught clang-format how to handle STACK_OF
correctly.
Change-Id: Ia90c3bf443846a07eddaea5044b724027552ed30
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43964
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I77e08b88afa8a1f4e28449bf728eccc2c2f6f372
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43944
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
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>
David Benjamin
Adam Langley
Adam Langley
Yuchen Dai
David Schinazi
Dan McArdle
Tamas Petz