aboutsummaryrefslogtreecommitdiff
path: root/decrepit
AgeCommit message (Collapse)AuthorFilesLines
2024-03-29Switch EVP_CIPHERs to C99 initializersDavid Benjamin4-48/+75
We're using it in parts of EVP already and this is much more readable. Change-Id: I42f30b83331cafdabd4f5d995b61176458e906bc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67567 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2024-03-20Move ssl and decrepit sources to sources.cmakeDavid Benjamin1-22/+0
Bug: 542 Change-Id: Iec0348555b988f8eb8eb24394a867e015b125c20 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67227 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-16Remove unused app_data from EVP_CIPHERTheo Buehler4-46/+46
This field makes no sense for static const structures. It was added early on but never used as far as I can tell. Change-Id: Ie0272c5f498ad777cb3b114589248d8b403ae457 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67047 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2024-01-26Import upstream's tests for DES_ede3_cfb_encryptDavid Benjamin2-1/+134
Upstream does not actually have any tests for DES-EDE3-CFB, with the exception of a single DES-EDE3-CFB1 test vector, only the single-DES version. But we can gain some coverage by turning 3DES back into single DES with a repeated key. That's good enough for DES. The DES-EDE3-CFB1 test vector is unusable because that tests EVP_des_ede3_cfb1, the real DES-EDE3-CFB1. OpenSSL's low-level APIs do not actually implement CFB correctly for a non-whole-number of bytes! See discussion in the test. I've added coverage for that case by just fabricating a test vector. Change-Id: I9f69cab4d8d1d3accecbeb09f8c1661ce2ecb4ee Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65689 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-11-30Merge <openssl/x509v3.h> into <openssl/x509.h>David Benjamin1-1/+1
Change-Id: I53147d1f96d1f99909f5c8bda00cefb088677a0e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64138 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-10-05Add OPENSSL_zallocDavid Benjamin1-5/+1
OpenSSL added a similar helper function. It's very, very common for us to malloc something an then zero it. This saves some effort. Also replace some more malloc + memcpy pairs with memdup. Change-Id: I1e765c8774a0d15742827c39a1f16df9748ef247 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63345 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-07-18Support Android's "baremetal" targetDavid Benjamin1-2/+3
This corresponds to the libcrypto_baremetal build target in Android, which is an embedded-style platform that uses a subset of the bionic libc. It will also, eventually, use getentropy for its PRNG. As part of this, generalize the OPENSSL_TRUSTY exclusion for file BIOs to OPENSSL_NO_FILESYSTEM. Upstream OpenSSL uses OPENSSL_NO_STDIO, but that excludes all of FILE entirely. We already require FILE in quite a few places (urandom.c, self_test.c) for writing to stderr, and FILE is part of C standard library. So, let's tentatively say that we require you have FILE and stderr. Instead, OPENSSL_NO_FILESYSTEM is saying you don't have fopen. You're still required to have the three std{in,out,err} FILEs, and given a FILE, you need to allow the standard operations on it. (Possibly in forms that always fail.) To keep us honest, whenever a function is excluded, I've dropped it from the header too, and followed callers up the chain. I have not attempted to make the tests work when these are excluded. Later CLs in this series will do the same for NO_SOCK and NO_POSIX_IO. This was a little tedious, but not too bad. (I assume we'll end up changing our minds on this a lot. For now, let's try this.) I haven't yet restored OPENSSL_RAND_TRUSTY or removed the OPENSSL_TRUSTY ifdef on file.c. Having a separate CL makes it a bit easier to revert if something goes wrong. This depends on https://android-review.googlesource.com/c/platform/bionic/+/2659335, which fixes the header bionic uses for getentropy. Bug: 629, b:291102972 Change-Id: Idd839cd3fa4253128de54bd1be7da261dbcdeb7c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61726 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2023-07-16Replace BIO_snprintf with snprintf within the libraryDavid Benjamin1-1/+1
Our BIO_snprintf is just a thin wrapper over the libc one, and we already call it directly in other places. Just call the libc one consistently. Change-Id: Ia7daf26b9789ddcecab67118c4ec4a077aad5a22 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61685 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-07-11Use std::make_unique when possibleDavid Benjamin2-3/+3
We've required C++14 for a while now. As we're mostly C with a little C++, this is less helpful, but may as well avoid bare new where possible. Change-Id: Icf3386e3f3b6f2092bb0089ed874cc50985f1a40 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61429 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-07-05Use sources.cmake for test binariesDavid Benjamin1-14/+0
CMake and the generate builds now broadly share a source of truth for the test files. Update-Note: In the standalone CMake build, build/crypto/crypto_test is now build/crypto_test, etc. For now, the build still copies the outputs to the subdirectories (it's cheap and avoids some workflow turbulence), but I'm thinking we keep that for six months or so and then remove it. Bug: 542 Change-Id: I8f97e1fcedea1375d48567dfd2da01a6e66ec4e8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61286 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-02-15Make boringssl_gtest_main a STATIC libraryDavid Benjamin1-4/+2
Prior to 3.12 (which we won't be requiring until July), OBJECT libraries cannot be used with target_link_libraries. That means they cannot pick up INTERFACE_INCLUDE_DIRECTORIES, which makes them pretty unusable in the "modern CMake" style. Just switch it to a static library to unbreak the build in CMake 3.10. For some link ordering reason I don't understand, this also requires explicitly linking boringssl_gtest to libcxx when we USE_CUSTOM_LIBCXX is set. Change-Id: Ia9d8351551f5da060248aa3ca73fe04473bf62aa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57345 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-02-14Remove global_target from build.David Benjamin1-2/+0
This was added with the generated symbol-prefixing header. But it seems to be sufficient for crypto to have a dependency on the generated header, along with some of the stray bits of delocate. It's a little unclear from CMake documentation how these are processed; normally .o files can be built before libraries are built or linked, only the link step depends on. But, empirically, if A links B, and B has a dependency on C, then CMake seems to run C before building any of A. I tested this by making a small project where the generation step slept for three seconds and running with enough parallelism that we'd have tripped. Interestingly, in the Makefile output, the individual object file targets didn't have that dependency, but the target itself did. But this was true on both A and B, so I think that just might not work. Also fix the dependency in the custom target. The old formulation broke when using an absolute path to the symbols file. Change-Id: I2053d44949f907d465da403a5ec69c191740268f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-02-14Specify -Iinclude with the crypto target.David Benjamin1-6/+0
It's unclear to me whether doing it target-by-target is an improvement in crypto/fipsmodule, but this otherwise does seem a bit tidier. This aligns with CMake's documentation and "modern CMake" which prefers this pattern. Change-Id: I36c81842bff8b36eeaaf5dd3e0695fb45f3376c9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56585 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-02-07Trim unnecessary -lrt and ws2_32 deps in the build.David Benjamin1-3/+0
The ws2_32 dependency comes from BIO, which is in libcrypto. Once it's added there, it should get inherited by anything downstream, so we don't need to keep listing it. We also no longer need -lrt. We tried to remove it in https://boringssl-review.googlesource.com/4622, but had to revert it in https://boringssl-review.googlesource.com/4894 because of clock_gettime. clock_gettime, per the Linux man page, is now in libc, not librt, as of glibc 2.17. THat was released December 2012, well past our five year watermark, so clean this part of the build up. Change-Id: Ie6a07434b0cb02fe916b32ab8c326ec33d40bcb6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56606 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-01-31Fix stray */s in // line comment license headersDavid Benjamin3-3/+3
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>
2023-01-17Further const-correct config-based extension creation.David Benjamin1-2/+3
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>
2022-12-09Finish porting dh_test.cc and ripemd_test.cc to GTest.David Benjamin1-20/+5
They're the only two half-finished ports left, so we may as well finish that up and trim them down a little. Change-Id: Ic058124a44086161ab5d2d6fa24448492c3ba219 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55506 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2022-11-14More -Wshorten-64-to-32 fixes.David Benjamin1-41/+39
I had a rewrite of the decrepit ciphers (CAST and Blowfish) to use CRYPTO_{load,store}_u32_be and drop the old macros, but this is probably not worth the effort to review. Instead, just fix the type in the macro. Bug: 516 Change-Id: I1cdecc16f6108a6235f90cf9c2198bc797c6716e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54985 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-10-13Switch RSA_sign to size_t.David Benjamin1-2/+2
While I'm here, use a fixed-size uint64_t in RSA_generate_key, rather than unsigned long. This code also assumes unsigned long fits in BN_ULONG, which is probably true on all platforms we care about, but unnecessarily fussy. The RSA_sign -> RSA_METHOD transition does require a cast. Go ahead and check length/hash_nid consistency so we know it fits in the cast. This does mean RSA_METHOD-backed keys are restricted to implementing digests that we support, but that's probably fine. If anything, I think we should try to shift away from RSA_METHOD as a story for custom keys. Bug: 516 Change-Id: I3969da67d1daeff882279a534eb48ca831eb16cd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54465 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2022-05-26Make EVP_CIPHER opaque.David Benjamin4-1/+5
If we're to have any hope of fixing EVP_CIPHER_CTX's calling convention, we need to be able to change the shape of its method table. Looking back, it looks like we exported this in https://boringssl-review.googlesource.com/4330, for OpenSSH. I don't remember exactly what OpenSSH was doing, but I see in this commit, they removed a bunch of custom EVP_CIPHERs which would definitely have required an exported EVP_CIPHER struct: https://github.com/openssh/openssh-portable/commit/cdccebdf85204bf7542b7fcc1aa2ea3f36661833 That's been gone for a while now, so hopefully we can hide it again. (If a project needs a cipher not implemented by OpenSSL, it's not strictly necessarily to make a custom EVP_CIPHER. It might be convenient to reuse the abstraction, but you can always just call your own APIs directly.) Update-Note: EVP_CIPHER is now opaque. Use accessors instead. Bug: 494 Change-Id: I9344690c3cfe7d19d6ca12fb66484ced57dbe869 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52725 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2022-02-14Move DES out of the FIPS module.Adam Langley1-1/+1
FIPS no longer likes it. Change-Id: I32a4ba93a5849927ff75aa72b816cdc669e8a0af Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51325 Reviewed-by: David Benjamin <davidben@google.com>
2021-10-05Extract common rotl/rotr functions.David Benjamin2-31/+23
We have a ton of per-file rotation functions, often with generic names that do not tell you whether they are uint32_t vs uint64_t, or rotl vs rotr. Additionally, (x >> r) | (x << (32 - r)) is UB at r = 0. (x >> r) | (x << ((-r) & 31)) works for 0 <= r < 32, which is what cast.c does. GCC and Clang recognize this pattern as a rotate, but MSVC doesn't. MSVC does, however, provide functions for this. We usually rotate by a non-zero constant, which makes this moot, but rotation comes up often enough that it's worth extracting out. Some particular changes to call out: - I've switched sha256.c from rotl to rotr. There was a comment explaining why it differed from the specification. Now that we have both functions, it's simpler to just match the specification. - I've dropped all the inline assembly from sha512.c. Compilers should be able to recognize rotations in 2021. Change-Id: Ia1030e8bfe94dad92514ed1c28777447c48b82f9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49765 Reviewed-by: Adam Langley <agl@google.com>
2021-09-24Keep EVP_CIPHER/EVP_MD lookup and do_all functions in syncDavid Benjamin2-0/+46
Node seems uncommonly sensitive to this, so let's write these functions in a way that stays in sync and test this. See also https://boringssl-review.googlesource.com/c/boringssl/+/49585 This does incur a cost across all BoringSSL consumers that use these functions: as a result of Node indiscriminately exposing every cipher, we end up pulling more and more ciphers into these getters. But that ship sailed long ago, so, instead, document that EVP_get_cipherby* should not be used by size-conscious callers. EVP_get_digestby* probably should have the same warning, but I've left it alone for now because we don't quite have the same proliferation of digests as ciphers. (Though there are things in there, like MD4, that ought to be better disconnected.) Change-Id: I61ca406c146279bd05a52bed6c57200d1619c5da Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49625 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2021-08-30Include SHA512-256 in EVP_get_digestbyname and EVP_MD_do_all.David Benjamin1-0/+2
Change-Id: I25a1a58589ec8843da4d1955d8fec38561f13ec9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49125 Reviewed-by: Adam Langley <agl@google.com>
2021-07-01Add some OpenSSL compatibility aliases.David Benjamin1-0/+6
EVP_MD_nid, in OpenSSL, is the same as EVP_MD_type. EVP_MD_type seems to be the preferred spelling, so put EVP_MD_nid in the deprecated bucket. Also add an EVP_MD_do_all alias to EVP_MD_do_all_sorted. Change-Id: I4e7b800902459ac5cb9ef0df65d73da94afdf927 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48365 Reviewed-by: Adam Langley <agl@google.com>
2021-06-01Make md32_common.h single-included and use an unsized helper for SHA-256.David Benjamin1-24/+18
Similar to https://boringssl-review.googlesource.com/c/boringssl/+/46405, SHA256_Final and SHA224_Final hit array size warnings in the new GCC. The array sizes are, strictly speaking, purely decoration, but this is a good warning so we should be clean with it on. That same change is difficult to apply to md32_common.h because md32_common.h generates the functions for us. md32_common.h is already strange in that it is multiply-included and changes behavior based on macros defined by the caller. Instead, replace it with inline functions, which are a bit more conventional and typesafe. This allows each hash function to define the function prototype. Use this to add an unsized helper for SHA-256. Bug: 402 Change-Id: I61bc30fb58c54dd40a55c9b1ebf3fb9adde5e038 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47807 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Peter Foley <pefoley@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-06-01Pull HASH_TRANSFORM out of md32_common.h.David Benjamin1-1/+5
The macro isn't doing any work here. Change-Id: Id97dfa4b027407c5e4b3e7eb1586c3c2a2d977d8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47806 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-04-02Fold ripemd/internal.h into ripemd.c.David Benjamin2-497/+423
It's only used from that file and, given the names defined by it, probably isn't usable by other files anyway. Change-Id: Ice205408962ade00c1dcb51406da3ef2fd7f0393 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46426 Reviewed-by: Adam Langley <agl@google.com>
2021-04-02Move load/store helpers to crypto/internal.h.David Benjamin2-46/+48
We have loads of variations of these. Align them in one set. This avoids the HOST_* macros defined by md32_common.h, so it'll be a little easier to make it a more conventional header. Change-Id: Id47fe7b51a8f961bd87839f8146d8a5aa8027aa6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46425 Reviewed-by: Adam Langley <agl@google.com>
2021-01-07A handful more compatibility functions.Adam Langley2-4/+36
Change-Id: I814f55742910c519e9b64aca1b15a4d754adc541 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44944 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2021-01-07Add some OpenSSL-compatibility aliasesAdam Langley1-0/+2
Change-Id: I808f37c2980e36843b5b5d29174b4f27a030738a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44924 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2020-11-06Const-correct various X509 string parameters.David Benjamin1-1/+1
Change-Id: Iceaed077d072a51b67b8cda8f363d2d8f8d1762d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43886 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2020-06-22Remove uneeded switch statement.Pete Bentley1-8/+1
Warnings for switch statements with just a default case are now fatal with the latest Windows toolchain used by Github workflows. So indirectly this was breaking Conscrypt's continuous integration and possibly other projects using BoringSSL which run CI on Windows. Example: https://github.com/google/conscrypt/runs/793502854?check_suite_focus=true Change-Id: Ia09b86f3292299089c6536862a170677a8024984 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41844 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2020-01-03Add some XTS tests.David Benjamin2-0/+269
For some reason, these also fail with the reverted aes_nohw on 32-bit Android. (Still trying to figure out why that happens.) Change-Id: Ia9ef34e97b473585424120620b1d937220cd2c31 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39305 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-09-16Add AES-256 CFB to libdecrepit.Shelley Vohr2-7/+45
Electron builds Node.js with BoringSSL. They want to match OpenSSL as much as possible and thus have a patch[1] that adds AES-256 CFB mode. However, that patch makes libcrypto depend on libdecrepit, which can't be done in general. This change lands the AES-256 CFB support in libdecrepit without the libcrypto bit and, in order for BoringSSL to remain consistent, without advertising support in EVP_CIPHER_do_all_sorted. This will let Electron reduce the size of their patch a bit. [1] https://github.com/electron/electron/blob/master/patches/boringssl/expose_aes-cfb.patch Change-Id: If628d22a595b354623439c587542e414e43e4045 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37264 Reviewed-by: Adam Langley <agl@google.com>
2019-06-04Fix name clash in test structuresJulien Desgats2-4/+4
Revealed by -lfto linking. Creating multiple classes with the same name but different contents is illegal. Change-Id: I184c34235f4f11e94d47dee1ca2d1a97de55d6ba Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36304 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2019-04-08Rename 'md' output parameter to 'out' and add bounds.David Benjamin2-4/+6
We usually name output parameters 'out'. (Someone made a C++ templating change in Chromium which messed up const-ness, saw the compile error, and thought it was in MD5_Final.) Also tag the parameters with the sizes. Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and SHA384_Final/SHA512_Final, but they're just documentation anyway. (Though it does touch on the mess that is sha->md_len which would be nice to clear through somehow.) Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-02-14Remove non-STRICT_ALIGNMENT code from xts.c.David Benjamin1-20/+0
Independent of the underlying CPU architecture, casting unaligned pointers to uint64_t* is undefined. Just use a memcpy. The compiler should be able to optimize that itself. Change-Id: I39210871fca3eaf1f4b1d205b2bb0c337116d9cc Reviewed-on: https://boringssl-review.googlesource.com/c/34872 Reviewed-by: Adam Langley <agl@google.com>
2019-02-11sync EVP_get_cipherbyname with EVP_do_all_sortedJeremy Apthorp1-8/+20
EVP_get_cipherbyname should work on everything that EVP_do_all_sorted lists, and conversely, there should be nothing that EVP_get_cipherbyname works on that EVP_do_all_sorted doesn't list. node.js uses these APIs to enumerate and instantiate ciphers. Change-Id: I87fcedce62d06774f7c6ee7acc898326276be089 Reviewed-on: https://boringssl-review.googlesource.com/c/33984 Reviewed-by: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2019-01-03Set NIDs for Blowfish and CAST.Adam Langley2-5/+5
I hadn't thought that we still had the NIDs for these, but it appears that we do. In which case, might as well set them. Change-Id: I0d459ecacda95298c7ef345b73639cc02c74914f Reviewed-on: https://boringssl-review.googlesource.com/c/34045 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2019-01-03Add a CFI tester to CHECK_ABI.David Benjamin1-2/+2
This uses the x86 trap flag and libunwind to test CFI works at each instruction. For now, it just uses the system one out of pkg-config and disables unwind tests if unavailable. We'll probably want to stick a copy into //third_party and perhaps try the LLVM one later. This tester caught two bugs in P-256 CFI annotations already: I47b5f9798b3bcee1748e537b21c173d312a14b42 and I9f576d868850312d6c14d1386f8fbfa85021b347 An earlier design used PTRACE_SINGLESTEP with libunwind's remote unwinding features. ptrace is a mess around stop signals (see group-stop discussion in ptrace(2)) and this is 10x faster, so I went with it. The question of which is more future-proof is complex: - There are two libunwinds with the same API, https://www.nongnu.org/libunwind/ and LLVM's. This currently uses the system nongnu.org for convenience. In future, LLVM's should be easier to bundle (less complex build) and appears to even support Windows, but I haven't tested this. Moreover, setting the trap flag keeps the test single-process, which is less complex on Windows. That suggests the trap flag design and switching to LLVM later. However... - Not all architectures have a trap flag settable by userspace. As far as I can tell, ARMv8's PSTATE.SS can only be set from the kernel. If we stick with nongnu.org libunwind, we can use PTRACE_SINGLESTEP and remote unwinding. Or we implement it for LLVM. Another thought is for the ptracer to bounce SIGTRAP back into the process, to share the local unwinding code. - ARMv7 has no trap flag at all and PTRACE_SINGLESTEP fails. Debuggers single-step by injecting breakpoints instead. However, ARMv8's trap flag seems to work in both AArch32 and AArch64 modes, so we may be able to condition it on a 64-bit kernel. Sadly, neither strategy works with Intel SDE. Adding flags to cpucap vectors as we do with ARM would help, but it would not emulate CPUs newer than the host CPU. For now, I've just had SDE tests disable these. Annoyingly, CMake does not allow object libraries to have dependencies, so make test_support a proper static library. Rename the target to test_support_lib to avoid https://gitlab.kitware.com/cmake/cmake/issues/17785 Update-Note: This adds a new optional test dependency, but it's disabled by default (define BORINGSSL_HAVE_LIBUNWIND), so consumers do not need to do anything. We'll probably want to adjust this in the future. Bug: 181 Change-Id: I817263d7907aff0904a9cee83f8b26747262cc0c Reviewed-on: https://boringssl-review.googlesource.com/c/33966 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-01-03Fix some size_t to long casts.David Benjamin2-18/+22
Maybe someday we'll be able to turn on that warning. (The EVP_CIPHER hooks take size_t while the functions took long.) Change-Id: Ic4da44efca9419a7f703e232d3f92638eb4ab37a Reviewed-on: https://boringssl-review.googlesource.com/c/34084 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-01-03Add EVP_CIPHER support for Blowfish and CAST to decrepit.Adam Langley5-1/+475
Postgres contains a “pqcrypto” module that showcases the worst of 90's crypto, including Blowfish and CAST5 in CFB, CBC, and ECB modes. (Also, 64-bit keys for both of those.) In order to minimise the patching needed to build Postgres, put these things in decrepit. Change-Id: I8390c5153dd7227eef07293a4363878d79df8b21 Reviewed-on: https://boringssl-review.googlesource.com/c/34044 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2018-10-17Undo recent changes to |X509V3_EXT_conf_nid|.Adam Langley1-2/+6
cryptography.io wraps this function and so we have to keep the LHASH_OF argument for now. Change-Id: I4e071dee973c3931a4005678ce4135161a5861bd Reviewed-on: https://boringssl-review.googlesource.com/c/32524 Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-10-01Remove LHASH_OF mention in X509V3_EXT_conf_nid.David Benjamin1-23/+3
Everyone calls this with NULL anyway. People never actually use lh_CONF_VALUE_* functions (or any other lh_* functions for that matter). Also remove unused X509V3_EXT_CRL_add_conf prototype. This removes one of the last mentions of LHASH_OF in public headers. Update-Note: X509V3_EXT_conf_nid calls that pass a non-NULL first parameter will fail to compile. Change-Id: Ia6302ef7b494efeb9b63ab75a18bc340909dcba3 Reviewed-on: https://boringssl-review.googlesource.com/32117 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2018-10-01Fix undefined block128_f, etc., casts.David Benjamin1-10/+10
This one is a little thorny. All the various block cipher modes functions and callbacks take a void *key. This allows them to be used with multiple kinds of block ciphers. However, the implementations of those callbacks are the normal typed functions, like AES_encrypt. Those take AES_KEY *key. While, at the ABI level, this is perfectly fine, C considers this undefined behavior. If we wish to preserve this genericness, we could either instantiate multiple versions of these mode functions or create wrappers of AES_encrypt, etc., that take void *key. The former means more code and is tedious without C++ templates (maybe someday...). The latter would not be difficult for a compiler to optimize out. C mistakenly allowed comparing function pointers for equality, which means a compiler cannot replace pointers to wrapper functions with the real thing. (That said, the performance-sensitive bits already act in chunks, e.g. ctr128_f, so the function call overhead shouldn't matter.) But our only 128-bit block cipher is AES anyway, so I just switched things to use AES_KEY throughout. AES is doing fine, and hopefully we would have the sense not to pair a hypothetical future block cipher with so many modes! Change-Id: Ied3e843f0e3042a439f09e655b29847ade9d4c7d Reviewed-on: https://boringssl-review.googlesource.com/32107 Reviewed-by: Adam Langley <agl@google.com>
2018-09-06Support symbol prefixesJoshua Liebow-Feeser1-0/+4
- In base.h, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols.h - In all .S files, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols_asm.h - In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are defined with appropriate values depending on whether BORINGSSL_PREFIX is defined; these macros are used in place of 'namespace bssl {' and '}' - Add util/make_prefix_headers.go, which takes a list of symbols and auto-generates the header files mentioned above - In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS are defined, run util/make_prefix_headers.go to generate header files - In various CMakeLists.txt files, add "global_target" that all targets depend on to give us a place to hook logic that must run before all other targets (in particular, the header file generation logic) - Document this in BUILDING.md, including the fact that it is the caller's responsibility to provide the symbol list and keep it up to date - Note that this scheme has not been tested on Windows, and likely does not work on it; Windows support will need to be added in a future commit Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2 Reviewed-on: https://boringssl-review.googlesource.com/31364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-09-05Flatten the decrepit target.David Benjamin16-168/+17
https://boringssl-review.googlesource.com/c/boringssl/+/31364 wants to add a dependency to each target, which is much easier with fewer of them. Start with decrepit. Change-Id: Ib3777063d545dfebe3e2b8448eb7e5bbb5c3aaac Reviewed-on: https://boringssl-review.googlesource.com/31584 Reviewed-by: Adam Langley <agl@google.com>
2018-08-28Clarify thread-safety of key objects.David Benjamin1-3/+3
This often causes confusion since, for various silly reasons (intrinsic ref-counting, FOO_METHOD, and RSA's cached Montgomery bits), the thread safety of some functions don't match the usual const/non-const distinction. Fix const-ness where easy and document it otherwise. Change-Id: If2037a4874d7580cc79b18ee21f12ae0f47db7fd Reviewed-on: https://boringssl-review.googlesource.com/31344 Reviewed-by: Ryan Sleevi <rsleevi@chromium.org> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-08-10Align on a single CMake style.David Benjamin1-1/+1
We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
generated by cgit v1.1 at 2024-06-29 01:53:11 +0000