letsencrypt
About the "detail" field of errors
Hi, it's me again.
The ACME RFC describes the "detail" field of errors as being human-readable. I understand that your stance is to avoid clients relying on implementation-specifics, but I think the RFC makes it very clear that the "type" field is for distinct, standardised values such as "urn:ietf:params:acme:error:malformed" for the computer to parse, and a "detail" field which is very clearly meant to be a) human-readable, and b) to be given to the human operator(s). It is also implied to provide the human operator(s) with error information that is specific to their error such as Invalid underscore in DNS name "_example.org".
Now to get back to my point, I think Parse error reading JWS does not match these guidelines, and I think it would not be too difficult to correct the code, so that people like myself could figure out problems like these a lot quicker:
If the error message were just a little more specific on what exactly the parse error was. 🙂
Hi, and welcome back!
You're absolutely correct that RFC8555 makes it clear that the "type" field is intended for machine use, while the "detail" field is intended for human use. Unfortunately it is our experience that many clients do things like parse the "detail" field in order to present to their user an even-more-human-readable string.
For better or worse, the error messages that we return are part of our API. This is why we try to carefully control the contents of those error messages. In particular, we don't want to directly expose error messages returned by third-party libraries, because those libraries might change their error messages, or we might change which libraries we use.
Your position, that this error message isn't detailed enough, is completely understandable. But at this time I don't think this case is enough to justify reversing our existing policy of not returning library errors verbatim.
Is there a reason that you're not using an existing JWS library in your language, to avoid having to deal with parsing errors at all?
To be honest, it sounds quite absurd to me developers would use the field in that way, but I trust you to know the bigger picture.
I would suggest maybe adding a different, non-standard field to make it clear that the value is specific to your go-jose library and is extremely volatile, but I guess that would be too much effort and would likely lead to developers doing the same thing anyway.
And many reasons not to use existing code; it would complicate licensing, I would likely have to spend a lot of time adjusting the API to fit my patterns, and when it comes to having to optimise it, I'd have to get really familiar with it, at which point I'd be spending more time maintaining a stranger's code than it would've taken me to do it myself. Besides, it is enjoyable to get into a random set of RFCs and to implement that stuff myself.
I've just never encountered an instance where the error reporting was so sparse, and then seeing the code responsible for it, did kind of insult me, because I saw there is an error message... you just didn't give it to me.
To be honest, it sounds quite absurd to me developers would use the field in that way, but I trust you to know the bigger picture.
It's absurd to me too, but that's just how it is :)
I've just never encountered an instance where the error reporting was so sparse, and then seeing the code responsible for it, did kind of insult me, because I saw there is an error message... you just didn't give it to me.
Yeah, I'm sorry that our error strings didn't have the level of detail you needed! Maybe it would be more useful to test your JWS implementation by feeding its output into a JWS parser you control, rather than sending its output to a live API.
I sent it to the staging environment. Thought that's supposed to be for building and testing implementations. :wink:
Hah fair point! I would say that it's generally for testing ACME implementations, not JWS implementations.
@aarongable Btw., Boudler is capable of emitting funny messages such as "x509: RSA modulus is not a positive number" because you do pass on the error message of your library for the FinalizeOrder endpoint: https://github.com/letsencrypt/boulder/blob/cba581301997b7ca5ebf44681ffbc0b090036e42/wfe2/wfe.go#L2215-L2220 Is this not inconsistent?