New EEP for extended error information

Bram Verburg bram.verburg@REDACTED
Wed Nov 4 08:12:03 CET 2020


Hi,

Nice one!

Regarding backwards compatibility, existing modules that implement a 'format_error/4' function for their own purposes might be affected, no? Perhaps the arguments won't match, the call will result in a badarg exception, which is caught and ignored. But unintended consequences from a call by the exception formatter can't be ruled out.

But the main point I want to raise is the following, and I do apologise if this exceeds the original scope of the proposal: The 'format_error/4' callback introduces an opportunity to suppress the value of sensitive parameters from a stack trace.

For instance, suppose I call `crypto:mac(hmac, sha256, Message, Key)` and in some code path Message ends up being `undefined`. The stack trace would currently leak the key:

** exception error: {badarg,{"mac.c",216},"Bad key"}
     in function  crypto:mac_nif/4
        called as crypto:mac_nif(hmac,sha256,undefined,<<"Supersecret">>)

The proposed format_error/4 callback allows the module, crypto in this case, to customise the exception message below the 'called as' line. Perhaps the callback could be extended to also allow the module to request suppression/masking of (some of) the arguments on that line as well. In its simplest form it might just return a flag requesting suppression of the actual arguments, showing only the arity.

Again, I realise this is perhaps out of scope for the EEP's intended scope, but it seems to me there is a window of opportunity to define the contract for the format_error/4 callback, and once this EEP is implemented it is may become harder to extend it to cover this additional use-case.

Regards,

Bram


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, November 4, 2020 7:18 AM, Björn Gustavsson <bjorn@REDACTED> wrote:

> There is a new EEP that suggests a way to show
> additional information about why a call to a BIF
> failed.
>
> Here is the EEP:
>
> https://github.com/erlang/eep/blob/master/eeps/eep-0054.md
>
> And here is the pull request for the implementation:
>
> https://github.com/erlang/otp/pull/2849
>
> /Björn
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Björn Gustavsson, Erlang/OTP, Ericsson AB




More information about the eeps mailing list