[erlang-questions] Adjusting the error level for SSL alerts?

Ingela Andin ingela.andin@REDACTED
Thu Dec 8 16:06:22 CET 2016


Hi!

2016-12-08 12:09 GMT+01:00 Roger Lipscombe <roger@REDACTED>:

> When using ssl, it's possible to set the 'log_alert' value to true or
> false. If true, SSL/TLS alerts are logged using error_logger:format.
> If false, they're simply dropped.
>
> See https://github.com/erlang/otp/blob/OTP-19.1.6/lib/ssl/src/
> ssl_connection.erl#L2352
>
> error_logger:format outputs the message as an 'error'.
>
> We use lager with a custom backend that turns error reports into
> emails. This means that we have to use {log_alert, false}, lest we get
> inundated with email reports of SSL alerts due to random port scans,
> etc.
>
> I was wondering whether it would be possible to control the error
> level that ssl uses. That is: instead of {log_alert, true} and
> {log_alert, false}, we could, instead, use that to define the log
> level, such as {log_alert, false | info | warning | error}, and have
> that translate to: no-op, error_logger:info_msg,
> error_logger:warning_msg, etc.
>
> Then the TLS alerts would naturally arrive as lager messages at
> 'info', 'warning' or 'error' level, as appropriate.
>
> This would, in turn, mean that they get written to our log file, but
> don't result in noisy error emails, unless we want them to.
>
> Obviously, 'true' would be treated as a synonym for 'error', for
> backwards-compatibility.


This sounds ok to me.


Alternatively, an extra option,
> 'log_alert_level', defaulting to 'error', might make more sense.
>
>

I have mixed feelings about this. There are already so many options that
keeping the number of options down when possible seem appealing. Also I am
not a big fan of having different options that
that have an impact on each other (other than overriding), granted such
options already exist (atleast on inet level).



> More simply, but less flexible, and having global effect, changing
> error_logger:format to error_logger:warning_msg would allow
> coarse-grained control of the resulting logging level by use of the +W
> emulator flag.
>
>
Seem like a less general solution that could easily be broken by someone
not knowing the rational behind it.


Regards Ingela Erlang/OTP team - Ericsson AB

(Aside: the +W default value appears to have changed at some point
> between 17.5 and 19.1...).
>
> Does any of this sound like a sensible proposal? If so, I'll try to
> find time to put together a pull request.
>
> --
> Cheers,
> Roger.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161208/e245f056/attachment.htm>


More information about the erlang-questions mailing list