When determining whether a certificate has been revoked, is an Error<T> really more desirable than a segfault? Would you even expect a "is certificate revoked" function to return an Error<T>?
> is an Error<T> really more desirable than a segfault?
It's only by happy coincidence that it manifests cleanly as a segfault. In the C language, dereferencing NULL causes undefined behaviour, so all manner of peculiar things can happen. This isn't just theoretical nit-picking, it can happen with real code:
The code in question [1] does indeed return Result<(), Error>. This makes sense - more than one thing can go wrong during the verification, and the details can be important in some situations.
In Rust, the signature of the function would be along the lines of `-> Result<whatever, Error>` and you'd have no choice but to handle the Error case of the Result or to panic. Either way, not a segfault.
> Would you even expect a "is certificate revoked" function to return an Error<T>?
Depends on how it's doing the check. If it has to fetch the CRL from the CRLdp or do OCSP with the OSCP AIA, like CAPI does, then it definitely has to have an error for when certificate revocation status is not available.
Honestly, even if I provide the cert & CRL, it should probably be able to throw an error if either one has invalid ASN.1 encoding or such.
You have no choice in rust. It wont compile unless you handle all error conditions.
You get Result< Data T, Error>. And you have to handle Error condition (usually kick it up stack, but it has to be handled somewhere) for it to compile.
What rust wouldn't prevent you from is forgetting to check for revocation, or doing it wrong.
It's only by happy coincidence that it manifests cleanly as a segfault. In the C language, dereferencing NULL causes undefined behaviour, so all manner of peculiar things can happen. This isn't just theoretical nit-picking, it can happen with real code:
• Raymond Chen's Undefined behavior can result in time travel (among other things, but time travel is the funkiest), https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...
• John Regehr's A Guide to Undefined Behavior in C and C++, Part 1, https://blog.regehr.org/archives/213 (ctrl-f for A Fun Case Analysis)