[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