[erlang-bugs] SSL option fail_if_no_peer_cert has the wrong default value
Vincent de Phily
vincent.dephily@REDACTED
Wed Mar 11 12:15:51 CET 2015
On Tuesday 10 March 2015 19:35:28 Ingela Anderton Andin wrote:
> > In f_i_n_p_c's case, changing the default would probably close more bugs
> > than it'd open. Importantly, the new bugs would cause a visible failure,
> > rather than the invisible security hole caused by the current bugs. It'll
> > be an annoyance for the minority of people who actually need
> > f_i_n_p_c=false, but it's a clear win overall.
> >
> > I even think that f_i_n_p_c should be completely deprecated, since it's
> > niche behavior can be obtained with a custom verify_fun. But it seems
> > like I'd have a hard time convincing you about that :p
>
> We will think about it. It is not entirely up to me, but my opinion will
> count.
Thanks, I hope I provided a good enough argument that the change is worth the
potential incompatibility.
> > Speaking of liking backward compatibility, I'm still hoping for a reply by
> > the OTP team to my last two emails (2015-02-19, 2015-02-20) about the
> > 17.3 partial_chain breakage ;)
>
> I am not quite sure I agree that it is a breakage! We do not like to be
> bug compatible! It is on my todo list!
Well my usecase was broken by it. I'm still open to an explanation that my
usecase was broken to begin with, but I think that it is very reasonable. On
the plus side, it got me to do a thorough code review and improve our unit
testing :)
Note that I'm not against changes, introcucing partial_chain is certainly
usefull. But beyond the docs that could be improved, something still doesn't
feel quite right. Maybe it's again a matter of default setting, we should have
a require_full_cert_chain option ? IMHO the ssl options need a good bit of
disentangleing, but it's hard to do without bringing incompatibilities.
--
Vincent de Phily
More information about the erlang-bugs
mailing list