Merge BoringSSL through 7b9b9baa95449d49019f7ce45b94963f8763005f #1656
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <[email protected]> Reviewed-by: Adam Langley <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Bob Beck <[email protected]>
Change-Id: I81ae040c23ff07cac9156456ba7050dc35775608 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56387 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
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 <[email protected]> Reviewed-by: Adam Langley <[email protected]>
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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: Steven Valdez <[email protected]> Auto-Submit: Steven Valdez <[email protected]>
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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Bob Beck <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]> Auto-Submit: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]> Auto-Submit: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]>
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 golang/go#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 <[email protected]> Reviewed-by: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Adam Langley <[email protected]>
gopls was warning about this. Change-Id: Ida8ff67bcb9ada253fb075a8a800cbefd432ca8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56545 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
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 grpc/grpc#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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: Bob Beck <[email protected]> Auto-Submit: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]> Auto-Submit: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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 <[email protected]> Commit-Queue: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]>
The outl <= 0, etc., checks are actually redundant with logic in the wrappers, but it seems easier to just add the check and avoid worrying about it. Maybe someday we'll make the internals use size_t and this will be moot. Bug: 516 Change-Id: I0bea5ac325c79b9765d822c816661fe4f2bcd4cc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58546 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]>
Normally these would be size_t, but we try to reduce per-connection memory in libssl, so use uint8_t, then add asserts, checks, and casts as appropriate. Bug: 516 Change-Id: Ibdd9d88f2b05173daee2db5f6fb77d619302bfdf Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58547 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]>
…eturn 0 Change-Id: I4288988f3742f14b15f80a3023b716392a667631 Signed-off-by: wangjiale3 <[email protected]> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58485 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
We support BIO_gets on three BIOs. They're all slightly different. File BIOs have the NUL truncation bug. fd BIOs swallow the embedded newline. This CL fixes the second issue and updates the BIO_gets test to cover all three. See also upstream's openssl/openssl#3442 Update-Note: BIO_gets on an fd BIO now returns the newline, to align with memory and file BIOs. BIO_gets is primarily used in the PEM parser, which tries to tolerate both cases, but this reduces the risk of some weird bug that only appears in fd BIOs. Change-Id: Ia8ffb8c67b6981d6ef7144a1522f8605dc01d525 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58552 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Change-Id: Idcf0fdcc88af509958e56052c1925f3f695bc3e3 Signed-off-by: wangjiale3 <[email protected]> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58487 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Change-Id: I06773ff0c42c68f1f2d4c581f52b71008c4cdb3c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58625 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]> Auto-Submit: Adam Langley <[email protected]>
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 <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Bob Beck <[email protected]>
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 <[email protected]> Reviewed-by: Bob Beck <[email protected]>
Change-Id: I43dd18f7d70ee06ca25affad0ab06e5d5ef8263d Signed-off-by: wangjiale3 <[email protected]> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58489 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]>
The *ring* counterpart to `copy_from_prebuf` is `LIMBS_select_512_32` which is already written very (too?) conservatively w.r.t. compiler- introduced side channels. I inspected the generated code before/after adding additional `value_barrier_w` and it made no difference.
We don't have padding.c yet.
*ring* doesn't use bn/generic.c. Instead it uses limbs.c. Likely we need to optimize limbs.c but not now.
…ds assembly for aarch64. Bring in the new code as we'll likely use it soon, but not now. Merged as-is except with the "arm_arch.h" include changed to what we need.
*ring* doesn't use bn/generic.c.
*ring* doesn't incoroprate the ABI tests (unfortunately).
*ring* already had removed the code.
|
I compared the changed files with those of 7b9b9ba and verified that they differ by only what's expected: removed code, and using "ring-core/" instead of "openssl/" as the include prefix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.