Closed alli5723 closed 3 years ago
@mworrell and @seriyps, I have recreated the simple PR by adding log_level
to the available keys SSL_CONNECT_OPTIONS_KEYS
Hi, sorry for the late reply. In #274 we disabled any filtering of socket options, so now you should be able to provide whatever TLS and TCP options you like. May you, please, verify that the current master branch works fine for your scenario?
I believe smth like this should do the trick:
gen_smtp_client:send(..., [{tls_options, [{log_level, error}]}])
(however I personally would recommend to try to start using verify_peer
as described in https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/ssl)
Hi, sorry for the late reply. In #274 we disabled any filtering of socket options, so now you should be able to provide whatever TLS and TCP options you like. May you, please, verify that the current master branch works fine for your scenario?
I believe smth like this should do the trick:
gen_smtp_client:send(..., [{tls_options, [{log_level, error}]}])
(however I personally would recommend to try to start using
verify_peer
as described in https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/ssl)
@seriyps, the latest master satisfies my use-case. Thank you and I agree with your recommendation.
The latest change to erlang's SSL module prints a warning when verify_none is used as a verify option. This function only prints at a log level of warning, so it is possible for users to choose when they want to see such warnings.
This PR simply adds the log_level as one of the acceptable
SSL_CONNECT_OPTIONS_KEYS
, hence users are able to add log_level using sockopts as shown below.