Align with upstream's error strings, take two.
I messed up a few of these.
ASN1_R_UNSUPPORTED_ALGORITHM doesn't exist. X509_R_UNSUPPORTED_ALGORITHM does
exist as part of X509_PUBKEY_set, but the SPKI parser doesn't emit this. (I
don't mind the legacy code having really weird errors, but since EVP is now
limited to things we like, let's try to keep that clean.) To avoid churn in
Conscrypt, we'll keep defining X509_R_UNSUPPORTED_ALGORITHM, but not actually
do anything with it anymore. Conscrypt was already aware of
EVP_R_UNSUPPORTED_ALGORITHM, so this should be fine. (I don't expect
EVP_R_UNSUPPORTED_ALGORITHM to go away. The SPKI parsers we like live in EVP
now.)
A few other ASN1_R_* values didn't quite match upstream, so make those match
again. Finally, I got some of the rsa_pss.c values wrong. Each of those
corresponds to an (overly specific) RSA_R_* value in upstream. However, those
were gone in BoringSSL since even the initial commit. We placed the RSA <-> EVP
glue in crypto/evp (so crypto/rsa wouldn't depend on crypto/evp) while upstream
placed them in crypto/rsa.
Since no one seemed to notice the loss of RSA_R_INVALID_SALT_LENGTH, let's undo
all the cross-module errors inserted in crypto/rsa. Instead, since that kind of
specificity is not useful, funnel it all into X509_R_INVALID_PSS_PARAMETERS
(formerly EVP_R_INVALID_PSS_PARAMETERS, formerly RSA_R_INVALID_PSS_PARAMETERS).
Reset the error codes for all affected modules.
(That our error code story means error codes are not stable across this kind of
refactoring is kind of a problem. Hopefully this will be the last of it.)
Change-Id: Ibfb3a0ac340bfc777bc7de6980ef3ddf0a8c84bc
Reviewed-on: https://boringssl-review.googlesource.com/7458
Reviewed-by: Emily Stark (Dunn) <estark@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
2016-03-14 21:13:54 +00:00
|
|
|
RSA,100,BAD_ENCODING
|
|
|
|
|
RSA,101,BAD_E_VALUE
|
|
|
|
|
RSA,102,BAD_FIXED_HEADER_DECRYPT
|
|
|
|
|
RSA,103,BAD_PAD_BYTE_COUNT
|
|
|
|
|
RSA,104,BAD_RSA_PARAMETERS
|
|
|
|
|
RSA,105,BAD_SIGNATURE
|
|
|
|
|
RSA,106,BAD_VERSION
|
|
|
|
|
RSA,107,BLOCK_TYPE_IS_NOT_01
|
|
|
|
|
RSA,108,BN_NOT_INITIALIZED
|
|
|
|
|
RSA,109,CANNOT_RECOVER_MULTI_PRIME_KEY
|
|
|
|
|
RSA,110,CRT_PARAMS_ALREADY_GIVEN
|
|
|
|
|
RSA,111,CRT_VALUES_INCORRECT
|
|
|
|
|
RSA,112,DATA_LEN_NOT_EQUAL_TO_MOD_LEN
|
|
|
|
|
RSA,113,DATA_TOO_LARGE
|
|
|
|
|
RSA,114,DATA_TOO_LARGE_FOR_KEY_SIZE
|
|
|
|
|
RSA,115,DATA_TOO_LARGE_FOR_MODULUS
|
|
|
|
|
RSA,116,DATA_TOO_SMALL
|
|
|
|
|
RSA,117,DATA_TOO_SMALL_FOR_KEY_SIZE
|
|
|
|
|
RSA,118,DIGEST_TOO_BIG_FOR_RSA_KEY
|
|
|
|
|
RSA,119,D_E_NOT_CONGRUENT_TO_1
|
|
|
|
|
RSA,120,EMPTY_PUBLIC_KEY
|
|
|
|
|
RSA,121,ENCODE_ERROR
|
|
|
|
|
RSA,122,FIRST_OCTET_INVALID
|
|
|
|
|
RSA,123,INCONSISTENT_SET_OF_CRT_VALUES
|
|
|
|
|
RSA,124,INTERNAL_ERROR
|
|
|
|
|
RSA,125,INVALID_MESSAGE_LENGTH
|
|
|
|
|
RSA,126,KEY_SIZE_TOO_SMALL
|
|
|
|
|
RSA,127,LAST_OCTET_INVALID
|
|
|
|
|
RSA,128,MODULUS_TOO_LARGE
|
|
|
|
|
RSA,129,MUST_HAVE_AT_LEAST_TWO_PRIMES
|
|
|
|
|
RSA,130,NO_PUBLIC_EXPONENT
|
|
|
|
|
RSA,131,NULL_BEFORE_BLOCK_MISSING
|
|
|
|
|
RSA,132,N_NOT_EQUAL_P_Q
|
|
|
|
|
RSA,133,OAEP_DECODING_ERROR
|
|
|
|
|
RSA,134,ONLY_ONE_OF_P_Q_GIVEN
|
|
|
|
|
RSA,135,OUTPUT_BUFFER_TOO_SMALL
|
|
|
|
|
RSA,136,PADDING_CHECK_FAILED
|
|
|
|
|
RSA,137,PKCS_DECODING_ERROR
|
2017-04-11 17:46:03 +01:00
|
|
|
RSA,146,PUBLIC_KEY_VALIDATION_FAILED
|
Align with upstream's error strings, take two.
I messed up a few of these.
ASN1_R_UNSUPPORTED_ALGORITHM doesn't exist. X509_R_UNSUPPORTED_ALGORITHM does
exist as part of X509_PUBKEY_set, but the SPKI parser doesn't emit this. (I
don't mind the legacy code having really weird errors, but since EVP is now
limited to things we like, let's try to keep that clean.) To avoid churn in
Conscrypt, we'll keep defining X509_R_UNSUPPORTED_ALGORITHM, but not actually
do anything with it anymore. Conscrypt was already aware of
EVP_R_UNSUPPORTED_ALGORITHM, so this should be fine. (I don't expect
EVP_R_UNSUPPORTED_ALGORITHM to go away. The SPKI parsers we like live in EVP
now.)
A few other ASN1_R_* values didn't quite match upstream, so make those match
again. Finally, I got some of the rsa_pss.c values wrong. Each of those
corresponds to an (overly specific) RSA_R_* value in upstream. However, those
were gone in BoringSSL since even the initial commit. We placed the RSA <-> EVP
glue in crypto/evp (so crypto/rsa wouldn't depend on crypto/evp) while upstream
placed them in crypto/rsa.
Since no one seemed to notice the loss of RSA_R_INVALID_SALT_LENGTH, let's undo
all the cross-module errors inserted in crypto/rsa. Instead, since that kind of
specificity is not useful, funnel it all into X509_R_INVALID_PSS_PARAMETERS
(formerly EVP_R_INVALID_PSS_PARAMETERS, formerly RSA_R_INVALID_PSS_PARAMETERS).
Reset the error codes for all affected modules.
(That our error code story means error codes are not stable across this kind of
refactoring is kind of a problem. Hopefully this will be the last of it.)
Change-Id: Ibfb3a0ac340bfc777bc7de6980ef3ddf0a8c84bc
Reviewed-on: https://boringssl-review.googlesource.com/7458
Reviewed-by: Emily Stark (Dunn) <estark@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
2016-03-14 21:13:54 +00:00
|
|
|
RSA,138,SLEN_CHECK_FAILED
|
|
|
|
|
RSA,139,SLEN_RECOVERY_FAILED
|
|
|
|
|
RSA,140,TOO_LONG
|
|
|
|
|
RSA,141,TOO_MANY_ITERATIONS
|
|
|
|
|
RSA,142,UNKNOWN_ALGORITHM_TYPE
|
|
|
|
|
RSA,143,UNKNOWN_PADDING_TYPE
|
|
|
|
|
RSA,144,VALUE_MISSING
|
|
|
|
|
RSA,145,WRONG_SIGNATURE_LENGTH
|
