2a0ee112c4
Some archaeology: it was added in upstream's ee1d9ec019a7584482bd95891404f1cad66a4a0a. This seems to come from upstream's arrangement where an EVP_MD can specify both the signing algorithm and the message digest. (Most of the usual hash algorithms were tied to RSA.) The flag is set on EVP_MDs that should use the EVP_PKEY's method table in EVP_Sign* rather than the one attached to the EVP_MD (there's also required_pkey_type to filter on EVP_PKEY to prevent a mismatch). Without the flag, the old codepath is hit where they're tied together. Interestingly, EVP_md5 does not have the flag, but I suppose this is because no one would sign ECDSA + MD5. EVP_DigestSign* also postdates this and doesn't use the legacy mechanism anyway. Upstream also has, e.g., EVP_ecdsa(). Although those too have since also gained the flag in bce1af776247fee153223ea156228810779483ce. Let's get rid of these TODOs. We don't have the old codepath. It's unclear if upstream really does either at this point. Note: EVP_PKEY_RSA_method in upstream is actually a macro that expands to three fields, which is why it's so difficult to figure out what's going on with those structs. Change-Id: I1aea4d3f79f1eb1755063bb96c1c65276c6e3643 Reviewed-on: https://boringssl-review.googlesource.com/2122 Reviewed-by: Adam Langley <agl@google.com> |
||
|---|---|---|
| .. | ||
| algorithm.c | ||
| asn1.c | ||
| CMakeLists.txt | ||
| digestsign.c | ||
| evp_ctx.c | ||
| evp_error.c | ||
| evp.c | ||
| example_sign.c | ||
| internal.h | ||
| p_ec_asn1.c | ||
| p_ec.c | ||
| p_hmac_asn1.c | ||
| p_hmac.c | ||
| p_rsa_asn1.c | ||
| p_rsa.c | ||
| pbkdf.c | ||
| sign.c | ||