Upgrade to upstream 519c2986c73c23461b130ad19b93fd7d081353d5 (Chromium 92 0 4515 107) #68
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 improves compatibility with cryptography.io. cryptography.io doesn't actually care what we return, since the code won't run, but feigning success seems better than failure. If some application does try to run this function and checks, returning an error will probably crash it. Change-Id: I7a8164753a2f1a7b31dbeb10c7030c5e5fea2bc9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46004 Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
I got the values flipped around. Also cryptography.io wants EC_GROUP_get_asn1_flag to check a curve's encoding. We (mostly) only support named curves, so just return OPENSSL_EC_NAMED_CURVE. Change-Id: I544e76b7380ecd8dceb1df3db4dd4cf5cb322352 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46024 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Update-Note: This removes a function that appears to be unused. It also hardcodes the use of MD5, so please do not use it. Change-Id: I67909c6360e4737fc22742592f88b907eb818e96 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45964 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Update-Note: https://boringssl-review.googlesource.com/c/boringssl/+/44124 made these functions a no-op, but we kept them around because there were still some call sites floating around. That code has since been updated, so we can remove this. Change-Id: I25d411122d0e7a427eef5ebe8357401c0e5039d4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45984 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
pkcs12_test.cc was getting a bit long. Along the way, embed_test_data.go needed a fix to work around a syntax quirk of C++. Change-Id: Ic4a19f77d177ebd607918feb253a08f1f9037981 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46044 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
PKCS#12 is overly general and, among other things, supports disabling encryption. In practice, the unencrypted form is not widely implemented. Moreover, even in contexts where cleartext is fine, an unencrypted PKCS#12 file still requires a password for the mandatory MAC component. They're not very useful. However, cryptography.io uses them. Previously, we added support for parsing these. This CL adds support for creating them too, because now cryptography.io now also depends on that. Change-Id: Ib7c4e29615047b6c73f887fea7c80f8844999bb7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46045 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
We aim to eventually make the entire X509 structure opaque, but let's start small. Update-Note: I believe this is now safe to do. If there are compile failures, switch to X509_get0_notBefore, X509_getm_notBefore, and X509_set1_notBefore, or revert this if I'm wrong and too many callers still need updating. Change-Id: I6e9d91630a10ac777e13ebcdeb543b3cbeea6383 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45965 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
OpenSSL classified their behavior as a bug and are fixing it for the next release. In principle it'd be more compatible to emulate OpenSSL's bug and undo it when we update OPENSSL_VERSION_NUMBER, but use of PKCS12_parse is rare and this behavior is confusing, so let's leave it as-is. Bug: 250 Change-Id: I5f9825490a8afde67272dfaf476b35dbde94b59c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46064 Reviewed-by: Adam Langley <[email protected]>
This is to help with cryptography.io compatibility. We don't implement any of the flags (PKCS7_sign checks flags == PKCS7_DETACHED), but cryptography.io now depends on the constant and PKCS7_SIGNER_INFO type being available. (cryptography.io also wants some new functions, but I think it's easier to stub those out externally for now. If we need to actually enable those features, we can look at actually implementing more of PKCS7_sign.) Change-Id: Id8419e34a68c04d4894417c7d6b13c1952d0bb88 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46084 Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
This will also pull in POLICY_MAPPINGS by way of STACK_OF(T) handling. Change-Id: I8ddc9547647f8cae3800047eb58e1c83f6ae1085 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46104 Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Change-Id: I290abd9e48dd4c200f61dd1a7c9acb56a9e2a707 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46105 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
This flag causes the runner to execute the shim with the RR debugger. See https://rr-project.org/. Unlike typical debuggers, the RR workflow is to first record a session and then replay it. The user cannot interact with the debugger while recording and they replay the session multiple times. For these reasons, I've opted not to launch xterm like -gdb and -lldb do. The other difference is that -rr-record restricts the runner to exactly one test. Otherwise, it's too easy to accumulate a bunch of unwanted recordings. Also, `rr replay` uses the most recent recording by default, so it's not very useful for runner to record multiple tests. Change-Id: I2d29d64df5c4c832e50833325db3500ec2698e76 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46144 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
ASN1_OBJECTs are awkward. Sometimes they are static, when returned from OBJ_nid2obj, and sometimes they are dynamic, when parsed from crypto/asn1. Most structures in crypto/asn1 need to support unknown OIDs and thus must own their ASN1_OBJECTs. But they also may be initialized with static ones in various APIs, such as X509_ALGOR_set0. To make that work, ASN1_OBJECT_free detects static ASN1_OBJECTs and is a no-op. Functions like X509_ALGOR_set0 take ownership, so OpenSSL has them take a non-const ASN1_OBJECT*. To match, OBJ_nid2obj then returns a non-const ASN1_OBJECT*, to signal that it is freeable. However, this means OBJ_nid2obj's mutability doesn't match its return type. In the fork, we switched OBJ_nid2obj to return const. But, in doing so, we had to make X509_ALGOR_set0 and X509_PUBKEY_set0_param take const ASN1_OBJECT, even though they would actually take ownership of dynamic ASN1_OBJECTs. There are also a few internal casts with a TODO to be const-correct. Neither situation is ideal. (Perhaps a more sound model would be to copy static ASN1_OBJECTs before putting them in most structs. But that would not match current usage.) But I think aligning with OpenSSL is the lesser evil here, since it avoids misleading set0 functions. Managing ownership of ASN1_OBJECTs is much more common than mutating them. To that end, I've added a note that ASN1_OBJECTs you didn't create must be assumed immutable[*]. Update-Note: The change to OBJ_nid2obj should be compatible. The changes to X509_PUBKEY_set0_param and X509_ALGOR_set0 may require fixing some pointer types. [*] This is *almost* honored by all of our functions. The exception is c2i_ASN1_OBJECT, which instead checks the DYNAMIC flag as part of the object reuse business. This would come up if we ever embedded ASN1_OBJECTs directly in structs. Change-Id: I1e6c700645c12b43323dd3887adb74e795c285b9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46164 Commit-Queue: David Benjamin <[email protected]> Commit-Queue: Adam Langley <[email protected]> Reviewed-by: Adam Langley <[email protected]>
In order to provide evidence to auditors that high-level functions end up calling into the FIPS module, provide counters that allow for such monitoring. Change-Id: I55d45299f3050bf58077715ffa280210db156116 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46124 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>
The representation here is a bit more messy than necessary. In doing so, clean up the variable names and smooth away two rough edges: - X509_ALGOR_get0 would leave *out_param_value uninitialized if *out_param_type is V_ASN1_UNDEF. Instead, set it to NULL, so callers do not accidentally use an uninitialized pointer. - X509_PUBKEY_set0_param, if key is NULL, would leave the key alone. No one calls this function externally and none of the (since removed) callers in OpenSSL rely on this behavior. A NULL check here adds a discontinuity at the empty string that seems unnecessary here: changing the algorithm without changing the key isn't useful. (Note the API doesn't support changing the key without the algorithm.) Note for reviewing: the representation of ASN1_TYPE is specified somewhat indirectly. ASN1_TYPE uses the ASN1_ANY ASN1_ITEM, which has utype V_ASN1_ANY. Then you look at asn1_d2i_ex_primitive and asn1_ex_c2i which peel off the ASN1_TYPE layer and parse directly into the value field, with a fixup for NULL. Hopefully we can rework this someday... Change-Id: I628c4e20f8ea2fd036132242337f4dcac5ba5015 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46165 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Flagged by valgrind. Change-Id: Ib49297bd483650880207a1efe5e9dff666e458d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46204 Reviewed-by: Adam Langley <[email protected]>
We already know all the supported curves in runner.go. No sense in repeating this list in more places than needed. (I'm about to need a similar construct for -signing-prefs, so I figure it's worth being consistent.) This CL also adds a ShimConfig option because others don't support the same curves we do and will likely run into this quickly. Change-Id: Id79cea16891802af021b53a33ffd811a5d51c4ae Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46186 Reviewed-by: Adam Langley <[email protected]>
When it is and isn't safe to assume an X509 field is non-NULL seems to cause some confusion. (I often get requests to add NULL checks when rewriting calling code.) X.509 has surprisingly few optional fields, and we generally say pointers are non-NULL unless documented. But that only works if we remember to mention the nullable ones. Change-Id: I18b57a17c9d57c377ea2227347e423f574389818 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46185 Reviewed-by: Adam Langley <[email protected]>
See draft-davidben-tls13-pkcs1-00. The code point is disabled by default and must be configured in SSL_set_verify_algorithm_prefs and SSL_set_signing_algorithm_prefs. It is also only defined for TLS 1.3 client certificates and otherwise ignored. This required reworking the tests a bit since this is the first signature algorithm that's disabled by default, and the first algorithm that behaves differently between client and server. Change-Id: Iac4aa96a4963cbc33688c252e958a572c5c3b511 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46187 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
The build scripts distinguish between normal files and bcm.c fragments based on whether code is in a subdirectory inside crypto/fipsmodule. Bug: 401 Change-Id: Ieba88178e4f8e19f020e56e2567d5736a34bb43f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46224 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
Get entropy from /dev/urandom on FreeBSD < 12, or getrandom() on FreeBSD 12, per https://www.freebsd.org/cgi/man.cgi?query=getrandom&sektion=2&format=html Tested manually with `ninja run_tests` on both FreeBSD 11 and 12. Change-Id: I72ef54d1a83104d1fbe172fd86f6cd32dacc9819 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46188 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]>
This is a little inconvenient for external users of the test suite. It's also not very helpful to pass -handshaker-path in build configurations without a handshaker because there won't be a file there anyway. Change-Id: I6a8fdcfbbf86288876c4c6fda2a46d32663efb69 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46244 Reviewed-by: Adam Langley <[email protected]>
Change-Id: Id5b5b639023d30a8ebd763d02e1787fbf9d79288 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46245 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]>
In doing so, this switches make_errors.go to take library names as parameters rather than detecting it from the CWD. (I considered detecting it, but then we'd need to map evp -> crypto/whatever and crypto/whatever -> evp in both directions.) Since crypto/hpke currently sits in the EVP namespace, I've gone ahead and added that, so it should be easier to define new errors in crypto/hpke. I've not added crypto/cipher, etc., yet. Moving those will be a breaking change (consumers that put ERR_LIB_CIPHER and ERR_LIB_EVP in a switch/case need patches). Bug: 398 Change-Id: Ibae2afd46e076891fa517c377b540b2e492516f0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46264 Reviewed-by: Adam Langley <[email protected]>
Bug: 275 Change-Id: I724e9315b860e230e8fed92de34d89a875ef043c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46184 Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]>
All our EVP_CIPHERs are deterministic, so there's usually no point in testing only one direction. Some of the ECB tests were missing free decryption tests. CTR is the same in both directions, but we ought to test the API agrees. OFB vectors are doubled up, so we can merge them together. Plus there are typos in the OFB-AES192.Decrypt tests, also present upstream, so we weren't actually testing everything we should. (I haven't removed the direction-specific logic altogether since the tests imported from nist_cavp rely on it. Though there may be something to be said for running them both ways since they don't actually double them up...) Change-Id: I36a77d342afa436e89ad244a87567e1a4c6ee9dc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46284 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This reverts commit a3437c0. There was a miscommunication and it does not seem like we currently need this. If that changes later, it's in Git and we can bring it back easily. Change-Id: Ibbce29df2258a2d893d725ab3ee6fd78c5b6cb00 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46286 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
See also 8129ac6ac4c0ca3a488c225cde580ede7dabe874 and 81198bf323ea9deda907714170d329ca7d2ff01f from upstream. In trying to figure out why ASan (which normally catches overlapping memcpys) didn't flag this, I noticed that we actually don't have tests for empty inputs. I've added them to cipher_tests.txt where missing and fixed a bad assert in ofb.c. ASan still doesn't flag this because LLVM even requires memcpy handle dst == src. Still, fixing it is less effort than getting a clear answer from GCC and MSVC. Though this puts us in the frustrating position of trying to follow a C rule that our main toolchain and sanitizer disavow. https://bugs.llvm.org/show_bug.cgi?id=11763 https://reviews.llvm.org/D86993 Change-Id: I53c64a84834ddf5cddca0b3d53a29998f666ea2f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46285 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
This API does not come from OpenSSL, but OpenSSL does not appear to have any way to get this information. There is X509_get0_pubkey_bitstr, but that only works for X509 objects, not X509_PUBKEY. Change-Id: Ifc8be554a4d8cbf830c32b95b953f092980804df Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46304 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
This fixes a bug in ASN1_TYPE_get. Partly imported from upstream's 261ec72d58af64327214a78ca1c54b169ad93c28, though I don't believe ASN1_TYPE_set was broken per se. There's also a lot more than in that commit. I've added a test to ensure we maintain the unused bits invariant anyway, in case external code relies on it. (The invariant comes from the pointer being NULL-initialized and from ASN1_primitive_free zeroing *pval on free.) Change-Id: I4c0c57519a7628041d81c26cd850317e01409556 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46324 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
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 <[email protected]>
lh_strhash mapped nullptr to zero. ec8c67d switched CONF's use to OPENSSL_strhash, which crashes on nullptr. But CONF depends on the nullptr handling. Change-Id: I131c752aa089fb99b01c9e406b6994f3a6236976 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48385 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>
The comments say that this should work, but it didn't. OpenSSL doesn't have any documentation about this but from looking at the code it works there. (Along with things like magic sections called “ENV” to get environment variables, sigh.) Change-Id: I538fbad57e6af37eee739de6d2643f554bfc5c79 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48386 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Change-Id: Iaa5971f6a09a4267be95ea1820b72f7b619b53e1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48366 Reviewed-by: Adam Langley <[email protected]>
This function's behavior differs from all the other lastpos functions. It does not appear to be used anywhere, so remove it. (lastpos = -1 returns the first match, lastpos = -2 additionally fails if there are duplicates, lastpos = -3 additionally fails if the attribute is multiply-valued.) Update-Note: X509at_get0_data_by_OBJ is removed. We found no callers of this function. Change-Id: I8547bac6626623e43827e2490f04850eb148e317 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48367 Reviewed-by: Adam Langley <[email protected]>
X509*_get_*_by_NID return -1 if the extension was not found, but -2 if the NID was invalid. Looking through callers, many check index != -1, rather than index < 0. That means, in theory, they'll do the wrong thing in some cases. Realistically, this case is impossible: most callers pass in a constant. Even in those that don't, NIDs are a local enum, not standard constants. That means hitting this path is almost certainly a programmer error. No need to complicate the calling convention for it. Update-Note: The return value convention of some functions was simplified. This is not expected to affect any callers. Change-Id: If2f5a45c37caccdbfcc3296ff2db6db1183e3a95 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48368 Reviewed-by: Adam Langley <[email protected]>
Found by OSS-Fuzz. This comes up if you enable client certificates and the draft ECH implementation on the server. Bug: 275, oss-fuzz:35815 Change-Id: I0b4fcc994f7238f8a3cf1f1934672bac0cee0cfb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48425 Reviewed-by: Adam Langley <[email protected]>
See also f8fc0e35e0b1813af15887d42e17b7d5537bb86c from upstream, though our BN_divs have diverged slightly. Change-Id: I49fa4f0a5c730d34e6f41f724f1afe3685470712 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48426 Reviewed-by: Adam Langley <[email protected]>
This is not used anywhere inside or outside the library. Update-Note: Removed unused field in struct. Change-Id: I244d8af819e84412956fecb929678404fdfcc38f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48427 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Adam Langley <[email protected]>
Also use a slightly more conservative pattern. Instead of aligning the pointer as a uintptr_t and casting back, compute the offset and advance in pointer space. C guarantees that casting from pointer to uintptr_t and back gives the same pointer, but general integer-to-pointer conversions are generally implementation-defined. GCC does define it in the useful way, but this makes fewer dependencies. Change-Id: I70c7af735e892fe7a8333b78b39d7b1f3f1cdbef Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48405 Reviewed-by: Adam Langley <[email protected]>
Change-Id: I10eb66f195636a9bf953c841ea13e187e6f94aad Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48506 Reviewed-by: Adam Langley <[email protected]>
Update-Note: Use accessors instead. Change-Id: I7b41eb7c724d94d3e6d26498063e045a1850c671 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48465 Reviewed-by: Adam Langley <[email protected]>
I've switched a few things to the accessors where it was easy, but X509_EXTENSION is, in us and upstream, not const-correct right now, so it's a little goofy. Update-Note: Use X509_EXTENSION_get_* instead. Change-Id: Ife9636051a924a950b1c739b7720baf12e35f9c7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48505 Reviewed-by: Adam Langley <[email protected]>
The stack consumption of the HRSS functions is causing issues in stack-constrained environments. Therefore allocate many variables on the heap. This means that several HRSS_ functions now allocate, and thus can fail, where they couldn't before. Callers that ignore the return value and don't have crash-on-failure mallocs will still be safe, although things will fail to decrypt later on. Somehow, this actually makes key generation _faster_ on my machine. (I don't know. Better alignment? Fewer L1 collisions?) The other operations are slightly slower, as expected. Before: Did 17390 HRSS generate operations in 3054088us (5694.0 ops/sec) Did 225000 HRSS encap operations in 3000512us (74987.2 ops/sec) Did 87000 HRSS decap operations in 3014525us (28860.3 ops/sec) After: Did 21300 HRSS generate operations in 3026637us (7037.5 ops/sec) Did 221000 HRSS encap operations in 3008911us (73448.5 ops/sec) Did 84000 HRSS decap operations in 3007622us (27929.0 ops/sec) Change-Id: I2312df8909af7d8d250c7c483c65038123f21ad9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48345 Commit-Queue: Adam Langley <[email protected]> Reviewed-by: David Benjamin <[email protected]>
Trusty wants to seed from a different RNG than the one that supplies per-draw entropy. This is a no-op change unless you're substituting in your own implementations of these functions. To see that it's a no-op in urandom.c, note that it only changes the |seed| argument to |fill_with_entropy|. That causes the value of |extra_getrandom_flags_for_seed_bss_get| to be ORed into the flags, but that value will always be zero unless it's an Android FIPS build. Change-Id: Ic8d954df3074559cbf1bfee1ae91a4a2b7e14d9d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48485 Reviewed-by: David Benjamin <[email protected]>
|
Please review but do not merge: This branch causes a build error deep in Chromium when pulled in: I have the gut feeling that for some reason, it's not the chromium/boringssl-source-tree provided "openssl" includes that are utilized when building, but the ones from the system (where exactly |
|
Update: This release works OK in Chromium94 as per open-quantum-safe/oqs-demos#98. So, this PR is ready for review. |
|
Will hold off on merging until #60 (comment) is resolved. |
xvzcf
approved these changes
Aug 19, 2021
baentsch
deleted the
mb-519c2986c73c23461b130ad19b93fd7d081353d5--92-0-4515-107
branch
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.
Fixes #57.