aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-02-10Fix the type of x400Address in GENERAL_NAMEgrpc-202302David Benjamin3-3/+4
This fixes CVE-2023-0286. The main impact is that GENERAL_NAME_cmp, when given x400Addresses, can interpret a pointer with the wrong type. Applications that set X509_V_FLAG_CRL_CHECK and take CRLs from untrusted sources should take this patch. Change-Id: Ib76265fa098df3cb0db075646773c14d59d0ca75 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56985 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> (cherry picked from commit f219ae96bef5be04e78ddb5b5226ccb6439bd3ed) Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57165
2021-11-24update main-with-bazel from master branchBoringSSL Robot30-1614/+1822
2021-11-22Binary tag bump: 1 -> 2Adam Langley1-1/+1
Change-Id: If115d3ab25e2e538447a130f469debe25a92ce5c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50525 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2021-11-19Export PKCS12_DEFAULT_ITER.David Benjamin4-4/+8
rust-openssl uses this constant to determine PKCS12_create's defaults. Define it so it does not need to be redefined in https://boringssl-review.googlesource.com/c/boringssl/+/49645 Change-Id: Ife4a6597de430a411932096618406b9fcd721f43 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50505 Reviewed-by: Adam Langley <agl@google.com>
2021-11-18Add SSL_has_pending.David Benjamin3-2/+47
This was added in OpenSSL 1.1.x. It is slightly different from SSL_pending in that it also reports buffered transport data. Change-Id: I81e217aad1ceb6f4c31c36634a546e12b6dc8dfc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50445 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-11-18Update HPKE test vectors.David Benjamin9-1577/+1577
HPKE draft-12 has no changes from draft-08 except that the test vectors were refreshed and some fields in the JSON file renamed. Also fix the test vector reference to point to copy from the spec rather than the (identical) copy from the reference implementation. Change-Id: Icd4fd467672cc8701fcd2b262ac90c5adc05ac39 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50465 Reviewed-by: Adam Langley <agl@google.com>
2021-11-18Add various OpenSSL compatibility functions.David Benjamin6-1/+77
The non-_ex EVP_CIPHER_CTX Final functions are a bit interesting. Unlike EVP_DigestFinal(_ex), where the non-_ex version calls EVP_MD_CTX_cleanup for you, the EVP_CIPHER_CTX ones do not automatically cleanup. EVP_CipherFinal and EVP_CipherFinal_ex are identical in all releases where they exist. This appears to date to OpenSSL 0.9.7: Prior to OpenSSL 0.9.7, EVP_MD_CTX and EVP_CIPHER_CTX did not use void* data fields. Instead, they just had a union of context structures for every algorithm OpenSSL implemented. EVP_MD_CTX was truly cleanup-less. There were no EVP_MD_CTX_init or EVP_MD_CTX_cleanup functions at all. EVP_DigestInit filled things in without reference to the previous state. EVP_DigestFinal didn't cleanup because there was nothing to cleanup. EVP_CIPHER_CTX was also a union, but for some reason did include EVP_CIPHER_CTX_init and EVP_CIPHER_CTX_cleanup. EVP_CIPHER_CTX_init seemed to be optional: EVP_CipherInit with non-NULL EVP_CIPHER similarly didn't reference the previous state. EVP_CipherFinal did not call EVP_CIPHER_CTX_cleanup, but EVP_CIPHER_CTX_cleanup didn't do anything. It called an optional cleanup hook on the EVP_CIPHER, but as far as I can tell, no EVP_CIPHER implemented it. Then OpenSSL 0.9.7 introduced ENGINE. The union didn't work anymore, so EVP_MD_CTX and EVP_CIPHER_CTX contained void* with allocated type-specific data. The introduced EVP_MD_CTX_init and EVP_MD_CTX_cleanup. For (imperfect!) backwards compatibility, EVP_DigestInit and EVP_DigestFinal transparently called init/cleanup for you. EVP_DigestInit_ex and EVP_DigestFinal_ex became the more flexible versions that left init/cleanup to the caller. EVP_CIPHER_CTX got the same treatment with EVP_CipherInit/EVP_CipherInit_ex, but *not* EVP_CipherFinal/EVP_CipherFinal_ex. The latter did the same thing. The history seems to be that 581f1c84940d77451c2592e9fa470893f6c3c3eb introduced the Final/Final_ex split, with the former doing an auto-cleanup, then 544a2aea4ba1fad76f0802fb70d92a5a8e6ad85a undid it. Looks like the motivation is that EVP_CIPHER_CTX objects are often reused to do multiple operations with a single key. But they missed that the split functions are now unnecessary. Amusingly, OpenSSL's documentation incorrectly said that EVP_CipherFinal cleaned up after the call until it was fixed in 538860a3ce0b9fd142a7f1a62e597cccb74475d3. The fix says that some releases cleaned up, but there were, as far as I can tell, no actual releases with that behavior. I've put the new Final functions in the deprecated section, purely because there is no sense in recommending two different versions of the same function to users, and Final_ex seems to be more popular. But there isn't actually anything wrong with plain Final. Change-Id: Ic2bfda48fdcf30f292141add8c5f745348036852 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50485 Reviewed-by: Adam Langley <agl@google.com>
2021-11-15Add PKCS7_bundle_raw_certificates function which takes CRYPTO_BUFFERsMatt Mueller3-4/+88
Change-Id: I12ab8e9209bd5fdff75c42332d4d35a461302b61 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50425 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-11-04No-op change to test the bots.David Benjamin1-1/+1
Testing the Python 3 recipe migration. Change-Id: I428f08eaf426cf0bbd4b53f9f6932df7d15ad2ee Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50326 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-11-04Remove outdated comment in ECDSA implementation.David Benjamin1-2/+1
As of https://boringssl-review.googlesource.com/26968, digest_to_scalar should output a fully-reduced value. Change-Id: I9fccc62413b17184eb3aa6fa5cd87d7e7849e2eb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50325 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-11-04Add missing assert.h include.David Benjamin1-0/+1
Change-Id: I4af18ce3de2a01a8a5184096b07354bcbd24caf1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50265 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-11-01update main-with-bazel from master branchBoringSSL Robot12-916/+878
2021-11-01Check tag class and constructed bit in d2i_ASN1_OBJECT.David Benjamin2-17/+49
d2i_ASN1_OBJECT had a similar set of bugs in as in https://boringssl-review.googlesource.com/c/boringssl/+/49866. This does not affect any other d2i functions. Those already go through the ASN1_ITEM machinery. Update-Note: d2i_ASN1_OBJECT will now notice more incorrect tags. It was already checking for tag number 6, so it is unlikely anyone was relying on this as a non-tag-checking parser. Change-Id: I30f9ad28e3859aeb7a38c0ea299cd2e30002abce Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50290 Reviewed-by: Adam Langley <agl@google.com>
2021-11-01Don't parse constructed BIT STRINGs in crypto/bytestringDavid Benjamin2-25/+25
Update-Note: PKCS#7 and PKCS#12 parsers will now reject BER constructed BIT STRINGs. We were previously misparsing them, as was OpenSSL. Given how long the incorrect parse has been out there, without anyone noticing (other parsers handle it correctly), it is unlikely these exist. Change-Id: I61d317461cc59480dc9f772f88edc7758206d20d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50289 Reviewed-by: Adam Langley <agl@google.com>
2021-11-01Enforce DER rules for BIT STRING values.David Benjamin5-10/+37
DER requires BIT STRING padding bits be zero. Bug: 354 Change-Id: Id59154cc4e77f91df8b9ff1eb1b09514116808da Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50288 Reviewed-by: Adam Langley <agl@google.com>
2021-11-01Remove support for indefinite lengths in crypto/asn1.David Benjamin6-186/+87
This simplifies the ASN1_get_object calling convention and removes another significant source of tasn_dec.c complexity. This change does not affect our PKCS#7 and PKCS#12 parsers. Update-Note: Invalid certificates (and the few external structures using asn1t.h) with BER indefinite lengths will now be rejected. Bug: 354 Change-Id: I723036798fc3254d0a289c77b105fcbdcda309b2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50287 Reviewed-by: Adam Langley <agl@google.com>
2021-11-01update main-with-bazel from master branchBoringSSL Robot3-141/+52
2021-11-01Remove support for constructed strings in crypto/asn1.David Benjamin3-141/+52
Constructed strings are a BER mechanism where a string type can be represented as a tree of constructed nodes and primitive leaves, that then have to be concatenated by the parser. This is prohibited in DER and a significant source of complexity in our parser. Note this change does not affect our PKCS#7 and PKCS#12 parsers (where BER is sadly necessary for interop) because those use CBS. Update-Note: Invalid certificates (and the few external structures using asn1t.h) with BER constructed strings will now be rejected. Bug: 354 Change-Id: I5a8ee028ec89ed4f2d5c099a0588f2029b864580 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50286 Reviewed-by: Adam Langley <agl@google.com>
2021-11-01update main-with-bazel from master branchBoringSSL Robot41-405/+648
2021-11-01Check for trailing data in extensions.David Benjamin37-135/+299
X509V3_EXT_d2i should notice if an extension has extra data at the end. Update-Note: Some previously accepted invalid certicates may be rejected, either in certificate verification or in X509_get_ext_d2i. Bug: 352 Change-Id: Iacbb74a52d15bf3318b4cb8271d44b0f0a2df137 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50285 Reviewed-by: Adam Langley <agl@google.com>
2021-11-01update main-with-bazel from master branchBoringSSL Robot4-18/+17
2021-11-01Update tools.David Benjamin4-18/+17
We haven't done this in a while. This also tests more codepaths in in the previous Python 3 update. libc++ required a few more build tweaks. Also the CMake update was necessary to update the NDK. Older CMake cannot detect CMAKE_LINKER in the newer NDK. Change-Id: I59ab1c6b074b805dd4b8a6ab596c4cf469d5bfa9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50167 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-10-30update main-with-bazel from master branchBoringSSL Robot12-238/+222
2021-10-29Fold x509v3/pcy_int.h into x509v3/internal.h.David Benjamin9-235/+222
pcy_int.h was especially weird because it is even missing include guards and its dependencies. Change-Id: Idccfe23b74b47641bcfc802f78f3ee6fe479b781 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50245 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-10-27update main-with-bazel from master branchBoringSSL Robot1-7/+7
2021-10-27Switch kModuleDigestSize to a macro.David Benjamin1-7/+7
Although the compiler will hopefully optimize it out, this is technically a VLA. The new Android NDK now warns about this. Change-Id: Ib9f38dc73c40e90ab61105f29a635c453f1477a1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50185 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-10-27update main-with-bazel from master branchBoringSSL Robot2-12/+12
2021-10-27Switch DEPS actions on bots to Python 3.David Benjamin2-12/+12
In doing so, I think this fixes a bug on Windows where extract.py was digesting the archive in text mode. (Doesn't particularly matter, though by using the correct digest, we will end up re-extracting the files once.) Change-Id: Ia7effe5f9c228c1a702cba8e6380975b59261808 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50166 Reviewed-by: Adam Langley <agl@google.com>
2021-10-26update main-with-bazel from master branchBoringSSL Robot1-3/+3
2021-10-26Match OPENSSL_EXPORT in ssl/internal.h friend declarations.David Benjamin1-3/+3
After fixing up some issue with the BORINGSSL_IMPLEMENTATION define in Chromium builds (which used to work fine but, with the test that references ASN1_ITEM_rptr(BASIC_CONSTRAINTS), is a bit more strict), I'm running into this warning. ../../third_party/boringssl/src/ssl/internal.h(3695,15): error: 'SSL_CTX_free' redeclared without 'dllimport' attribute: previous 'dllimport' ignored [-Werror,-Winconsistent-dllimport] friend void SSL_CTX_free(SSL_CTX *); ^ Searching for friend.*EXPORT in Chromium shows they match exports in friend declarations, so I gather this is just how it works. Change-Id: I704686854c77406378882477a8bab3f1521e29e4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50145 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-10-25update main-with-bazel from master branchBoringSSL Robot2-0/+8
2021-10-25Add a function to express the desired record version protocol.Adam Langley2-0/+8
This function is currently a no-op, but could be made to do something in the future to ease the transition of deployments that extract keys from the handshake and drive the record protocol themselves. Change-Id: Ib1399e42442dad78173a6462980945559a88a2c7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49886 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2021-10-25update main-with-bazel from master branchBoringSSL Robot4-28/+138
2021-10-25Add CRYPTO_BUFFER_new_from_static_data_unsafe.David Benjamin4-28/+138
When making a CRYPTO_BUFFER from a static, const buffer, there is no need to make a copy of the data. Instead, we can reference it directly. The hope is this will save a bit of memory in Chromium, since root store certs will already in static data. Moreover, by letting static CRYPTO_BUFFERs participate in pooling, we can extend the memory savings to yet other copies of these certs. For instance, if we make the root store updatable via component updater, most of the updated roots will likely already be in the binary's copy. Pooling will transparently dedup those and avoid retaining an extra copy. (I haven't gone as far as to give static CRYPTO_BUFFERs strong references from the pool, since that seems odd. But something like Chromium probably wants to intentionally leak the initial static ones so that, when all references go away, they're still available for pooling.) Change-Id: I05c25c5ff618f9f7a6ed21e4575cf659e7c32811 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50045 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-10-21update main-with-bazel from master branchBoringSSL Robot8-162/+160
2021-10-21Finish documenting asn1.h.David Benjamin3-123/+133
One down, two more to go! As part of this, I've added it to doc.config, revised the note at the top, and moved the sample i2d/d2i functions here. Bug: 426 Change-Id: I7bb9d56bf9ba58c921cfcf9626bf3647c6e5c7df Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50107 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-10-21Trim some undocumented symbols from asn1.h.David Benjamin6-39/+27
ASN1_ENCODING can be unexported because all types using it are now hidden. This does mean external uses of <openssl/asn1t.h> can no longer use ASN1_SEQUENCE_enc, but there do not seem to be any such uses. ASN1_TLC and ASN1_TEMPLATE typedefs are only necessary for users of asn1t.h. I'm hopeful we can do away with ASN1_TLC once I get to reworking tasn_dec.c. ASN1_TEMPLATE is somewhat stuck, though all references should be hidden behind macros. ASN1_generate_* appear to only referenced within the library. Remove the unused one and move the other to x509/internal.h. (asn1_gen.c is currently in crypto/x509 rather than crypto/asn1, so I put it in x509/internal.h to match. I'll leave figuring out that file to later.) Annoyingly, asn1/internal.h now pulls in asn1t.h, but so it goes. Change-Id: I8b43de3fa9647883103006e27907730d5531fd7d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50106 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-10-21update main-with-bazel from master branchBoringSSL Robot1-0/+18
2021-10-21Add magic tag to BoringSSL binaries.Adam Langley1-0/+18
There are cases where people grep binaries for strings like OpenSSL version strings in order to detect when out-dated versions of libraries are being used. With BoringSSL you might find "OpenSSL 1.1.1 (compatible; BoringSSL)", if the linker didn't discard it, but that's not very helpful for knowing how up-to-date BoringSSL is because we hardly ever change it. This change adds a distinct random value to search for that uniquely identifies BoringSSL and includes a rough guide to how old the BoringSSL copy is. The linker will hopefully not discard it because it's refereneced from |OPENSSL_malloc|. Change-Id: Ie2259fd17a55d249a538a8a161b0d755396dd7b8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49885 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2021-10-21update main-with-bazel from master branchBoringSSL Robot2-27/+166
2021-10-21Document and const-correct multi-string types.David Benjamin2-27/+166
While I'm here, add missing parentheses around the B_ASN1_* bitmasks. I've tossed ASN1_PRINTABLE into the deprecated bucket, though X509_NAME relies on it, because it is a mess. Bug: 407, 426 Change-Id: I287f60e98d6c9f237908011e1a816f4b4fb4433e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50105 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-10-21update main-with-bazel from master branchBoringSSL Robot3-4/+4
2021-10-21update main-with-bazel from master branchBoringSSL Robot1-29/+106
2021-10-21Fully unexport X509_VAL.David Benjamin3-4/+4
After https://boringssl-review.googlesource.com/c/boringssl/+/45965, X509_VAL became largely unusable. While it did still exist as an ASN1_ITEM and we emitted d2i/i2d/new/free functions, there is no way to access its contents. Thus, hide it entirely. Interestingly, although we got that to stick a while ago, I missed that OpenSSL actually keeps X509_VAL exported, so it's possible we'll find 3p code that uses this later. Since a standalone X509_VAL isn't especially useful to construct or encode, this is most likely to come up in code defining new types with <openssl/asn1t.h>. Still, if we need to rexport this later (revert this *and* bring back the struct), it won't be a big deal. Nothing in the public API even constrains X509 to use X509_VAL. Update-Note: The last remnants of the now (barely usable) X509_VAL are no longer exported. It is unlikely anyone was relying on this. Bug: 425 Change-Id: I90975f2f7ec27753675d2b5fa18b5cc4716319f4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50085 Reviewed-by: Adam Langley <agl@google.com>
2021-10-21Document ASN1_OBJECT, i2c, and c2i functions.David Benjamin1-29/+106
Almost done with this header. Bug: 426 Change-Id: I9d103460d0f59b56f8539f77420a779f850335f7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50065 Reviewed-by: Adam Langley <agl@google.com>
2021-10-20update main-with-bazel from master branchBoringSSL Robot2-1/+2
2021-10-20Unexport ASN1_OBJECT_new.David Benjamin2-1/+2
Outside the library, this function is practically useless. It creates an empty ASN1_OBJECT, which can never be filled in because the struct is private and there are no mutating setters. (See https://boringssl-review.googlesource.com/c/boringssl/+/46164 and https://boringssl-review.googlesource.com/c/boringssl/+/48326 for a discussion on why it's important ASN1_OBJECTs are immutable.) Update-Note: ASN1_OBJECT_new is no longer exported. While this function does remain in OpenSSL, it is extremely unlikely anyone has found a use for this function. Bug: 452 Change-Id: I111a9a1ce3ca4d7aa717a3c3a03d34c05af8fdbd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50025 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-10-20update main-with-bazel from master branchBoringSSL Robot3-13/+16
2021-10-20Return 0x80 in all ASN1_get_object error paths.David Benjamin3-13/+16
If the header is valid, but the body is truncated, ASN1_get_object intentionally preserves the indefinite-length and constructed output bits. This means callers who check for error with == 0x80 may read off the end of the buffer on accident. This is unlikely to break callers: 0x80 was already a possible error value, so callers already needed to handle it. The original function's aim in returning more information is unlikely to matter because callers cannot distinguish 0x80 (could not parse header) and 0x80 (header was valid, definite-length, and primitive, but length was too long). Update-Note: ASN1_get_object's calling convention is slightly simplified. Bug: 451 Change-Id: If2b45c47e6b8864aef9fd5e04f313219639991ed Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50005 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-10-20update main-with-bazel from master branchBoringSSL Robot1-8/+58
generated by cgit v1.1 at 2024-08-04 02:51:59 +0000