kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
a307cb7d58
boringssl/crypto/err/asn1.errordata

94 lines
2.6 KiB
Plaintext
Raw Normal View History

Get rid of err function codes. Running make_errors.go every time a function is renamed is incredibly tedious. Plus we keep getting them wrong. Instead, sample __func__ (__FUNCTION__ in MSVC) in the OPENSSL_PUT_ERROR macro and store it alongside file and line number. This doesn't change the format of ERR_print_errors, however ERR_error_string_n now uses the placeholder "OPENSSL_internal" rather than an actual function name since that only takes the uint32_t packed error code as input. This updates err scripts to not emit the function string table. The OPENSSL_PUT_ERROR invocations, for now, still include the extra parameter. That will be removed in a follow-up. BUG=468039 Change-Id: Iaa2ef56991fb58892fa8a1283b3b8b995fbb308d Reviewed-on: https://boringssl-review.googlesource.com/5275 Reviewed-by: Adam Langley <agl@google.com>
2015-06-29 04:36:21 +01:00
ASN1,100,ASN1_LENGTH_MISMATCH
ASN1,101,AUX_ERROR
ASN1,102,BAD_GET_ASN1_OBJECT_CALL
ASN1,103,BAD_OBJECT_HEADER
ASN1,104,BMPSTRING_IS_WRONG_LENGTH
ASN1,105,BN_LIB
ASN1,106,BOOLEAN_IS_WRONG_LENGTH
ASN1,107,BUFFER_TOO_SMALL
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
ASN1,108,CONTEXT_NOT_INITIALISED
ASN1,109,DECODE_ERROR
ASN1,110,DEPTH_EXCEEDED
ASN1,111,DIGEST_AND_KEY_TYPE_NOT_SUPPORTED
ASN1,112,ENCODE_ERROR
ASN1,113,ERROR_GETTING_TIME
ASN1,114,EXPECTING_AN_ASN1_SEQUENCE
ASN1,115,EXPECTING_AN_INTEGER
ASN1,116,EXPECTING_AN_OBJECT
ASN1,117,EXPECTING_A_BOOLEAN
ASN1,118,EXPECTING_A_TIME
ASN1,119,EXPLICIT_LENGTH_MISMATCH
ASN1,120,EXPLICIT_TAG_NOT_CONSTRUCTED
ASN1,121,FIELD_MISSING
ASN1,122,FIRST_NUM_TOO_LARGE
ASN1,123,HEADER_TOO_LONG
ASN1,124,ILLEGAL_BITSTRING_FORMAT
ASN1,125,ILLEGAL_BOOLEAN
ASN1,126,ILLEGAL_CHARACTERS
ASN1,127,ILLEGAL_FORMAT
ASN1,128,ILLEGAL_HEX
ASN1,129,ILLEGAL_IMPLICIT_TAG
ASN1,130,ILLEGAL_INTEGER
ASN1,131,ILLEGAL_NESTED_TAGGING
ASN1,132,ILLEGAL_NULL
ASN1,133,ILLEGAL_NULL_VALUE
ASN1,134,ILLEGAL_OBJECT
ASN1,135,ILLEGAL_OPTIONAL_ANY
ASN1,136,ILLEGAL_OPTIONS_ON_ITEM_TEMPLATE
ASN1,137,ILLEGAL_TAGGED_ANY
ASN1,138,ILLEGAL_TIME_VALUE
ASN1,139,INTEGER_NOT_ASCII_FORMAT
ASN1,140,INTEGER_TOO_LARGE_FOR_LONG
ASN1,141,INVALID_BIT_STRING_BITS_LEFT
Use new encoding functions in ASN1_mbstring_ncopy. Update-Note: This changes causes BoringSSL to be stricter about handling Unicode strings: · Reject code points outside of Unicode · Reject surrogate values · Don't allow invalid UTF-8 to pass through when the source claims to be UTF-8 already. · Drop byte-order marks. Previously, for example, a UniversalString could contain a large-valued code point that would cause the UTF-8 encoder to emit invalid UTF-8. Change-Id: I94d9db7796b70491b04494be84249907ff8fb46c Reviewed-on: https://boringssl-review.googlesource.com/28325 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-05-10 21:23:03 +01:00
ASN1,142,INVALID_BMPSTRING
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
ASN1,143,INVALID_DIGIT
ASN1,144,INVALID_MODIFIER
ASN1,145,INVALID_NUMBER
ASN1,146,INVALID_OBJECT_ENCODING
ASN1,147,INVALID_SEPARATOR
ASN1,148,INVALID_TIME_FORMAT
Use new encoding functions in ASN1_mbstring_ncopy. Update-Note: This changes causes BoringSSL to be stricter about handling Unicode strings: · Reject code points outside of Unicode · Reject surrogate values · Don't allow invalid UTF-8 to pass through when the source claims to be UTF-8 already. · Drop byte-order marks. Previously, for example, a UniversalString could contain a large-valued code point that would cause the UTF-8 encoder to emit invalid UTF-8. Change-Id: I94d9db7796b70491b04494be84249907ff8fb46c Reviewed-on: https://boringssl-review.googlesource.com/28325 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-05-10 21:23:03 +01:00
ASN1,149,INVALID_UNIVERSALSTRING
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
ASN1,150,INVALID_UTF8STRING
ASN1,151,LIST_ERROR
ASN1,152,MISSING_ASN1_EOS
ASN1,153,MISSING_EOC
ASN1,154,MISSING_SECOND_NUMBER
ASN1,155,MISSING_VALUE
ASN1,156,MSTRING_NOT_UNIVERSAL
ASN1,157,MSTRING_WRONG_TAG
ASN1,158,NESTED_ASN1_ERROR
ASN1,159,NESTED_ASN1_STRING
Limit ASN.1 constructed types recursive definition depth Constructed types with a recursive definition could eventually exceed the stack given malicious input with excessive recursion. Therefore we limit the stack depth. CVE-2018-0739 Credit to OSSFuzz for finding this issue. (Imported from upstream's 9310d45087ae546e27e61ddf8f6367f29848220d.) BoringSSL does not contain any such structures, but import this anyway with a test. Change-Id: I0e84578ea795134f25dae2ac8b565f3c26ef3204 Reviewed-on: https://boringssl-review.googlesource.com/26844 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-03-27 16:03:27 +01:00
ASN1,192,NESTED_TOO_DEEP
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
ASN1,160,NON_HEX_CHARACTERS
ASN1,161,NOT_ASCII_FORMAT
ASN1,162,NOT_ENOUGH_DATA
ASN1,163,NO_MATCHING_CHOICE_TYPE
ASN1,164,NULL_IS_WRONG_LENGTH
ASN1,165,OBJECT_NOT_ASCII_FORMAT
ASN1,166,ODD_NUMBER_OF_CHARS
ASN1,167,SECOND_NUMBER_TOO_LARGE
ASN1,168,SEQUENCE_LENGTH_MISMATCH
ASN1,169,SEQUENCE_NOT_CONSTRUCTED
ASN1,170,SEQUENCE_OR_SET_NEEDS_CONFIG
ASN1,171,SHORT_LINE
ASN1,172,STREAMING_NOT_SUPPORTED
ASN1,173,STRING_TOO_LONG
ASN1,174,STRING_TOO_SHORT
ASN1,175,TAG_VALUE_TOO_HIGH
ASN1,176,TIME_NOT_ASCII_FORMAT
ASN1,177,TOO_LONG
ASN1,178,TYPE_NOT_CONSTRUCTED
ASN1,179,TYPE_NOT_PRIMITIVE
ASN1,180,UNEXPECTED_EOC
ASN1,181,UNIVERSALSTRING_IS_WRONG_LENGTH
ASN1,182,UNKNOWN_FORMAT
ASN1,183,UNKNOWN_MESSAGE_DIGEST_ALGORITHM
ASN1,184,UNKNOWN_SIGNATURE_ALGORITHM
ASN1,185,UNKNOWN_TAG
ASN1,186,UNSUPPORTED_ANY_DEFINED_BY_TYPE
ASN1,187,UNSUPPORTED_PUBLIC_KEY_TYPE
ASN1,188,UNSUPPORTED_TYPE
Match upstream's error codes for the old sigalg code. People seem to condition on these a lot. Since this code has now been moved twice, just make them all cross-module errors rather than leave a trail of renamed error codes in our wake. Change-Id: Iea18ab3d320f03cf29a64a27acca119768c4115c Reviewed-on: https://boringssl-review.googlesource.com/7431 Reviewed-by: Emily Stark (Dunn) <estark@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2016-03-11 19:39:46 +00:00
ASN1,189,WRONG_PUBLIC_KEY_TYPE
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
ASN1,190,WRONG_TAG
ASN1,191,WRONG_TYPE
Reference in New Issue Copy Permalink