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>
While this assembly implementation is faster in microbenchmarks, the
cache pressure makes it slightly worse than the C code in larger
benchmarks.
Before:
Did 7686 HRSS generate operations in 1056025us (7278.2 ops/sec)
Did 90000 HRSS encap operations in 1010095us (89100.5 ops/sec)
Did 28000 HRSS decap operations in 1031008us (27157.9 ops/sec)
After:
Did 3523 HRSS generate operations in 1045508us (3369.7 ops/sec)
Did 43000 HRSS encap operations in 1017077us (42278.0 ops/sec)
Did 17000 HRSS decap operations in 1011170us (16812.2 ops/sec)
Change-Id: Ia7745b50393f2d2849867e7c5c0af59d651f243d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55885
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The only callers of this function were reaching into RSA internals.
We cannot fix all the issues with RSA state management when callers do
this. Those have since been fixed, so unexport this function.
Update-Note: This removes a function that can only be used by accessing
one of BoringSSL's private locks.
Change-Id: I0f067b5650ead38d2dbb7302bad4ddd0b2512458
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56286
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This generator script once lived in Chromium, so we put the Chromium
copyright on the output. But we've long since moved it into BoringSSL,
so use the BoringSSL license header consistently. This avoids an
unnecessary mixed of licenses in the generated branch.
Bug: 542
Change-Id: I813a088d97af9671c8a4d7c9c707ae9d835f0349
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56285
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Some profiling systems cannot unwind with CFI and benefit from having a
frame pointer. Since this code doesn't have enough register pressure to
actually need to use rbp as a general register, this change tweaks
things so that a frame pointer is preserved.
As this would invalidate the SEH handler, just replace it with proper
unwind codes, which are more profiler-friendly and supportable by our
unwind tests. Some notes on this:
- We don't currently support the automatic calling convention conversion
with unwind codes, but this file already puts all arguments in
registers, so I just renamed the arguments and put the last two
arguments in RDI and RSI. Those I stashed into the parameter stack
area because it's free storage.
- It is tedious to write the same directives in both CFI and SEH. We
really could do with an abstraction. Although since most of our
functions need a Windows variation anyway.
- I restored the original file's use of PUSH to save the registers.
This matches what Clang likes to output anyway, and push is probably
smaller than the corresponding move with offset. (And it reduces how
much thinking about offsets I need to do.)
- Although it's an extra instruction, I restored the original file's
separate fixed stack allocation and alloca for the sake of clarity.
- The epilog is constrained by Windows being extremely picky about
epilogs. (Windows doesn't annotate epilogs and instead simulates
forward.) I think other options are possible, but using LEA with an
offset to realign the stack for the POPs both matches the examples in
Windows and what Clang seems to like to output. The original file used
MOV with offset, but it seems to be related to the funny SEH handler.
- The offsets in SEH directives may be surprising to someone used to CFI
directives or a SysV RBP frame pointer. All three use slightly
different baselines:
CFI's canonical frame address (CFA) is RSP just before a CALL (so
before the saved RIP in stack order). It is 16-byte aligned by ABI.
A SysV RBP frame pointer is 16 bytes after that, after a saved RIP and
saved RBP. It is also 16-byte aligned.
Windows' baseline is the top of the fixed stack allocation, so
potentially some bytes after that (all pushreg and allocstack
directives). This too is required to be 16-byte aligned.
Windows, however, doesn't require the frame register actually contain
the fixed stack allocation. You can specify an offset from the value
in the register to the actual top. But all the offsets in savereg,
etc., directives use this baseline.
Performance difference is within measurement noise.
This does not create a stack frame for internal functions so
frame-pointer unwinding may miss a function or two, but the broad
attribution will be correct.
Change originally by Clemens Fruhwirth. Then reworked from Adam
Langley's https://boringssl-review.googlesource.com/c/boringssl/+/55945
by me to work on Windows and fix up some issues with the RBP setup.
Bug: b/33072965, 259
Change-Id: I52302635a8ad3d9272404feac125e2a4a4a5d14c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56128
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/56109 tried to
simplify the X509V3_CTX story by automatically handling the second half
of initialization, but it turns out not all callers specify both values.
Instead, align with OpenSSL 3.0's behavior. Now X509V3_set_ctx
implicitly zeros the other fields, so it is the only mandatory init
function. This does mean callers which call X509V3_set_nconf before
X509V3_set_ctx will break, but that's true in OpenSSL 3.0 too.
I've retained the allowance for ctx being NULL, because whether
functions tolerate that or not is still a bit inconsistent. Also added
some TODOs about how strange this behavior is, but it's probably not
worth spending much more time on this code.
Change-Id: Ia04cf11eb5158374ca186795b7e579575e80666f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56265
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The ABI test already uses CHECK_ABI_SEH, so this is covered under tests.
As part of the conversion, we no longer rely on the assembler generating
a specific encoding and can just write the code normally.
Bug: 259
Change-Id: I47cbf81073237f2b95971a782848b85d230b6bf6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56127
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This implements similar directives as MASM, so we do not need to build
all the structures by hand. It does not provide any help to abstract
between Win64 and SysV differences, however.
This is pulled together from some old draft CLs I had, one of which
actually synthesized CFI directives from SEH, so it should be possible.
I've intentionally omitted that however, as it also brings in questions
about how to handle the calling convention differences (the existing
machinery won't *quite* work). I've uploaded just this for now, so
review can focus on the basic mechanism.
I've also preserved perlasm's weird mixed tabs and spaces indentation
convention for now, though it is a bit tedious.
Bug: 259
Change-Id: Ib3f46a27751a5319b758d12c462c660cf9f3e632
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56126
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
There was a typo and inhibitPolicyMapping updated the wrong value. With
this fixed, we pass the PKITS tests (as imported into Chromium).
Change-Id: I3b80eb56561ae5ae88023fa639d697a9f1757b21
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56205
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This reimplements policy handling using a similar DAG structure as in
https://chromium-review.googlesource.com/c/chromium/src/+/4111415. The
main difference is that, being C, we don't have std::set or std::map
easily available. But the algorithm can be implemented purely with
sorted lists, while remaining subquadratic.
This implementation relies on two assumptions:
1. We do not return the policy tree. This was removed in
https://boringssl-review.googlesource.com/c/boringssl/+/53327
2. We do not return the final set of certificate policies. I.e.,
certificate policy checking is only used for evaluating policy
constraints and X509_V_FLAG_EXPLICIT_POLICY.
The second assumption is not very important. It mostly simplifies
has_explicit_policy slightly.
In addition, this new implementation removes the per-certificate policy
cache. Instead, we just process the policy extensions anew on
certificate verification. This avoids a mess of threading complexity,
including a race condition in the old logic. See
https://boringssl-review.googlesource.com/c/boringssl/+/55762 for a
description of the race condition.
Change-Id: Ifba9037588ecff5eb6ed3c34c8bd7611f60013a6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56036
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This inline is not defined when OPENSSL_NO_ASM.
Change-Id: I11b90fe4f53281a36674a11dc19c6c61e3afaa68
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56145
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is purely cosmetic, but makes it consistent with the DW, etc.,
lines in the block above. The SEH unwind code support will emit a mix of
DW and DB directives and this makes them look more consistent.
Bug: 259
Change-Id: Ia16166ab2495aa813d6076d55af5b62511933c28
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56125
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This relaxes two caller requirements:
First, although one needs to initialize X509V3_CTX in two parts, some
callers forget to this. This works some of the time on accident,
because most codepaths read ctx->db. But if one were to read it, it'd
be uninitialized. Since all the entrypoints take a CONF anyway, and
always match them, just implicitly initialize the CONF half of the
X509V3_CTX with the provided one.
Second, allow X509V3_CTX to be NULL. Some codepaths in the library
check for NULL (or don't use it) and some do not. Enough codepaths
don't check that it really cannot be considered to work, but enough
do that a caller could mistakenly pass in NULL and have it mostly
work. I've seen one caller mistakenly do this. Since we have to copy
the X509V3_CTX for the first relaxation anyway, allow it to be NULL
and fill in an empty one when omitted.
Update-Note: If using different CONFs in the X509V3_CTX and the function
parameter, the function parameter is now always used. No callers do
this, and it's somewhat arbitrary which is used. (The generic code
always uses the one in ctx. The @section syntax uses the parameter. Then
the per-extension callbacks use the ctx.)
Change-Id: I9fc15a581ea375ea06c4b082dcf0d6360be8144f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56109
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Squat fewer unprefixed macros.
Update-Note: CTX_TEST appears to be unused. If affected, switch to using
X509V3_set_ctx_test instead.
Change-Id: I43b86c0b6f147bbca85b8bc6b43602fc4f6697c1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56108
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Functions typically just push their own error codes.
Change-Id: Iac83bfdf56ce436bd3a9b8af5c43ca67fb4b9b15
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56107
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Our NCONF_get_section doesn't silently handle NULLs, so add a check to
the caller.
Change-Id: I133d10c7a5dec22469a80b78cb45f479f128ada2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56106
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
And specifically that it also counts at the leaf, which was a bug I'd
nearly introduced. (RFC 5280 is written somewhat confusingly. The
wrap-up and prepare procedures have some duplicate processing.)
Change-Id: Iea901b96f64e12199fec426dc936bfbde16f88a4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56035
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Such mappings should be ignored.
Change-Id: Ic75d3c17e3f2d25da75b15d59e38177f9bc1c044
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56034
Reviewed-by: Matt Mueller <mattm@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There is no Kyber implementation in BoringSSL so these stubs assume that
you are locally patching such an implementation in.
Change-Id: I274b9a93e60f0eb74301c8d58f05c235687643e1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55930
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Cost: 6.3KiB, based on the size of the .o file. (The bssl tool size
doesn't really change, probably due to padding somewhere.)
This code originally came from ARM but David has merged the AES-128 and
AES-256 specific code into a function that works across AES sizes.
Speeds from an M1 Pro:
Did 16546000 AES-128-GCM (16 bytes) seal operations in 1000018us (16545702.2 ops/sec): 264.7 MB/s
Did 10450500 AES-128-GCM (256 bytes) seal operations in 1000011us (10450385.0 ops/sec): 2675.3 MB/s
Did 2822500 AES-128-GCM (1350 bytes) seal operations in 1000042us (2822381.5 ops/sec): 3810.2 MB/s
Did 547000 AES-128-GCM (8192 bytes) seal operations in 1000826us (546548.6 ops/sec): 4477.3 MB/s
Did 279000 AES-128-GCM (16384 bytes) seal operations in 1000411us (278885.4 ops/sec): 4569.3 MB/s
Did 16991250 AES-256-GCM (16 bytes) seal operations in 1000001us (16991233.0 ops/sec): 271.9 MB/s
Did 9257000 AES-256-GCM (256 bytes) seal operations in 1000072us (9256333.5 ops/sec): 2369.6 MB/s
Did 2398000 AES-256-GCM (1350 bytes) seal operations in 1000002us (2397995.2 ops/sec): 3237.3 MB/s
Did 465000 AES-256-GCM (8192 bytes) seal operations in 1001108us (464485.4 ops/sec): 3805.1 MB/s
Did 240000 AES-256-GCM (16384 bytes) seal operations in 1002704us (239352.8 ops/sec): 3921.6 MB/s
Did 16670000 AES-128-GCM (16 bytes) seal operations in 1000054us (16669099.9 ops/sec): 266.7 MB/s
Did 11450750 AES-128-GCM (256 bytes) seal operations in 1000014us (11450589.7 ops/sec): 2931.4 MB/s
Did 3830000 AES-128-GCM (1350 bytes) seal operations in 1000097us (3829628.5 ops/sec): 5170.0 MB/s
Did 790000 AES-128-GCM (8192 bytes) seal operations in 1000379us (789700.7 ops/sec): 6469.2 MB/s
Did 400000 AES-128-GCM (16384 bytes) seal operations in 1000980us (399608.4 ops/sec): 6547.2 MB/s
Did 16877000 AES-256-GCM (16 bytes) seal operations in 1000052us (16876122.4 ops/sec): 270.0 MB/s
Did 10438000 AES-256-GCM (256 bytes) seal operations in 1000067us (10437300.7 ops/sec): 2671.9 MB/s
Did 3419000 AES-256-GCM (1350 bytes) seal operations in 1000158us (3418459.9 ops/sec): 4614.9 MB/s
Did 698000 AES-256-GCM (8192 bytes) seal operations in 1000557us (697611.4 ops/sec): 5714.8 MB/s
Did 355000 AES-256-GCM (16384 bytes) seal operations in 1001900us (354326.8 ops/sec): 5805.3 MB/s
Change-Id: Id88f6e14482f09591fe95145bf4089de1ab68380
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55926
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
They don't work because ASN1_mbstring_ncopy doesn't recognize them.
Change-Id: Id036252f4c6790714a73c5d0666149e13050fd4a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56105
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This aligns with upstream OpenSSL, so it's hopefully more compatible.
Code search says no one outside of the project uses this function, so
it's unlikely to break anyone.
Whether it makes things better is a bit of a wash: OBJ_dup and
OPENSSL_strdup loose a pointless wrapper. X509_NAME_dup gains one, but
hopefully that can be resolved once we solve the X509_NAME
const-correctness problem. CRYPTO_BUFFER_up_ref gains one... really
FOO_up_ref should have type const T * -> T *, but OpenSSL decided it
returns int, so we've got to cast.
Change-Id: Ifa6eaf26777ac7239db6021fc1eafcaed98e42c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56032
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These APIs should not be used, but far too many callers use them. In the
meantime, at least test this behavior (so it can be rewritten) and write
down why it should not be used.
In doing so, I noticed that we actually broke some cases in the
ASN1_generate_v3 logic. I think it broke in
https://boringssl-review.googlesource.com/c/boringssl/+/48825. But since
no one's noticed, I've just kept it broken.
Bug: 430
Change-Id: I80ab1985964fc506c8aead579c769f15291b1384
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56029
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
We've removed them in other files.
Change-Id: I14ea99c85fd3a21094beeac88cb669e7aa9e2763
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56028
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Constructing extensions from a config file should not modify the config
file or input certificates, so everything here should be const.
While I'm here, fix various missing sk_FOO_push malloc failure checks.
Change-Id: Ic29b21248a9d9243050c771fd0ce1e1d77f7ce7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56027
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In the X.509 policy rewrite, I'll be using sorted stacks to keep the
overall algorithm subquadratic. Fix up sk_FOO_is_sorted in these edge
cases so the asserts work more smoothly.
Change-Id: I369f53543f0c2219df6f62a81aead630a9dbcd8d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56031
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This adds function to allow for issuing and redeeming tokens derived
from a particular message rather than a completely random nonce.
Change-Id: Ia29ae06ca419405ffff79ab6defadbed4f184b29
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55565
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
We've been setting /Wall on MSVC for a while, but /Wall in MSVC is
really "all". I.e., it's -Weverything in Clang and GCC, and includes
many warnings that are simply diagnostics. MSVC's own headers do not
promise to be clean under /Wall.
Rather, the equivalent of Clang and GCC's -Wall is /W4, which MSVC does
promise to pass. Under /Wall, every new MSVC release we've had to update
an ever-growing list of warning exceptions, to disable the
off-by-default warnings that were off for a reason. Switch to MSVC's
recommendations and just enable /W4.
From there, I've trimmed the exception list, now that we don't need to
re-disable disabled warnings. A few non-disabled warnings also no longer
need exceptions.
This should fix the build with VS2022, which was failing due to C5264.
C5264 flags a couple of instances in the library, but tons and tons in
MSVC headers and googletest. (The instances in the library are a little
goofy and reflect things that should have been 'inline constexpr', but
we can't rely on C++17 yet. Though I may go add a compat macro for
that.)
Fixed: 552
Change-Id: I9031c0d5bd4c7a4df1dc3040b38af9cfbcffc06e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56045
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Without this, it was using the headers from /usr/include, and on my
machine it failed with the following:
```
$ cmake .. -DRUST_BINDINGS=$(gcc -dumpmachine) && make
/boringssl/rust/rust_wrapper.c: In function
‘ERR_GET_FUNC_RUST’:
/usr/local/google/home/yukl/boringssl/rust/rust_wrapper.c:27:10: error:
implicit declaration of function ‘ERR_GET_FUNC’; did you mean
‘ERR_GET_LIB’? [-Werror=implicit-function-declaration]
27 | return ERR_GET_FUNC(packed_error);
| ^~~~~~~~~~~~
| ERR_GET_LIB
```
Change-Id: Ia34830c939f32a8807e1c8be03d962c21dfc1635
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55932
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Adam Langley <agl@google.com>
I did this because I was tired of explaining Grover's algorithm and
circuit depth, but it never large amounts of sense and it conflates any
measurements of post-quantum impact. If you want to configure a server
with a preference for 256-bit ciphers, that's still completely possible.
Change-Id: I3dc951ec724a713bb4da75c204d1105c62de8d74
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55929
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Nothing external ever defines X509V3_CONF_METHOD. Removing this allows
us to remove X509V3_section_free altogether because the returned
sections are always owned by the CONF object anyway.
For ease of review, I've split out some of the const-correctness to a
follow-up CL.
Update-Note: X509V3_CONF_METHOD is removed. Code search says no one uses
this.
Change-Id: I66ed6e978b85d40c6849e9f4f45e1bcbf9a0f6a9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56026
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
These are used inside the various extension implementations and aren't
used outside the library. In doing so, delete a bunch of functions that
aren't used anyway.
Change-Id: I7e4d049682155d20b8ae9bd7c239be96c1261d98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56025
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This is currently called "aesni", but a following change will add
support on Aarch64. This change thus makes the naming more generic.
Change-Id: I6acb135a91e61570ea250f2f4133b47f11cd51ad
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55865
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
(Unclear if we'll get the security policy in docx format this time but
it's always on NIST's site in PDF form.)
Change-Id: I831738b36873c7adafcc74d02748f69c1e94f501
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55931
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Upstream clang has changed how it handles passing -stdlib=libc++ on
Apple platfoms. The rationale is that libc++ is the default standard
library, and stdlibc++ is no longer supported.
A much more detailed rational can be found at
https://reviews.llvm.org/D139938.
Change-Id: I90f5fe8b63075b20e1632275c2751b6aa8a64800
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55928
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Paul Kirth <paulkirth@google.com>
Reviewed-by: Adam Langley <agl@google.com>
anyPolicy causes crypto/x509 to synthesize policy nodes in places. Add
some test coverage for this.
Change-Id: I1b1dcba35088d6cabce6b40e36e478ec4756effa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55753
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If a certificate has policy constraints, but the certificate policies
extension is either missing or unsuitable (in a way not caught by the
parser), the policy constraints object is leaked.
As part of this, add some basic tests for policy constraints.
Change-Id: I4a2c618019d1f92b0f3b9ad4cf6e29d4926e3095
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55752
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
X509 objects do some deferred parsing. Make sure we cover that code with
fuzzers.
Change-Id: I618e90aaf4d8decbc3af59f36910feb9949a8cd2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55751
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
X509_policy_check returns -1 if some certificate had an unparseable
extension, in which case it sets EXFLAG_INVALID_POLICY on it. The
calling code then iterates over the certificates to find the offending
one, so the callback has a chance to undo it. But it skips i = 0, the
leaf, and instead just silentely returns success.
We really should cut down on the callback's ability to mess things up
here but, in the meantime, fix this. Also add a test covering this case.
While I'm here, I've updated make_invalid_extensions.go, which I pulled
some code from, to rename fooOrPanic to mustFoo. That seems to be the
convention in the Go standard library. (regexp.MustCompile, etc.)
Change-Id: Ib07c9f4175e66483bd7c0f7d49aea931bf36e53f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55748
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I inadvertently removed it, but set_string(NULL, str) would validate str
without writing an object. OpenSSL's habit of dual-use functions isn't
great (this behavior masked a bug in another project), but I apparently
even documented it in the header, so restore the behavior.
Change-Id: I8b4dbe5a2b21eb59cb20e4c845b17761329b34a1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55785
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
David Benjamin
Adam Langley
Adam Langley
Steven Valdez
Piotr Sikora
Maurice Lam
Paul Kirth
Ilya Tokar