[haiku-commits] Re: haiku: hrev50368 - src/kits/network/libnetapi headers/os/net
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 27 Jun 2016 07:20:10 +0200
On Fri, Jun 24, 2016 at 12:11:21AM +0200, Mark Hellegers wrote:
The converse of this is that it's now forced upon the application
whether it wants it or not. An application now has to jump through
to disable SNI or if they want to use it with a socket address
resolved by other means.
That's true, but looking at the current implementation of
BSecureSocket, it does not give you any control at all. If the
intention is to give this kind of control to the developer then I agree
that my implementation is flawed, but if it is not, then I think it is
fair to enable it automatically as that is what is expected in most
cases. Disabling it would be exceptional.
I think it is a good idea to provide a higher level API to developers.
If we require the server name to be set twice when working with SSL (or
HTTPS), the API will be more flexible, but more confusing. It is known
that a lot of apps working irectly with OpenSSL run into security
problems because so many things need to be checked or done manually:
SNI, requesting validation of the certificate chain, etc.
The single responsibility principle is good for designing the internals
of the classes, but not always the best approach when it comes to
designing an user facing API.
Other related posts: