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

Author	SHA1	Message	Date
Adam Langley	66e61c577d	Allow PKCS7_sign to work for signing kernel modules. Linux module signing uses PKCS#7 / CMS because everything is awful and broken. In order to make the lives of kernel developers easier, support the calling pattern that the kernel uses to sign modules. The kernel utility was written at a time when PKCS#7 was hard coded to use SHA-1 for signing in OpenSSL and it reflects this: you can only specify “sha1” on the command line, for example. As of OpenSSL 1.1.1, at least, OpenSSL uses SHA-256 and thus so does this change. Change-Id: I32b036123a0d8b272ec9e1c0130c45bf3ed0d2c7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49545 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	4 years ago
David Benjamin	1264f0ce35	Correctly order PKCS#7 certificates and CRLs. PKCS#7 stores certificates and CRLs in (implicitly-tagged) SET OF types. This means they're unordered and, in DER, must be sorted. We currently sort neither. OpenSSL upstream sorts CRLs but doesn't sort certificates. https://github.com/openssl/openssl/pull/13143 reports that Microsoft has a stricter parser that checks this. This CL fixes both fields in our serializer. This does not change the parsing code, which still preserves whatever order we happened to find, but I've updated the documentation to clarify that callers should not rely on the ordering. Based on [0] and the odd order in kPKCS7NSS, I believe this aligns with NSS's behavior. Update-Note: It is no longer the case that constructing a PKCS#7 file and parsing them back out will keep the certificates and CRLs in the same order. [0] https://source.chromium.org/chromium/chromium/src/+/main:chrome/common/net/x509_certificate_model_nss_unittest.cc;drc=c91b0c37b5ddf31cffd732c661c0c5930b0740f4;l=286 Change-Id: If776bb78476557af2c4598f1b6dc10e189adab5d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47304 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