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

Author	SHA1	Message	Date
David Benjamin	ac85c036d7	Do not access value.ptr with V_ASN1_BOOLEAN. 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 <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>	4 years ago
David Benjamin	3d15a94add	Document ASN1_TYPE and related functions. 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 <davidben@google.com> Reviewed-by: Adam Langley <agl@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
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