There are three more specific TLS/SSL errors that were covered by the generic "other errors" case before: * revoked (certificate in CRL or cancelled via OCSP or other mechanism) * insecure (broken algorithm (eg MD2) or otherwise cryptographically weak) * limit exceeded (certificate parameters large enough to indicate DOS attempt, or TLS/SSL implementation does not support sufficiently large parameter range)
I opened bug #23933 about the future use of these errors in Gabble.
Typo: "peer rovided", and in future please try not to mingle two logically distinct changes (editorial changes to LimitExceeded, and addition of Revoked and Insecure) into one commit. I'm not convinced we really need enum members for these (Revoked could be a subtype of Expired without much of a stretch, and LimitExceeded and Insecure could be a subtype of OtherError).
(Please reinstate the patch keyword when this is ready for review again.)
Ping? Vivek, what's the status of these?
Revoked is _very_ distinct from expired: it means that someone with the authority to do so has quite deliberately taken active steps to make sure the cert i sno longer considered valid: I think it would be very bad to conflate expired and revoked: For one thing, we ourselves treat revoked as invalid even when in lenient mode, whereas we allow expired certs. Similarly limit exceeded indicates that we have crossed a line which the user or packager has chosen as a probable DOS attack, and insecure means the same people have decided a cert/crypto is not sufficiently secure, so we shouldn't really bury these inside the generic error. Typo fixed.
(In reply to comment #5) > Revoked is _very_ distinct from expired: it means that someone with the > authority to do so has quite deliberately taken active steps to make sure > the cert i sno longer considered valid: I think it would be very bad to > conflate expired and revoked: For one thing, we ourselves treat revoked > as invalid even when in lenient mode, whereas we allow expired certs. Would you prefer that Telepathy clients that don't understand the specific error in the ConnectionError signal treat Revoked like None_Specified ("unspecified error"), or like Expired? This determines whether it needs its own enum member or not. > Similarly limit exceeded indicates that we have crossed a line which the > user or packager has chosen as a probable DOS attack, and insecure means > the same people have decided a cert/crypto is not sufficiently secure, so > we shouldn't really bury these inside the generic error. Similarly, would you prefer Limit_Exceeded and Insecure to be treated like None_Specified, or like Cert_Other_Error, by clients that don't understand the specific reason given in the ConnectionError signal? If the former is OK, they can have their own enum members.
This has now been fixed together with bug 29018.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.