Hostname validation

[amesgen]

Canonical disclaimer: I don't really know OpenSSL, I used https://wiki.openssl.org/index.php/Hostname_validation for reference.

Closes #14

I am not sure if the discussion in #14 concerning backwards compatibility still applies, as this PR should work with both 1.1.0 and 1.0.2 (which are not that new anymore). Maybe it is useful to expose a constant bool whether it is supported.

I tested this locally with OpenSSL 1.1.1.h with this test code by (un)commenting enableHostnameValidation ssl host.

[vshabanov]

Thank you. It's now on Hackage in HsOpenSSL-0.11.4.20.

[hvr]

@vshabanov that's great; nitpick though, this should have been HsOpenSSL-0.11.5.x to signal an API addition; otherwise the MIN_VERSION_HsOpenSSL() macro can't be used to detect the availability of this feature.

[amesgen]

@hvr One could work around this by introducing an auto flag:

flag HsOpenSSL-hostname-validation description: Whether HsOpenSSL supports hostname-validation default: True manual: False library if flag(HsOpenSSL-hostname-validation) build-depends: HsOpenSSL >= 0.11.4.20 cpp-options: -DHSOPENSSL_HOSTNAME_VALIDATION else build-depends: HsOpenSSL >= 0.11.2

[hvr]

@amesgen obviously there is an awkward (and error-prone) workaround possible, but why should one have to workaround than be able to use the designated mechanisms/facilities for this kind of problem?

The specific conditional you suggest isn't semantically sound; it's fragile and assumes a very specific search order which cannot be guaranteed in general (and it's easy to break externally if the flag is explicitly pinned to False); unfortunately, from experience as Hackage Trustee this kind mistake is not so rare; you can find other instances on Hackage... :-/

In any case this just goes to show and reinforce my point that such a workaround is not a good idea in the first place except as a last-resort. But I'm not sure what you were arguing for in the first place...

[amesgen]

I did not and don't want to argue that my snippet above is nothing but a workaround; a a.b.c -> a.b.(c+1) bump would be better.

But I am interested, what problem can occur other than the flag being manually set to False (which is somewhat contrived IMHO)? The cabal docs say:

By default, Cabal will first try to satisfy dependencies with the default flag value and then, if that is not possible, with the negated value. However, if the flag is manual, then the default value (which can be overridden by commandline flags) will be used.

Feel free to ignore this, it is only a curiosity 😄

[vshabanov]

Just uploaded version 0.11.5 so it will be easier to check for new API availability (and it also handles SSL_get_error bug with unexpected EOF so it has a slight behavior change too).