Chiebot-Mirror/boringssl - boringssl - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
David Benjamin	4f9a7ba47e	Do not rely on ASN1_STRING being NUL-terminated. This imports part of the fix for CVE-2021-3712, commits d9d838ddc0ed083fb4c26dd067e71aad7c65ad16, 5f54e57406ca17731b9ade3afd561d3c652e07f2, 23446958685a593d4d9434475734b99138902ed2, and bb4d2ed4091408404e18b3326e3df67848ef63d0 from upstream. The others will be imported in follow-up CLs. Change-Id: Ic35aeb3895935ee94b82a295efade32782e8d1bc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49005 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	4 years ago
David Benjamin	acf6149ad8	Align with OpenSSL on constness of static ASN1_OBJECTs. 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 <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>	4 years ago
David Benjamin	c6ffcde8cd	Unwind M_ASN1_* macros for primitive types. At one point in the SSLeay days, all the ASN1_STRING typedefs were separate structs (but only in debug builds) and the M_ASN1_* macros included type casts to handle this. This is long gone, but we still have the M_ASN1_* macros. Remove the casts and switch code within the library to call the macros. Some subtleties: - The "MSTRING" types (what OpenSSL calls its built-in CHOICEs containing some set of string types) are weird because the M_FOO_new() macro and the tasn_new.c FOO_new() function behave differently. I've split those into a separate CL. - ASN1_STRING_type, etc., call into the macro, which accesses the field directly. This CL inverts the dependency. - ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free function is a no-op, but consistent.) - The other macros like M_ASN1_BIT_STRING_dup largely do not have corresponding functions. I've aligned with OpenSSL in just using the generic ASN1_STRING_dup function. But some others, like M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup function. OpenSSL retained these, so I have too. Update-Note: Some external code uses the M_ASN1_* macros. This should remain compatible, but some type errors may have gotten through unnoticed. This CL restores type-checking. Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045 Reviewed-by: Adam Langley <agl@google.com>	4 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago