aboutsummaryrefslogtreecommitdiff
path: root/gen/sources.json
AgeCommit message (Collapse)AuthorFilesLines
11 hoursAdd some compatibility symbolsDavid Benjamin1-0/+1
Change-Id: Ia07aa88be217a73846b0dc12f360cd1aaafcfaba Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69168 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
4 daysExtract SHA224/256 from bcmBob Beck1-0/+1
Change-Id: I953441ccf99321184a5b664cc446551fa5e295b4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70947 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com>
5 daysAdd SLH-DSA-SHA2-128s from FIPS 205.Adam Langley1-0/+17
Change-Id: I4844f20f6989be2d7fbe9687d9f8fc2c70f0d0f9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70907 Reviewed-by: David Benjamin <davidben@google.com>
7 daysExtract SHA1 from bcmBob Beck1-0/+2
This makes sha1 be internal to bcm other than the shared (public) SHA_CTX structure and lengths. Change-Id: Ib30e0e54a988e6c74a171ecf1fb400e70a9187b0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70567 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com>
11 daysExtract MD5 from bcmBob Beck1-10/+10
MD5 is no longer approved as part of fips, so we move it to digest_extra. Change-Id: I504c3d0d381cba72345c615209b99d4451886d96 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70727 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com> Auto-Submit: Bob Beck <bbe@google.com>
12 daysExtract md4 from bcmBob Beck1-1/+1
This isn't part of fips, so we move it to digest_extra Change-Id: Ia9aeb81c314bdb34c6c9bd567242c90821f372d0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70707 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com>
13 daysRename SPX files to have `spx_` prefix.Adam Langley1-11/+11
We can't have two source files with the same name, it seems, so since crypto/spx/ will be going away, move its files out of the way so that SLH-DSA can use those names. Change-Id: Iedee8453cb77291eeff5ec33aa9836ea5d00d9a2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70908 Auto-Submit: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-08-29Rename bcm.c fragments to foo.c.incDavid Benjamin1-74/+74
Having the files named .c but included causes a ton of problems with build systems. Many of our build systems care about three categories of files: - public headers, available to downstream targets - source files, each of which is compiled as a compilation unit - internal headers, not available to downstream targets There is usually a check, in Bazel called layering_check that enforces source files only include headers that are declared somewhere appropriate. The bcm.c fragments, under this classification, are internal headers. However, in both GN and Bazel, internal headers and sources both go in the source list. They are distinguished only by file extension. When FIPS fragments have a .c file extension, they are misinterpreted as source files, and many things break. Rename them. Either .h and .inc would be sufficient. Because we had to disable Bazel's parse_headers feature, there is no difference (AFAICT) in their handling. Also, these files actually pass the parse_headers feature, even though they don't have an include guard. Still, the tech of the style guide suggests that .inc is probably the better file extension. https://google.github.io/styleguide/cppguide.html#Self_contained_Headers I used .c.inc rather than plain .inc so that we can easily rename them back to .c when we solve https://crbug.com/362530616. Note that, as .inc is not as common of a file extension, people working on BoringSSL may need to reconfigure their editors to map .inc to C/C++. Update-Note: Some downstream builds have been working around this by building the fragments individually and excluding bcm.c. This change will break those workarounds but also remove the need for it. It should now be consistently possible to build BoringSSL without modifying the file list. Bug: 362664827 Change-Id: I933115c37843317a066e24a1092728c9afce35f5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70689 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-08-29Fix some mistakes in build.jsonDavid Benjamin1-1/+1
aes/internal.h got removed on accident in some reshuffling. All this also really should be under the bcm target, rather than the crypto target, but we'll sort that out later. Also rand_test.cc got duplicated. Change-Id: If77f1ff6149a764ccf96073166a5520b284b2dc7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70768 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-08-29Move fork detection support out of bcmBob Beck1-3/+3
This moves fork detection itself back into libcrypto. BCM itself retains only the API to access the generation number to know if stiring in more entropy is needed because a fork happened. Bug: 723 Change-Id: I9b38440e7243119de97f9c4653f0e91d71107501 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68967 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-08-29Move urandom and OS entropy support out of BCMBob Beck1-4/+6
BCM uses only passive entropy, in that from BCM's point of view, entropy is requested and obtained from an external source, and fed to BCM's CTR_DRBG as required. With this change entropy is always gathered in an OS specific manner outside of BCM by libcrypto, while the CTR_DRBG remains in BCM using that entropy. BCM functions (but not yet the tests!) now no longer use the public RAND_bytes function, but instead use BCM_rand_bytes which uses the BCM module CTR_DRBG. BCM_rand_bytes is in turn used by libcrypto to implement the public RAND_bytes function. All public RAND_ functions are now implemented in rand_extra. As part of this two new headers are introduced to start defining the interface boundary between libcrypto and BCM. crypto/bcm_support.h <- Functions implemented by libcrypto and used by bcm fipsmodule/bcm_interface.h <- Functions implemented by bcm and used by libcrypto. Bug: 723 Change-Id: I6b618dfe4df257f67971e88cbd79126c837e21d6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68147 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-08-26Specify the list of Rust files with build.jsonDavid Benjamin1-0/+30
In principle this should be derivable from lib.rs directly, but Rust made this surprisingly difficult, so we'll just do it with wildcards. Bug: 42290412 Change-Id: I3153613bdddf62eaa0e752a4a24192e2c484a95c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70428 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-08-22Specify the list of fuzzers with build.jsonDavid Benjamin1-0/+36
This is a bit of a mess because we actually build each fuzzer as a separate target, but ah well. Migrating to FuzzTest will resolve that. Bug: 42290412 Change-Id: Ia32287ce8b5947a339e966df9e55e2afabed08c1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70427 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2024-08-21Add ML-KEM.Adam Langley1-0/+14
This change implements FIPS 203. This marks the first use of C++ in libcrypto. If you can't compile C++ in this context, please reach out to boringssl@ and filter out the .cc files for now. This also makes marshaling a private key an internal function and, instead, exposes the seed from the generation process and a function to calculate a private key from a seed. Seeds are significantly smaller than NIST's format for private keys and don't require validation. On an M1 Pro: Did 22320 Kyber generate + decap operations in 1001900us (22277.7 ops/sec) Did 39000 Kyber parse + encap operations in 1005523us (38785.8 ops/sec) Did 22608 ML-KEM-768 generate + decap operations in 1010509us (22372.9 ops/sec) Did 44000 ML-KEM-768 parse + encap operations in 1013729us (43404.1 ops/sec) Did 15410 ML-KEM-1024 generate + decap operations in 1011500us (15234.8 ops/sec) Did 29000 ML-KEM-1024 parse + encap operations in 1003919us (28886.8 ops/sec) Change-Id: Ib563bd4d45228237b55cedbe7d7fdf0f0221a3cc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69928 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2024-08-19Add ML-DSA.Adam Langley1-0/+8
This change implements FIPS 204. Change-Id: I0043850767c93cc7235a15c701798fee6e1af1bf Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69987 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2024-05-29Revert "Move unit tests out of bcm/fipsmodule"Bob Beck1-16/+16
This reverts commit e09fcf8302f75dc50afcfe40f0d59a92b40a3c2e. Change-Id: Ib15912481ac25fd60e7e4806d9b6bd5be8e62db8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68809 Auto-Submit: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-05-29Revert "Also extract the test data files from bcm"Bob Beck1-20/+20
This reverts commit 5326e94dd188beba0a5e536b1d2723aee65bd85d. Change-Id: Ieb7fafaf9ca553330620f3f5c30fb69d54bdb8aa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68808 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: Bob Beck <bbe@google.com>
2024-05-29Also extract the test data files from bcmBob Beck1-20/+20
Put them in the same places as the tests moved to. Bug: 772 Change-Id: Id89de2e7418edcf3349e33ec1880ae8d2285312d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68827 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-05-28Move unit tests out of bcm/fipsmoduleBob Beck1-16/+16
Strictly speaking this does not change any of the bcm/fipsmodule code, it moves the tests out into libcrypto so that once we move to an api boundary where bcm does not call libcrypto functions directly, these tests still can do so. Bug: 722 Change-Id: I9defc70a9e523e52dda2d53ab4bd155a4b44fc02 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68787 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-05-22Add edge-case tests for Dilithium, and fix a bug that sneaked in withGuillaume Endignoux1-0/+2
the constant-time transformation. Change-Id: If8e9af65f4f02d695212ce449a2de82ec4a4e7c5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68668 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2024-05-16Move fiat_p256_adx assembly to the right build targetDavid Benjamin1-4/+4
Change-Id: Ib06552aea216af191b172bb062c53f592720041a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68547 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2024-05-15Fix the Bazel buildDavid Benjamin1-1/+1
The good news is we now have a way to test mistakes in the header lists standalone. The bad news is we don't run it on CI. Change-Id: Ie9e6efeb7922374efa38f8e4e8aab85174424f26 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68469 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2024-05-09Add verify.cc and verify.h as top level public API.Bob Beck1-1/+11
Not the end of a public API, but rather a beginning as this one has successful consumers. This is an adaptation of google3 verify.cc with the primary differences being: - No custom error code conversions are provided. when google3 is switched to use this the conversions for absl, sts, and trawler will be re-done and kept in third_party/chromium_certificate verifier. - No CRL or certificate revocation functionality is yet provided. (This comes via the delegate, we can consider exposing a way to to do this later) Bug: 660, b:323560158 Change-Id: Id5f36f792ca0f6d61298e6bb239bf51b1b6b40da Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64847 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2024-05-08Re-apply dilithium and make it work with a limited stackBob Beck1-0/+5
This reverts commit a56407d27da6ebf63ae9817dc19587a0ae98ef4a. On top of this it then makes changes to make dilithium work without consuming excessive stack space.. This makes DILITHIUM_sign and DILITHIUM_generate_key and friends fallible for malloc failures. It removes the abort() calls that were previously present if CBB allocations did not work and rolls them into the malloc failure case. Change-Id: Ibcd70a98bb500c76df8885c0a7d06f8e9f5b18c3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67027 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Guillaume Endignoux <guillaumee@google.com> Reviewed-by: Sophie Schmieg <sschmieg@google.com>
2024-04-26Add a standalone Bazel buildDavid Benjamin1-0/+4
Now that we can generate build files, we can actually maintain a Bazel build in HEAD, without synthesizing a separate "-with-bazel" branch. (Though we'll still need both for a transition, and until all the other build modes have migrated.) Note this has a slightly different directory structure than the old -with-bazel branch. But the targets are the same and #include <openssl/whatever.h> still works, so hopefully it's compatible. For now, I'm only setting this up with the new bzlmod scheme. Also since pulling in googletest is much less tedious with bzlmod, I've wired up tests and everything. https://bazel.build/external/overview#bzlmod To build, run commands like: bazelisk build ... bazelisk test ... bazelisk run :bssl The thinking is we can also go add this to CI and whatnot. This is also intended to replace the boringssl module in the bazel-central-registry which someone else set up already. To ease the transition, I've seeded the compatibility_level value with theirs. (I think we want to never bump it. Although we don't do SemVer, I think bzlmod's MVS version selection scheme is generally reasonable. Bumping it just introduces hiccups into the update process where projects need to coordinate updates, and we do not want that.) I wasn't clear on what to put in the version field in the tree, so I just went with 0.0.0-dev so we don't have to change it, but it's still vaguely analogous to the versions already in there. As part of this, I've added support for Bazel's runfiles mechanism in crypto/test/test_data.cc. This is completely undocumented and I had to figure out how it works by guessing, but I believe this is the officially supported way to make cc_test(data = ...) work? The official documentation says to use devtools_build::GetDataDependencyFilepath, but that API does not exist in the first place. I've also made it build with C++17 for now, so we can build libpki, but C++14 consumers should still be able to use this module, just not build libpki. To that end, one difference between this and the old module is that we no longer specify the C++ version in the build. From what I can tell, Bazel does *not* want libraries to set the C/C++ version and prefers it only come from the root. Unfortunately, they provide zero tools to effectively manage this. I've followed this pattern for C++ versions, as we can assume that Bazel projects are very aware of their C++ version, but I've explicitly ignored it for the C version. Projects tend not to change ABIs by C version, so it should be fine to set it internally. For context when reviewing, the unreadable MODULE.bazel.lock is automatically generated. I think the idea is that subsequent diffs will be more readable?? Bug: 542 Change-Id: I88f68b2602a75f58cc6d18832a956f01dc054f58 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67301 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-04-23short-circuit verification on invalid SPKIMatt Mueller1-0/+2
Change-Id: I6bd3973bfabd99b4ef1725c761a994a9e8cd5cac Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67889 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Matt Mueller <mattm@google.com>
2024-04-22Add a CLIENT_AUTH_STRICT_LEAF and SERVER_AUTH_STRICT_LEAF whichBob Beck1-0/+10
do STRICT requirements on the leaf certificate, and not STRICT on the rest of the chain. Bug: 721 Change-Id: Ieec5940c0ab40aa7ea9e8fe192e5734326b976c3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67787 Reviewed-by: David Benjamin <davidben@google.com> Auto-Submit: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-03-29Add missing public header for libpkiDavid Benjamin1-1/+2
Some CLs crossed in-flight. Change-Id: Id98cfb7c5af67275b99df627534a633f9ae3d14a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67587 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>
2024-03-23Move fips_fragments into bcm.internal_hdrs in build.jsonDavid Benjamin1-0/+78
This is sliiiightly weird because we can't quite decide whether these are headers with the wrong extension or standalone C files. But since most of our build does the former, I've done this for now. I expect we'll need to iterate on this one a bit. Bug: 542 Change-Id: Ib50332c0804efb5a1aa37fe445f129156260835a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67300 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Move internal headers to build.jsonDavid Benjamin1-0/+135
CMake doesn't use these, but a lot of our other build systems need it. Bug: 542 Change-Id: I74388751b832921ac121abd3d5755880f352a449 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67299 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-23Move crypto_sources to build.jsonDavid Benjamin1-0/+235
Bug: 542 Change-Id: Ie5590a0a68431903587fa87d70c1acac4161e9b9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67297 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Specify public headers in build.jsonDavid Benjamin1-0/+97
The CMake build doesn't use it, but this will be needed for the other builds to be driven by util/pregenerate. Bug: 542 Change-Id: If95cbcef1803e30ffc5ab7c9227fdcc6c53adf34 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67296 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Rework the test data storyDavid Benjamin1-1/+2
We originally embedded test data because of deficiencies in Android's build. Android had no way to specify test data with tests. That has since been resolved, and the embedding mechanism has gotten unwieldy. This unifies pki_test and crypto_test's test data story, and does so in a way that all tests can participate in. (We can now use FileTest in decrepit_test.) Update-Note: This will require some tweaks to downstream builds. We no longer emit an (unwieldy) crypto_test_data.cc file. Instead, tests will expect test data be available at the current working directory. This can be overridden with the BORINGSSL_TEST_DATA_ROOT environment variable. Callers with more complex needs can build with BORINGSSL_CUSTOM_GET_TEST_DATA and then link in an alternate implementation of this function. On the off chance some project needs it, I've kept the embed_test_data.go script around for now, but I expect we can delete it in the future. Fixed: 681 Change-Id: If181ce043e1eea3148838f1bb4db9ee4bfda0d08 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67295 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Move the rest of sources.cmake into util/pregenerateDavid Benjamin1-0/+261
Bug: 542 Change-Id: I23c3c5c01ae41bd98f605b34e09269a6602a2c49 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67294 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-22Move test data lists to util/pregenerateDavid Benjamin1-0/+1643
Since we can now handle glob patterns, make those shorter. Bug: 542 Change-Id: I971d9785bce0db7b2e8c41c8c82468afde64540d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67292 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-22Check in pre-generated perlasm and error data filesDavid Benjamin1-0/+182
This adds a tool for managing pre-generated files, aligning our CMake and non-CMake builds. The plan is roughly: The source of truth for the file lists will (eventually) be build.json. This describes the build in terms of the files that we directly edit. However, we have a two-phase build. First a pregeneration step transforms some of the less convenient inputs into checked in files. Notably perlasm files get expanded. This produces an equivalent JSON structure with fewer inputs. The same tool then outputs that structure into whatever build systems we want. This initial version pre-generates err_data.c and perlasm files. I've not wired up the various build formats, except for CMake (for the CMake build to consume) and JSON (for generate_build_files.py to parse). build.json is also, for now, only a subset of the build. Later changes The upshot of all this is we no longer have a Perl build dependency! Perl is now only needed when working on BoringSSL. It nearly removes the Go one, but Go is still needed to run and (for now) build the tests. To keep the generated files up-to-date, once this lands, I'll update our CI to run `go run ./util/pregenerate -check` which asserts that all generated files are correct. From there we can land the later changes in this patch series that uses this more extensively. My eventual goal is to replace generate_build_files.py altogether and the "master-with-bazel" branch. Instead we'll just have sources.bzl, sources.gni, etc. all checked into the tree directly. And then the normal branch will just have both a CMake and Bazel build in it. Update-Note: generate_build_files.py no longer generates assembly files or err_data.c. Those are now checked into the tree directly. Bug: 542 Change-Id: I71f5ff7417be811f8b7888b345279474e6b38ee9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67288 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
generated by cgit v1.1 at 2024-09-18 04:47:56 +0000