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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.