You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ParsePKCS8PrivateKey function of the x509 package has a couple of errors that would benefit from being converted into sentinel errors to support the errors.Is. The errors are returned here and here.
By converting these into package level and exported sentinel errors, downstream users will be able to use these in conjunction with errors.Is in order to determine an appropriate action, instead of resorting to parsing the error or blindly trying to parse the data with other functions.
I believe, but please correct me if I'm wrong, such a change would not break backwards compatibility given that the error returned would still be the same. My suggestion would be to create 3 new sentinel errors at the package level like this:
varErrUseParseECPrivateKey=errors.New("x509: failed to parse private key (use ParseECPrivateKey instead for this key format)")
varErrUseParsePKCS1PrivateKey=errors.New("x509: failed to parse private key (use ParsePKCS1PrivateKey instead for this key format)")
varErrUseParsePKCS8PrivateKey=errors.New("x509: failed to parse private key (use ParsePKCS8PrivateKey instead for this key format)")
The third, last, sentinel error is added as functions ParsePKCS1PrivateKey and ParseECPrivateKey can return similar errors and would also benefit from returning a sentinel error instead.
Additionally, it looks like ParsePKIXPublicKey can return a similar error about using ParsePKCS1PublicKey instead, which could also benefit from returning a sentinel error.
The text was updated successfully, but these errors were encountered:
Proposal Details
The ParsePKCS8PrivateKey function of the x509 package has a couple of errors that would benefit from being converted into sentinel errors to support the
errors.Is
. The errors are returned here and here.By converting these into package level and exported sentinel errors, downstream users will be able to use these in conjunction with
errors.Is
in order to determine an appropriate action, instead of resorting to parsing the error or blindly trying to parse the data with other functions.I believe, but please correct me if I'm wrong, such a change would not break backwards compatibility given that the error returned would still be the same. My suggestion would be to create 3 new sentinel errors at the package level like this:
The third, last, sentinel error is added as functions ParsePKCS1PrivateKey and ParseECPrivateKey can return similar errors and would also benefit from returning a sentinel error instead.
Additionally, it looks like
ParsePKIXPublicKey
can return a similar error about usingParsePKCS1PublicKey
instead, which could also benefit from returning a sentinel error.The text was updated successfully, but these errors were encountered: