Rather than trying to override the actual malloc symbol, just intercept
OPENSSL_malloc and gate it on a build flag. (When we first wrote these,
OPENSSL_malloc was just an alias for malloc.)
This has several benefits:
- This is cross platform. We don't interfere with sanitizers or the
libc, or have to mess with global symbols.
- This removes the reason bssl_shim and handshaker linked
test_support_lib, so we can fix the tes_support_lib / gtest
dependency.
- If we ever reduce the scope of fallible mallocs, we'll want to
constrain the tests to only the ones that are fallible. An
interception strategy like this can do it. Hopefully that will also
take less time to run in the future.
Also fix the ssl malloc failure tests, as they haven't been working for
a while. (Malloc failure tests still take far too long to run to the end
though. My immediate motivation is less malloc failure and more to tidy
up the build.)
Bug: 563
Change-Id: I32165b8ecbebfdcfde26964e06a404762edd28e3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56925
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Change-Id: I6fa17e204cb2003a6803e01604c0187420b4e39b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56945
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
The temporary X509_NAME wasn't destroyed if the section didn't exist.
Also document the weird 0 vs -1 convention (see callers), and revise the
NULL check added in
https://boringssl-review.googlesource.com/c/boringssl/+/56705. It
doesn't make a difference, but we should only apply the NULL check after
we've looked at the name, and return -1 because, after the name is
checked, it's a known syntax error.
Also fix a couple of comments that were wrong. It's that the RDNSequence
we take from X509_NAME must have one RDN, not that there's one
RDNSequence. (This is a consequence of X509_NAME's somewhat odd
in-memory representation.)
Bug: oss-fuzz:55700
Change-Id: I5745752bfa82802d361803868f962b2b0fa4bd32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56929
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Handling of duplicate keys is all over the place. For set_reasons, it
tried to catch it but leaked memory. Also fix a hypothetical memory leak
in crldp_from_section, but I think it's actually impossible because any
list of CONF_VALUE from a section, rather than from X509V3_parse_list,
cannot have duplicates. It just overrides the previous value.
(Ideally we'd be consistent about whether duplicates override previous
values or are caught, but I'm opting to just leave the existing behavior
alone because no one should be using these APIs in the first place.)
Bug: oss-fuzz:55669
Change-Id: I95d23c257203dcd799d19f334ef847a97d060aad
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56865
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We check OAEP padding in constant time, but once the padding is
determined to be valid (or not), this fact and, if valid, the output
length are public.
Change-Id: I2aa6a707ca9a91761776746264416736c820977c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56845
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
I forgot to put ASN1_CHOICE_END_cb in the StatementMacros list, which
caused it to mangle the formatting a bit. Also remove the duplicate
ASN1_SEQUENCE_END.
Change-Id: I58b6c6f028b81fb717722e02260f3dfaa4d17e4b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56665
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Newer versions of clang figure out that copy_from_prebuf (used in builds
that aren't x86_64 with assembly optimizations) has a bunch of no-op
iterations and insert a branch. Add a value barrier to stop it. This was
caught by our valgrind-based constant-time validation.
As part of this, I noticed that OPENSSL_NO_ASM builds turn off value
barriers. This is because the value barriers use an empty inline asm
block. While this is technically correct, it's probably unnecessary.
The clang|gcc check means we know GCC-style inline assembly is
supported. Disabling inline asm is used by sanitizers to shut off
unintrumentable code, but there's no uninstrumentable code in the empty
string. It's also used by consumers who haven't figured out how to
integrate an assembler into their build system, but that also doesn't
apply. So just remove the condition on the value barriers so
OPENSSL_NO_ASM also get mitigations.
Update-Note: It is possible the above is wrong and some OPENSSL_NO_ASM
relied on value barriers being disabled. If so, this will break that
build and we'll need to reconsider.
Change-Id: I6e3ea3ee705bef3afcf42d3532b17aaabbbcc60b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56827
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This silences a few false positives in the valgrind-based constant-time
validation.
First, there are a few precondition checks that are publicly true, but
valgrind doesn't know that. I've added a constant_time_declassify_int
function and stuck those in there, since the existing macro is mostly
suited for macros. It also adds a value barrier in production code (see
comment for why). If we more thoroughly decoupled RSA from BIGNUM, we
could probably avoid this, since a lot of comes from going through
public BIGNUM APIs.
Next, our BIGNUM strategy is such that bounds on bignums are sometimes
computed pessimally, and then clamped down later. Modular arithmetic is
trivially bounded and avoids that, but RSA CRT involves some non-modular
computations. As a result, we actually compute a few more words than
necessary in the RSA result, and then bn_resize_words down.
bn_resize_words also has a precondition check, which checks that all
discarded words are zero. They are, but valgrind does not know that.
Similarly, the BN_bn2bin_padded call at the end checks for discarded
non-zero bytes, but valgrind does not know that, because the output is
bounded by n, the discarded bytes are zero.
I've added a bn_assert_fits_in_bytes to clear this. It's an assert in
debug mode and a declassification in constant-time validation.
I suspect a different secret integer design would avoid needing this. I
think this comes from a combination of non-modular arithmetic, not
having callers pass explicit width, and tracking public widths at the
word granularity, rather than byte or bit. (Bit would actually be most
ideal.) Maybe worth a ponder sometime.
Change-Id: I1bc9443d571d2881e2d857c70be913074deac156
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56825
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
When building with OPENSSL_NO_ASM, things are inlined enough that GCC
figures out bn_reduce_once reads words, but not that
bn_big_endian_to_words initializes the parts that are read.
Change-Id: Id4d77cec6ca0782edd0d93022436bd307c2bba17
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56826
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
If obj2 were invalid, obj1 leaks. Also both leak if creating the
POLICY_MAPPINGS object fails on allocation error. Just swap the order,
so the ASN1_OBJECTs go to an owned pointer from the start.
Bug: oss-fuzz:55636
Change-Id: Ibf0bf58f44db510623035004f6eb1e00961a5454
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56805
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Without a limit, a short input can translate into a very large allocation,
which is upsetting the fuzzers. Set a limit of 256, which allows up to a
32-byte allocation. (The highest bit index of any type in RFC 5280 is
8, so this is plenty of buffer.)
We do not consider this function to be safe with untrusted inputs (even
without bugs, it is prone to string injection vulnerabilities), so DoS
is not truly a concern, but the limit is necessary to keep fuzzing
effective.
Update-Note: If anyone is using FORMAT:BITLIST to create very large BIT
STRINGs, this will break. This is unlikely and should be caught by
unit tests; if a project hits this outside of tests, that means they are
passing untrusted input into this function, which is a security
vulnerability in itself, and means they especially need this change to
avoid a DoS.
Bug: oss-fuzz:55603
Change-Id: Ie9ec0d35c7d67a568371dfa961867bf1404f7e2f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56785
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We've already put perlasm.cmake in there. I figure CMake helper files
can go in there. It also seems to match what other projects too.
Change-Id: Ief6b10cf4e80b8d4b52ca53b90aa425b32037e52
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56566
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
and isxdigit.
All of these can be affected by locale, and although we weren't using
them directly (except for isxdigit) we instead had manual versions inline
everywhere.
While I am here add OPENSSL_fromxdigit and deduplicate a bunch of code
in hex decoders pulling out a hex value.
Change-Id: Ie75a4fba0f043208c50b0bb14174516462c89673
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56648
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This feature is unused and, if I recall, doesn't actually work. (OpenSSL
1.1.0 or so had to rework the feature significantly.) It would actually
be nice to embed some fields, but I think that's better done by just
switching the parsers to imperative CBS/CBB calls.
One less feature to support in the new parsers.
Bug: 548
Change-Id: If10a0d9f1ba5eb09c7e570ab7327fb42fa2bd987
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56189
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Currently, the only EXTERN type is X509_NAME. Implicitly tagging an
X509_NAME didn't work anyway because of the cached encoding. Moreover,
even if it did work, it'd be invalid. Name in RFC 5280 is actually a
one-element CHOICE type, and CHOICE types can never be implicitly
tagged. So just remove support.
One thing of note: I'm thinking EXTERN can be used later to retain
ASN1_ITEM compatibility, once X509 and friends no longer use the
template machinery. That means we're not only assuming X509_NAME is
never implicitly tagged, but also that external callers using
<openssl/asn1t.h> won't implicitly tag a built-in type.
This removes a case we need to handle in the rewritten tasn_enc.c. (In
particular, crypto/asn1 and crypto/bytestring use a different tag
representation and I'd like to minimum the number of conversions we
need.)
Update-Note: IMPLEMENT_EXTERN_ASN1 can no longer be used outside the
library. I found no callers using this machinery, and we're better off
gradually migrating every <openssl/asn1t.h> user to CBS/CBB anyway.
Bug: 548
Change-Id: I0aab531077d25960dd3f16183656f318d78a0806
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56186
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I didn't quite handle this case correctly in
https://boringssl-review.googlesource.com/c/boringssl/+/49350, which
made it impossible to express an OPTIONAL, doubly-tagged type in
crypto/asn1.
For some background, an ASN1_ITEM is a top-level type, while an
ASN1_TEMPLATE is roughly a field in a SEQUENCE or SET. In ASN.1, types
cannot be OPTIONAL or DEFAULT, only fields, so something like
ASN1_TFLG_OPTIONAL is a flag an ASN1_TEMPLATE.
However, there are many other type-level features that are applied as
ASN1_TEMPLATE flags. SEQUENCE OF T and SET OF T are represented as an
ASN1_TEMPLATE with the ASN1_TFLG_SEQUENCE_OF or ASN1_TFLG_SET_OF flag
and an item of T. Tagging is also a feature of ASN1_TEMPLATE.
But some top-level ASN.1 types may be SEQUENCE OF T or be tagged. So one
of the types of ASN1_ITEM is ASN1_ITEM_TEMPLATE, which is an ASN1_ITEM
that wraps an ASN1_TEMPLATE (which, in turn, wraps an ASN1_ITEM...).
Such an ASN1_ITEM could then be placed in a SEQUENCE or SET, where it is
OPTIONAL.
We didn't correctly handle this case and instead lost the optional bit.
Fix this and add a test. This is a little interesting because it means
asn1_template_ex_i2d may get an optional bit from the caller, or it may
get one from the template itself. (But it will never get both. An
ASN1_ITEM_TEMPLATE cannot wrap an optional template because types are
not optional.)
This case doesn't actually come up, given it doesn't work today. But in
my pending rewrite of tasn_enc.c, it made more sense to just make it
work, so this CL fixes it and adds a test ahead of time.
Bug: 548
Change-Id: I0cf8c25386ddff992bafae029a5a60d026f124d0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56185
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
All evidence we have points to these devices no longer existing (or at
least no longer taking updates) for years.
I've kept CRYPTO_has_broken_NEON around for now as there are some older
copies of the Chromium measurement code around, but now the function
always returns zero.
Change-Id: Ib76b68e347749d03611d00caecb6b8b1fdbb37b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56765
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This is an unexported API, so it's okay to change it. Many extension
types work by parsing a list of key:value pairs and then setting fields
based on it. If a key appears twice, it'll just overwrite the old value.
But X509V3_get_value_int forgot to free the old value when doing so.
Bug: oss-fuzz:55572
Change-Id: I2b39aa7e9214e82fb40ee2e3481697338fe88e1a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56745
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also add some tests for this syntax. The error-handling here is slightly
subtle. Although we do call GENERAL_NAME_free on the temporary
GENERAL_NAME on error, GENERAL_NAME's value is freed based on the
type field. That means if you add an object to the value but don't set
the type, it won't be freed.
Only the OTHERNAME codepath was affected by this, and a malloc
failure-only case in the is_string path. I've gone ahead and reworked
all the paths so setting the type happens at the same time as setting
the value, so this invariant is more locally obvious.
This only impacts the unsafe, stringly-typed extensions-building APIs
that no one should be using anyway.
Bug: oss-fuzz:55569
Change-Id: I6390e4ac1142264cdc86f95fd850f1b8f81e3fc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56725
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
One less patch Envoy needs to apply. It should only matter when building
as a shared library on Windows, but the CMake build sets it
unconditionally, so match.
Change-Id: I96a2696d587839048184c448c2324cab836138a4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56726
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Now that all assembly files are conditionalized, we no longer need to
detect platforms at the build level. This is convenient because
detecting platforms in Bazel is a bit of a mess.
In particular, this reduces how much we depend on @platforms being
correct. gRPC's build appears to still be using some legacy modes which
seem cause it to, on cross-compiles, report the host's platforms rather
than the target. See https://github.com/grpc/grpc/pull/31938
gRPC should eventually fix this, but it is apparently challenging due
to complexities in migrating from Bazel's legacy system the new
"platforms" mechanism. Instead, try to sidestep this problem by not
relying on the build to do this.
Now, we primarily rely on os:windows being accurate, and cross-compiling
to/from Windows is uncommon. We do also need os:linux to be accurate
when Linux is the target OS, but if Linux is the host and gRPC mislabels
the target as os:linux, this is fine as long as the target is not
FreeBSD, Apple, or another platform that cares about _XOPEN_SOURCE. (In
particular, Android is ambivalent.)
I've also renamed a few things based on what they were actually
selecting. posix_copts was really copts for toolchains with GCC-style
flags. Unfortunately, it's not clear how to condition on the compiler,
rather than the platform in Bazel, so we'll do the wrong thing on
non-MSVC Windows toolchains, but that was true before.
Bug: 542
Change-Id: I7330d8961145ae5714d4cad01259044230d96bcd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56465
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
gopls was warning about this.
Change-Id: Ida8ff67bcb9ada253fb075a8a800cbefd432ca8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56545
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
I assume this came from a bad conversion and then got copy-and-pasted
everywhere.
Change-Id: Id596623608266ce6350d70dff413f38e9fdf13b3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56526
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
gopls currently litters our project with a sea of red, because it
assumes Go files are part of a package, but we have a lot of standalone
Go scripts. (If there are C files in the same directory as the script,
it gets upset about cgo. If there are multiple standalone scripts in the
same directory, it gets uspet about duplicate files.)
Per https://github.com/golang/go/issues/49657 and
https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string,
the convention seems to be a go:build ignore tag. Newer versions of
gopls run in a "standalone" mode, so we still get all the nice LSP
features.
As part of this, I had to align the license header comments from /*
block comments */ to // line comments. Go build constraints can only be
preceded by blank lines and line comments. Block comments apparently
aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.)
If I leave the file unconverted, go fmt will immediately move the
comment to above the license block.
Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Having two of these is tedious and I hope, eventually, we can align
them. But for now, sync them manually:
- Bump the minimum CMake versions to match
- Align the C/C++ version directives
- Simplify architecture detection
- Trim some Windows defines that date to our overly aggressive warnings
- Use the Threads package
- Only use _XOPEN_SOURCE on Linux because it's a glibc-specific problem.
I've tested this manually, but we don't particularly test this build
right now (I forget if anyone is even using it), so this is mostly
relying on finding out from others if it breaks something. In the long
term, we should merge the two CMake builds.
Bug: 542
Change-Id: Icccc466464306967275d29a6982c0e9859fc972c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56445
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
CONF_VALUEs are a mess. They show up in three forms:
- When parsed from a config file (in a CONF), I believe name and value
are never NULL.
- Internally, CONF represents sections as funny CONF_VALUEs where name
is NULL, and value is a STACK_OF(CONF_VALUE) of the wrong type. This
is ridiculous and should be a separate type, though I don't believe it
ever leaks outside the public API.
- When created by X509V3_parse_list, it is possible for them to be
value-less, with a NULL value.
v2i functions can see the last case, and set_dist_point_name comes from
a v2i function. Add a missing NULL check. This only impacts the unsafe,
stringly-typed extensions-building APIs that no one should be using
anyway.
Also fix the name of the test I added in the previous CL. I didn't quite
follow the existing convention.
Fixed: oss-fuzz:55558
Change-Id: I1a2403312f3ce59007d23fe7e226f2e602653019
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56705
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
See also upstream's abcf241114c4dc33af95288ae7f7d10916c67db0.
Fixed: oss-fuzz:55555, oss-fuzz:55556, oss-fuzz:55560
Change-Id: I3b015822806ced39a498017bd2329323ed8dfbf0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56685
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Since we started supporting higher tag numbers, this function needed to
call parse_asn1_tag, which is internally bounds-checked.
Change-Id: I19202fb1256240155fa1b53dd31f2b96fd0e8d40
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56188
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
While information is contradictory on this subject, investigation
of several implementaions and Posix appears to indicate that it
is possible to change the behaviour of isdigit() with locale.
Change-Id: I6ba9ecbb5563d04d41c54dd071e86b2354483f77
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56625
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This fuzzes the config file parser, and the converrsion to X.509
extensions. The initial corpus was computed by:
1. Import every file from OpenSSL 1.1.1 that ends in .cnf.
2. For each section in each such file, add a copy with that section
copied to the top (the "default") section.
3. Also add a file for each unit test.
4. Minimize the corpus.
While I'm here, sort the targets in fuzz/CMakeLists.txt.
Change-Id: I0cfc1ae8e2be3e67dae361605ad19833aec3fe4d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56167
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This improves the error-handling and uses CBB instead. It also resolves
a pile of -Wshorten-64-to-32 warnings. It also removes some of the calls
to ASN_put_object within the library.
The parsing uses NUL-terminated strings a bit because several of the
functions called at the end actually rely on the string being
NUL-terminated. Rather than pipe through (ptr, len) versions through
everything, I just used const char * or CBS based on whether the string
could be assumed to have a trailing NUL.
As part of this, I've made it reject [UNIVERSAL 0], matching all our
parsers. Rejecting that value means, since we don't have a nice
Option<T> in C, we can use zero in all the recursive calls to mean "no
implicit tag".
This does tighten the forms allowed for UTCTime a bit. I've disabled
allow_timezone_offset, while crypto/asn1 broadly still allows it. The
reasoning is this is code for constructing new certificates, not
consuming existing ones. If anything is calling this (hopefully not!) to
accidentally generate an invalid UTCTime, it should be fixed.
Update-Note: This code is reachable from the deprecated, string-based
X.509 extensions API. I've added tests for this, so it should behave
generally compatibly, but if anything changes for a caller using these
APIs, this CL is the likely cause. (NB: No one should be using these
APIs. They're fundamentally prone to string injection vulnerabilities.)
Bug: 516
Change-Id: I87f95e01ffbd22c4487d82c89ac098d095126cc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56166
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
ASN1_BOOLEAN has these ASN1_FBOOLEAN and ASN1_TBOOLEAN variants that
behave slightly strangely. Add some tests to ensure we don't break them
in the rewrite.
In doing so, fix a bug: ASN1_BOOLEAN canonically represents TRUE as
0xff, to match DER. But ASN1_TBOOLEAN is initialized with it->size,
which is 1, not 0xff. Fix it to be 0xff. (This shouldn't actually matter
because the encoder is lax and ASN1_TBOOLEAN doesn't encode TRUE
anyway.)
Bug: 548
Change-Id: I4e7fdc2a3bc87603eaf04a7668359006a1480c2e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56187
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Between the type being sometimes a tri-state and capturing the
underlying DER/BER representation, this type is a bit confusing. Add
constants for these.
I've left a case in ASN1_TBOOLEAN unconverted because it's actually
wrong. It will be fixed in a subsequent CL.
Change-Id: I75d846af14f6b4cd5278c3833b979e89c92c4203
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56487
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The real isspace may give locale-dependent results, so use our own.
This also lets us simplify some of the silliness asn1_string_canon needs
to go through to never pass high bytes into isspace and islower. (I'm
otherwise leaving that function alone because I plan to, later, convert
the whole thing to CBS/CBB.)
Change-Id: Idd349095f3e98bf908bb628ea1089ba05c2c6797
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56486
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These values figure into X509_LOOKUP_hash_dir's on-disk format, so they
must remain stable. Record a couple of values to ensure this remains the
case.
Change-Id: I63afa970f8564e0836d78d00375eb5cd6d383bea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56485
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This removes TRUST_TOKEN_ISSUER_redeem and renames
TRUST_TOKEN_ISSUER_redeem_raw to TRUST_TOKEN_ISSUER_redeem.
Change-Id: Ifc07c73a6827ea21b5f2b0469d4bed4d9bf8fa84
Update-Note: Callers of TRUST_TOKEN_ISSUER_redeem_raw should remove the _raw.
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56365
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Auto-Submit: Steven Valdez <svaldez@google.com>
We no longer have a need to support ppc64le, nor do we have any testing
story.
Update-Note: BoringSSL no longer supports ppc64le.
Change-Id: I016855e40e9a56f96d6d043fb4f970835eabe3b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56389
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Inline functions have type signatures, unlike macros. This seems to be
compatible with existing callers and matches OpenSSL 3.0. Additionally,
while Rust bindgen cannot deal with either inline functions or macros
right now, it seems a future version will fix the former.
Change-Id: I6966ff55910cf70e23117fe5f70a0bd286e26d56
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56405
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
We no longer have a need to support ppc64le, nor do we have any testing
story for the assembly we previously had. Remove all ppc64le-specific
assembly.
This CL stops short of removing it from base.h. That'll be done in a
follow-up CL, just to separate which removals are for the assembly and
which removals remove all support.
Update-Note: After this change, ppc64le builds drop assembly
optimizations and will fallback to a generic C-based AES implementation.
Change-Id: Ic8075638085761d66cebc276eb16c4770ce03920
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56388
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ASN1_generate_v8 has a number of calls to strtoul. strtoul has two
problems for that function.
First, strtoul keeps reading until NUL, but all the functions in that
file act on pointer/length pairs. It's fine because the underlying
string is always NUL-terminated, but this is fragile.
Second, strtoul is actually defined to parse "-1" as
(unsigned long)(-1)! Rather than deal with this, extract the decimal
string parser out of the OID parser as a CBS strotul equivalent.
Change-Id: I1b7a1867d185e34e752be09f8c8103b82e364f35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56165
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
The ppc assembly opened directly to STDOUT while all the other ones open
to OUT and then reassign *STDOUT. I don't know why this makes a
difference, but only the latter works on Windows.
Bug: 542
Change-Id: I5b21bcf11c356ea4f2b6bc124a4a300bbd13be43
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56386
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Template operator() instead of the type. This fixes converting
subclasses with bssl::UniquePtr. std::unique_ptr<T, D> can be converted
to std::unique_ptr<U, E> requires either D == E or for D to be
implicitly convertable to E, along with other conditions. (Notably T*
must be convertible to U*.)
In the real std::unique_ptr, we rely on std::default_delete<T> being
convertable to std::default_delete<U> if T* is convertible to U*. But
rather than write all the SFINAE complexity, I think it suffices to
move the template down a later. This simplifies SSLKeyShare::Create a
little.
Change-Id: I431610f3a69a72dd9def190d3554c89c2d3a4c32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56385
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
I'm not sure why I conditioned C11 on non-Clang MSVC. I think I meant to
invert that condition to NOT MSVC OR CLANG. But given that it worked,
just do it across the board.
(Though we support VS2017, which doesn't support a C11 mode, so this is
slightly curious. It may just be that pre-VS2019, this option is a
no-op.)
Change-Id: I271ffd2a913c1aa676fea7ec41f30c1896bb5955
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56325
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
If you pass an empty assembly file into nasm, it crashes. Add a dummy
instruction which the static linker will hopefully dropped. (This is a
no-op unless you try to link all the assembly files together for a
simpler build.)
Bug: 542
Change-Id: Idd2b96c129a3a39d5f21e3905762cc34c720f6b2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56326
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
97873cd1a5 removed the HRSS assembly, but that file was special-cased in
generate_build_files.py and so an update is also needed there.
Change-Id: I3c99989da5faee6b39a3b90fee5fa89c20997c64
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56345
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
More than one post-quantum group is now defined so it would be possible
for two PQ groups to be 1st and 2nd preferences. In that case, we
probably don't want to send two PQ initial key shares.
(Only one PQ group is _implemented_ currently, so we can't write a test
for this.)
Change-Id: I51ff118f224153e09a0c3ee8b142aebb6b340dcb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56226
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
