CT Test Results

    2 files    14 suites   5m 16s ⏱️
207 tests 205 ✔️ 2 💤 0 ❌
222 runs  220 ✔️ 2 💤 0 ❌

Results for commit 6e3758d.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

@andreasanta would this solve your problem? As a critical extension should be able to be handled by the
user, I think we need to make it handlable by the verify_fun which possibly could understand the encoding error.

Thank you! I think that almost solves it! I added a minor comment because I think there is an error being thrown when parsing fails. I agree that we should delegate control to verify_fun and let the caller decide.

There is another potential improvement we may want to tackle in a separate task, the trace from the parsing was not very clear in my opinion. Is there a way to get a better error from the OTP-PUBLIC-KEY module?

@andreasanta I adjusted the implementation as you are correct that an error will be raised. Do you have a certificate that you could contribute as a test case with an extension that will fail the decoding? As for your other question, the module OTP-PUBLIC-KEY is generated by the asn1 compiler so enhancements in that area would be enhancments to the ASN1 compiler.

@andreasanta just realized you provided one in the issue, thanks I will use that!

@andreasanta also realized my first solution was correct an error tuple will actually be returned, so I changed the code back.

@andreasanta also realized my first solution was correct an error tuple will actually be returned, so I changed the code back.

Fantastic, thanks.

Please use this for unit tests:

public_key:pkix_decode_cert(
   base64:decode(
<<"MIICXDCCAgKgAwIBAgIBATAKBggqhkjOPQQDAjApMRkwFwYDVQQFExBjOTY4NDI4OTMyNzUwOGRiMQwwCgYDVQQMDANURUUwHhcNMjIxMDI5MTczMTA3WhcNMjkwNDE2MjAzNDUzWjAfMR0wGwYDVQQDExRBbmRyb2lkIEtleXN0b3JlIEtleTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFmIQDus/jIZ0cPnRCITCzUUuCjQBw8MetO6154mmTL8O/fFlGgYkZ6C8jSSntKC/lMwaZHxAgW1AGgoCrPuX5ejggEjMIIBHzALBgNVHQ8EBAMCB4AwCAYDVR0fBAEAMIIBBAYKKwYBBAHWeQIBEQSB9TCB8gIBAgoBAQIBAwoBAQQgyvsSa116xqleaXs6xA84wqpAPWFgaaTjCWBnZpHslmoEADBEv4VFQAQ+MDwxFjAUBAxjb20ud2hhdHNhcHACBA0+oAQxIgQgOYfQQ9EK769ahxCzZxQY/lfg4ZtlPJ34JVj+tf/OXUQweqEFMQMCAQKiAwIBA6MEAgIBAKUIMQYCAQYCAQSqAwIBAb+DdwIFAL+FPQgCBgGEJMweob+FPgMCAQC/hUAqMCgEIFNB5rJkaXmnDldlMAeh8xAWlCHsm92fGlZI91reAFrxAQH/CgEAv4VBBQIDAV+Qv4VCBQIDAxUYMAoGCCqGSM49BAMCA0gAMEUCIF0BwvRQipVoaz5SIhsYbIeK+FHbAjWPgOxWgQ6Juq64AiEA83ZLsK37DjZ/tZNRi271VHQqIU8mdqUIMboVUiy3DaM=">>
   ),
otp).

Unfortunately, this sort of general discarding of decoding errors could cause problems in other places, such as CRL validation. And probably in general is better not to allow arbitrary decoding errors. We are thinking of making the solution more of a specific workaround for this specific error that will also not mess with the CRL validation. I will update the PR once we have had time to work something out.

I see. But in theory, if the default verify_fun rethrows an error in this case, unless the callee override the fun, it should still behave as expected by other libraries, no?

Hi @IngelaAndin may I ask how is the change coming along, do you have any blockers you'd like to discuss? Thanks.

@IngelaAndin Is there anything we could do to help out with to move forward with a solution?

I assume the hold-up is partly because the resulting decoded #'OTPCertificate'{} is invalid because it cannot be re-encoded as-is?

Would it make sense to have (1) a function or module callback that could be optionally provided during decode so that these errors could be handled and (2) some sort of extension to the SupportedExtensions in #'Extension'{} which allows extnValue to be a "raw value" or "decoding error value"?

Context: we are running into a significant number of production decoding errors related to Android-based hardware-backed Key Attestation.

We appreciate your help, please let me know if there's anything we could do to arrive at an agreeable solution.

@potatosalad @IngelaAndin Potentially we can also keep the current behaviour by rethrowing in case a malformed exception is found. And we could control that behaviour with a flag passed as options to pkix_decode_cert and pkix_path_validation.

For instance:
public_key:pkix_decode_cert(..., otp, {do_not_throw, true}).

In any case, currently the implementation throws a badmatch, I would at least recommend to throw a specific error with the extension name that failed validation, so it can be trapped by the caller and floated to the user. If we fixed this and passed the error to verify_fun passed to pkix_path_validation, by default it could rethrow and a customised one could instead trap a specific extension name and handle gracefully.

Thank you both for your efforts 🙏

@IngelaAndin and I have discussed this and we think we can find a solution. We have now primarily thought about the problem when setting up a TLS connection and the certificate contains extensions of which one or some of them have an erroneous data.
The problem as we see it is that we have a number of known extensions (hard coded) and if the decoding of one of them fails the whole connection setup fails or the whole handling of the certificate fails. And this failure happens even if the faulty extension is not needed further on in the connection setup (or other handling of the certificate). In this particular case it is the extension CRLDistributionPoints which is faulty but it is not really needed unless the user has ordered a CRL validation with {crl_check true}. What we can do is to remove the CRLDistributionPoints from the known extensions or redefine the known extensions to mean the mandatory decoded extensions and let the other extensions be decoded when they are needed. This would solve this particular problem. It would also be good to return the failing extension whenever there is a failure during decode. We we look further into this after we have released OTP 26 RC1 next week.

Replaced by #6883