Re: SSL option fail_if_no_peer_cert has the wrong default value
Vincent de Phily <[email protected]>
| Newsgroups | gmane.comp.lang.erlang.bugs |
|---|---|
| Organization | Mobile Devices |
| Message-ID | <1469496.YeGSKO4vTO@moltowork> |
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 _______________________________________________ erlang-bugs mailing list [email protected] http://erlang.org/mailman/listinfo/erlang-bugs