AllCurves interferes with cross-version handshake hint tests. If any
curve is removed, the test breaks. This is a particular nuisance for
signing tests, where we'd rather like to see cross-version hint
compatibility. It's also a nuisance for writing test suppressions
because the remove curve is not actually listed in the test name.
The signing tests don't actually need to enable all curves. They just
need to handle some TLS 1.2 ECDSA rules. Fix that by having the test
know the expected curve and to configure it explicitly. Hopefully
that'll reduce the exceptions needed in the future.
Change-Id: I432e084c49a943afc92726ccf0b73658e7bd30b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59325
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Also fixes some copy-paste errors in earlier docs.
Bug: 426
Change-Id: I330445477b6feb50f65a868130387804114f23a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59205
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We have since added an implementation of a subset of the SSL BIO, but we
don't implement all the features, notably some of the BIO_ctrl values.
Remove them, so it doesn't look like they should work.
Update-Note: I found no code using those symbols (that we build). If
anything was, they most likely were broken. Now they'll fail to build
and the brokenness will be more obvious. (If we find something needs it,
we can always go back and implement them.)
Fixed: 420
Change-Id: Iad03fa65f098023dca555a9b2ac0214ba4264546
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59125
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Instead, just have it look for the files it needs via a
BORINGSSL_BUILD_DIR environment variable. This avoids hardcoding
"../../build" anywhere that cannot be easily overriden by the user.
Although this puts logic in a build.rs file, which is problematic for
repositories with more coherent build stories like Android or Chromium,
those are already driving the bindgen and link process themselves,
without calling CMake. I.e. this file should already only be used for
standalone development and testing and not directly impact them. (Though
we'd like to keep it vaguely analogous to better predict without a
change will impact downstream folks.)
For now, I've kept bindgen generated from CMake, mostly in anticipation
of using the inline functions feature. Building the synthesized C file
from CMake seems less of a headache than Cargo. Additionally, calling
bindgen from the command-line is closer to how those consumers will do
it, so this forces us to stick to bindgen invocations that can be
expressed via command-line arguments. (E.g. the mess that is regexes and
escaping.)
As part of this, I've removed the messy "find the first matching wrapper
file" behavior in build.rs. Instead, it knows the expected TARGET and
just finds the file with matching name. This means we'll be stricter
about matching the two. (Otherwise there's no point in naming it by
target name anyway.)
Fixed: 598
Change-Id: I07fa74f7e5f5f008d6f0ceec648a2378df7d317a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59105
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Nabil Wadih <nwadih@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
The reason to make it a package was to avoid needing this, but I missed
that git put it back.
Change-Id: Idd6df275aa964083db525d4d5e300128b204d973
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59305
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Prior to https://boringssl-review.googlesource.com/c/boringssl/+/58548,
ASN1_item_sign_ctx returned the length of the signature on success. It's
unclear why anyone would ever want this, but some test was sensitive to
it. (I think it was a typo.)
Restore the old behavior.
Change-Id: Ibf3e45331a339226744d51df703634d02b08a7c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59307
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
When building BCM sources individually, this gets missed.
Change-Id: I58858da441daaeffc5e54b653f5436fe817c4178
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59306
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We previously used the functions from the cipher language to define it,
but it's more straightforward to just list them out.
Change-Id: I1467d6db47a93c8443a0a448ef974c827b1b3233
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59146
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We were currently squeezing 3 bytes at a time. And because kyber.c and
keccak.c are separate files, we've got an optimization barrier, at least
in non-LTO builds, at a very inconvenient place.
Instead, extract the full 168 bytes (SHAKE-128 rate) at a time. This is
conveniently a multiple of three, so we don't need to worry about
partial coefficients. We're still doing a copy due to the Keccak
abstraction, but it should extend cleanly to either LTO or a different
abstraction to read from the state directly. Even without that, it's a
significant perf win.
Benchmarks on an M1:
Before:
Did 87390 Kyber generate + decap operations in 4001590us (21838.8 ops/sec)
Did 119000 Kyber parse + encap operations in 4009460us (29679.8 ops/sec)
After:
Did 96747 Kyber generate + decap operations in 4003687us (24164.5 ops/sec) [+10.6%]
Did 152000 Kyber parse + encap operations in 4018360us (37826.4 ops/sec) [+27.4%]
Change-Id: Iada393edf0c634b7410a34374fb90242a392a9d3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59265
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This aligns the DLEQ proof portion of TRUST_TOKEN_pst_v1_voprf
with draft-irtf-cfrg-voprf-21. The blind and finalize operations
still differ. Additionally, as VOPRF doesn't include batched
issuance, the issuance process around the DLEQ proof is adapted
from draft-robert-privacypass-batched-tokens-01.
Bug: chromium:1414562
Change-Id: If1c6de0f92089a826968a57279ae598ccf89ca3e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58906
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This reverts commit bab2f96e26. This
clears the sea of red in my editor.
Change-Id: I600ef6c36556fb526da729f0f0d8bc69db5c5a08
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59186
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This can still be run like go run ../../util/convert_wycheproof. This is
part of an attempt to reland 54b04fdc21,
which ran into an issue with internal tooling that could not handle
standalone Go files.
Since the only such target we actually needed to run in that repository
is convert_wycheproof, just promote it into its own package. Then we can
stop trying to import util.
Change-Id: I6237777dad09e5c81ad961816ce14a287ab2d46a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59185
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Add a new flag, -shim-extra-flags, which allows specifying additional
flags to pass to the shim binary on all invocations. These flags will be
passed as the first flags to the shim in order to take advantage of some
slightly confusing Go flag semantics.
Change-Id: I382f47bfe2662903b43135fcb249b46646fc9e7b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59245
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Per b/31553927, the last use of this is long gone. This cipher has been
deprecated since it was (re)-added in 2015, so it's long past time to
remove it.
Update-Note: TLS_RSA_WITH_NULL_SHA is no longer available. Nothing
should be enabling it anymore. Callers using
SSL_CTX_set_strict_cipher_list instead of SSL_CTX_set_cipher_list will
notice if they're affected very quickly, because the functino will
fail if this cipher is referenced. As a deprecated cipher suite, this
cipher was already unavailable unless explicitly named, so if your
configuration doesn't say "TLS_RSA_WITH_NULL_SHA" or "NULL-SHA", you
were not using this cipher.
Bug: b:31553927
Change-Id: Id560bb4f9b156be3650d63f4ecf7783fad5ae209
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59145
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>
This took a bit of wrangling to get the depfiles working, but I
eventually figured it out. ninja -d explain is very useful.
Fixed: 597
Change-Id: I909a4c9418e9dc954e3d328da8f3a825e62544e4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59005
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This allows us to mark functions as deprecated
declarations with OPENSSL_DEPRECATED.
We also add an OPENSSL_BEGIN_ALLOW_DEPRECATED and an
OPENSSL_END_ALLOW_DEPRECATED for testing use to
test deprecated functions.
The purpose of this is to allow us to mark things
people should not be using as deprecated, and force some
inconvenience on the user of such things to notice them
(as opposed to a only a warning to not use it that they
may not see or read without something tripping them up.)
The intent is to still allow use, with some effort,
before removing the function, or moving it to
libdecrepit.
We initially mark X509V3_EXT_add and X509V3_EXT_add_alias
as deprecated.
Update-Note: We are starting to mark some functions in
boringssl as deprecated declarations which will cause the
compiler to emit warnings if they are used. The intention
is both to prevent accidental use in new code, and to to call
attention to call sites in existing code so that the documentation
for the deprecated function can be revisted and appropriate action
taken.
Bug: 584
Change-Id: Ia9ff386f0d22588e8a5999eda1a48b8c28dca2de
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58405
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We already require that #include <openssl/blah.h> work. May as well be
consistent in wrapper.h, so it's less path-sensitive.
Change-Id: Idd12e1c56a6e5d11623b4da82e405a5e976601b0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59045
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I6e0361a42b9612ba4294cc8806203ea445bc9257
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58945
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
The allowlist is just a regex, which means bindgen leaves it to the
user to resolve Windows vs POSIX filepath differences. We need to
support both / and \. It's unclear why only some headers are broken, but
it's probably something to do with whether the header is included
directly or indirectly.
Unfortunately, in doing so, we run into a mess of escaping issues, so
the regex is more permissing than ideal.
Bug: 595
Change-Id: I8b785aeaaeff162d9eb2aced89928f9602445903
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58967
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Newer CMakes support a -B parameter, which saves some fuss.
Change-Id: Ifdbbb50b3720cdc42af098eb32941283692e9d99
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58966
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Nabil Wadih <nwadih@google.com>
These appear to be unused. Some ones of note:
- XN_FLAG_FN_ALIGN breaks with multi-attribute RDNs anyway
- XN_FLAG_FN_NONE is completely pointless
Update-Note: Some seemingly unused XN_FLAG_* values were removed. If
some project fails to build, we can put them back but one shouldn't be
using this function in the first place.
Change-Id: I4d8472e1e31aeec623b4d4e2aea48da7b1ef6798
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58930
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This has been on by default since
cc78b6fdb6,
and now removed from recent bindgen altogether.
Change-Id: Iea4c2a7480fe8b138c375686ca6b36e6d68257b3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58965
Reviewed-by: Nabil Wadih <nwadih@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
These probably don't need their own section. They're just thin wrappers
over other ASN1_TIME functions.
Bug: 426
Change-Id: I8672feb0ca7ba1cf69b56d02d2559de5b80a3ee7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58928
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
They're not used anywhere, as X509_REQ doesn't expose the underlying
STACK_OF(X509_ATTRIBUTE) anyway. They're also very thin wrappers over
the stack functions, so just delete them and inline them into X509_REQ
functions.
While I'm here, I've tidied up the add1_attr_by_* functions to reduce an
unnecessary copy.
Change-Id: Iec002c83ab7ad7267314e98866d680d12a82e971
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58927
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also organize the low-level signature verification functions. I missed
those in the first pass.
Bug: 426
Change-Id: I9c93d643d8f0f77a35ee132f31377ba447f2f2f1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58926
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
I had a branch lying around to rewrite X509_NAME_print(_ex) because
those functions are a disaster, but it needs more work and probably
isn't high priority. In the meantime, document what we've got.
Also tidy up X509_print_ex slightly. m was completely unused and
some variable declarations could be moved closer to their definition.
Bug: 426
Change-Id: I24295048c36268c745f579ad66f34736cfe6830f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58925
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
(This change breaks running on Android. But it's close to what we used
for non-Android FIPS testing so is useful to have on the record.)
This change adds testing of the run-time break tests: the pair-wise
consistency tests and the RNG test.
It also switches to using two test_fips binaries: an unmodified one for
showing a clean up and testing the integrity test, and a test_fips_break
which makes integrity test failures non-fatal (for KAT testing) and
which allows the run-time tests to be triggered.
Change-Id: Id2787723059cfb17cc2d22013ad66b985ef86701
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53885
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
On Android, when running from an APK, |tmpfile| does not work. See
b/36991167#comment8.
Change-Id: I1415471907e61da5e8c8d1530a2b915fcd991d53
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58845
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
NIST has deprecated the test that we were using and replaced it with the
one that this change switches BoringSSL to using.
Change-Id: Iff975cda33153f8db42d9c01457d104c502485b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58787
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This relands
https://boringssl-review.googlesource.com/c/boringssl/+/54606, which was
temporarily reverted.
Update-Note: By default, clients will now require RSA server
certificates used in TLS 1.2 and earlier to include the keyEncipherment
or digitalSignature bit. keyEncipherment is required if using RSA key
exchange. digitalSignature is required if using ECDHE_RSA key exchange.
If unsure, TLS RSA server signatures should include both, but some
deployments may wish to include only one if separating keys, or simply
disabling RSA key exchange. The latter is useful to mitigate either the
Bleichenbacher attack (from 1998, most recently resurfaced in 2017 as
ROBOT), or to strengthen TLS 1.3 downgrade protections, which is
particularly important for enterprise environments using client
certificates (aka "mTLS") because, prior to TLS 1.3, the TLS client
certificate flow was insufficiently encrypted or authenticated. Without
reflecting an RSA key exchange disable into key usage, and then the
client checking it, an attacker can spoof a CertificateRequest as coming
from some server.
This aligns with standard security requirements for using X.509
certificates, specified in RFC 5280, section 4.2.1.3, and reiterated in
TLS as early as TLS 1.0, RFC 2246, section 7.4.2, published 24 years ago
on January 1999. Constraints on usage of keys are important to mitigate
cross-protocol attacks, a class of cryptographic attacks that is
well-studied in the literature.
We already checked this for each of ECDSA, TLS 1.3, and servers
verifying client certificates, so this just fills in the remaining hole.
As a result, this change is also important for avoiding some weird
behaviors when configuration changes transition a server in or out of
this hole. (We've seen connection failures get misattributed to TLS 1.3
when it was really a certificate misconfiguration.)
Chrome has also enforced this for some time with publicly-trusted
certificates. As a temporary measure for callers that need more time,
the SSL_set_enforce_rsa_key_usage API, added to BoringSSL in January
2019, still exists where we need to turn this off.
Fixed: 519
Change-Id: I91bf2cfb04c92aec7875e640f90ba6f837146dc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58805
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: I32a40a73f96e029ac9096af826d15b22d9dcad28
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58745
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
HRSS itself remains in libcrypto because there are some direct users of
it. But this will let it be dropped by the linker in many cases.
Change-Id: I870eda30c9ed1d08693c770e9e7df45a2711b7df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58645
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These are already unused, though add and add_alias will need more work.
In doing so, simplify the X509V3_EXT_DYNAMIC business. I added some
cleanup calls to https://boringssl-review.googlesource.com/2208, but
that should have been in the error-handling path of
X509V3_EXT_add_alias, the only case that cares about this.
Update-Note: Removed unused API.
Bug: 590
Change-Id: Idd97366d90d7aab0ca2e020c76a7c8065b3dd7ff
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58765
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
I don't believe these codepaths have ever been run. All the built-in
X509V3_EXT_METHODs are ASN1_ITEM-based, as are all callers I found of
X509V3_EXT_add and X509V3_EXT_add_list.
Also document not to use those APIs because they're pointless and (for
now) not even thread-safe. Making them thread-safe is doable, but it'd
add rwlock contention in certificate verification, unless we first
rework certificate verification to ignore custom registrations, because
it never uses them anyway. But that only proves that this whole feature
was pointless, so this time may be better spent trying to get rid of
this API.
Update-Note: Externally-installed X509V3_EXT_METHODs now must be
ASN1_ITEM-based. I believe all existing ones already are. If there are
any that aren't, let us know. We'll either revert this for now, or
export a way to implement custom ASN1_ITEMs, or, most likely, try to
move the caller off custom X509V3_EXT_METHODs altogether. Like most of
OpenSSL's other global registration APIs, this one is unsafe (two
callers may conflict) and there isn't much reason to register it with
the library because OpenSSL doesn't do much with the registration
anyway.
Bug: 590
Change-Id: Ice0e246d50069e10e6cca8949f60fac474d0846c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58687
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts a small portion of
8c8629bfd8. The parsers for ANY remain
unchanged, but we inadvertently changed a corner case of ASN1_PRINTABLE
MSTRINGs. This is a huge mess.
utype in these switch cases is usually the type of the ASN1_ITEM, but,
with ANY and MSTRING, it is the tag of the value we found. (An MSTRING
or "multi-string" is a CHOICE of string-like types.)
When parsing ANY, this is moot because the is_supported_universal_type
logic ensures we'll never pass in an invalid type. When encoding ANY,
this only happens if you manually construct such an ASN1_TYPE.
MSTRINGs *should* be similar because of the bitmask they apply on tag
types. However, there is one MSTRING type whose bitmask,
B_ASN1_PRINTABLE, includes B_ASN1_UNKNOWN. ASN1_tag2bit, arbitrarily
maps eight unsupported tags to B_ASN1_UNKNOWN and instead of zero. These
are:
- ObjectDescriptor
- EXTERNAL
- REAL
- EMBEDDED PDV
- RELATIVE-OID
- TIME (note this is not the same as the X.509 Time CHOICE type)
- [UNIVERSAL 15], which is not even a defined type!
- CHARACTER STRING
(ENUMERATED is also mapped to B_ASN1_UNKNOWN, but it's supported.)
These eight tags were previously accepted in d2i_X509_NAME but
8c8629bfd8 inadvertently started rejecting
them. For now, restore the default in the switch/case so that we accept
them again. Per https://crbug.com/boringssl/412, attribute values are
ANY DEFINED BY types, so we actually should be accepting *all* types. We
do not, because B_ASN1_PRINTABLE is completely incoherent. But because
ANY is the correct type, going from the original incoherent set, to
this new, smaller incoherent set is arguably a regression.
This is a minimal fix. Long-term, we should handle that ANY correctly,
and avoid unexpected ASN1_STRING type values, by mapping all unsupported
types to V_ASN1_OTHER. This would allow us to support all types
correctly. A follow-up change will do that.
Update-Note: The X.509 name parser will go back to accepting a handful
of universal tag types that were inadvertently rejected in
8c8629bfd8. It is extremely unlikely that
anyone uses these as they're unsupported, obscure types. This CL also
makes our ASN1_TYPE encoder slightly more permissive again, if the
caller manually constructs an legacy in-memory representation of an
unsupported tag. But the follow-up change will restore the stricter
behavior.
Bug: 412, 561
Change-Id: Ia44a270f12f3021154761a1cd285707416d8787e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58705
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: I6e53434246f3fef06d4f88924bfe1cbfad0543e8
Bug: chromium:1414562
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58205
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Change-Id: I43dd18f7d70ee06ca25affad0ab06e5d5ef8263d
Signed-off-by: wangjiale3 <wangjiale3@xiaomi.corp-partner.google.com>
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58489
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also unexport PEM_proc_type and PEM_dek_info. They're never called
externally, just private functions within one file. Also, while I'm
here, fix the include guard on asn1/internal.h.
Bug: 516
Change-Id: I6961a65f638e7b464a8c349663898a954d7826b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58548
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This was replaced with the upstream-compatible SSL_CIPHER_standard_name
in https://boringssl-review.googlesource.com/17324. It looks like we've
since migrated everything off the old name, so let's just remove it.
Update-Note: SSL_CIPHER_get_rfc_name calls can be replaced with
SSL_CIPHER_standard_name, which is also more efficient as it avoids an
allocation and copy. If anyone's using this function and can't easily
migrate, let us know and we can put this back for a little longer.
Change-Id: I6bce40a8a146671429641a5dbff6f614006a9a1c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58665
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
David Benjamin
Steven Valdez
Roland Shoemaker
Bob Beck
Andres Erbsen
Adam Langley
Adam Langley
Nabil Wadih
Adam Langley
wangjiale3