Skip to content

Breaking changes in upstream error types. #297

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #294
cpu opened this issue Mar 22, 2023 · 4 comments
Closed
Tracked by #294

Breaking changes in upstream error types. #297

cpu opened this issue Mar 22, 2023 · 4 comments

Comments

@cpu
Copy link
Member

cpu commented Mar 22, 2023

There were several upstream breaking API changes in Rustls related to error types:

The upstream changes will have to be adapted to error.rs and client.rs.

  • rustls::internal::msgs::enums::AlertDescription needs to be changed to the non-internal import.
  • InvalidCertificateEncoding, InvalidCertificateSignatureType, InvalidCertificateSignature, InvalidCertificateData, CorruptMessage, CorruptMessagePayload, PeerIncompatibleError, PeerMisbehavedError have been removed and need to be adapted to the more fine-grained error types that replaced them.
@cpu
Copy link
Member Author

cpu commented Mar 22, 2023

@jsha Do you have any thoughts on how the rustls_result enum should adapt to the upstream changes:

rustls-ffi/src/error.rs

Lines 137 to 152 in 55df122

// From https://docs.rs/rustls/0.20.0/rustls/enum.Error.html
CorruptMessage = 7100,
NoCertificatesPresented = 7101,
DecryptError = 7102,
FailedToGetCurrentTime = 7103,
FailedToGetRandomBytes = 7113,
HandshakeNotComplete = 7104,
PeerSentOversizedRecord = 7105,
NoApplicationProtocol = 7106,
BadMaxFragmentSize = 7114,
UnsupportedNameType = 7115,
EncryptError = 7116,
CertInvalidEncoding = 7117,
CertInvalidSignatureType = 7118,
CertInvalidSignature = 7119,
CertInvalidData = 7120, // Last added

For e.g. CertInvalidEncoding = 7117. The upstream InvalidCertificateEncoding entry in the Error enum this was being mapped to previously was removed and now we have InvalidCertificate(x) where x is something more specific like CertificateError::BadEncoding.

A couple questions I have:

  • Should all new additions use distinct u32 values not previously used, leaving gaps for the removed types?
  • Should there be a u32 per more specific CertificateError variant, or just for the top level InvalidCertificate?

I'm trying to implement some of these changes without having had time to do a lot of reading of the existing code, or the git blame. Any guidance is welcome :-)

@jsha
Copy link
Collaborator

jsha commented Mar 22, 2023

Should all new additions use distinct u32 values not previously used, leaving gaps for the removed types?

Yes, please.

Should there be a u32 per more specific CertificateError variant, or just for the top level InvalidCertificate?

Yes. The error design here is more-or-less "combinatorial explosion," since I looked at the error enum in rustls at the time and decided that splitting out errors for sub-variants was reasonable in scope.

For the Other sub-variant, we will have to drop the Arc<_> and any information in it, which is a bummer but the best approach for now.

I think sometime soonish we may want to rework errors in the FFI binding to accommodate more complex error types like Other and General without dropping useful information on the floor. But that can come after the next release; it will be a significant change.

@cpu
Copy link
Member Author

cpu commented Mar 22, 2023

I just noticed there was another PR that touched error content I missed in my original scan: rustls/rustls#1198 Added to the list in the PR desc.

I'm almost done adapting all the changes. I might run out of time today before I have a cleaned up PR ready for review but if that happens I should have something to share early tomorrow.

@cpu
Copy link
Member Author

cpu commented Mar 23, 2023

Fixed with #303

@cpu cpu closed this as completed Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants