QSslSocket

[Thiago Macieira]

Alon Bar-Lev said:
> I am not Qt programmer... so I cannot tell... But is it seems the
> design of Qt uses signals to notify the user of the class. So during
> negotiation you should be notified that peer certificate is valid so
> you can validate it... But I really don't know.

The purpose of signals is to notify of information. Its use to require
information from the slots (by passing a reference or pointer) is a bit of
an abuse, though perfectly valid technically. I'd tend to avoid that, but
let's see what the developer comes up with.

>> For three reasons, at least:
>> 1) One less library being in memory if you don't use it at all;
>
> You can say this regarding any library you use...
> It is best to use the TLS/SSL/crypto engine as a plugin... Just as QCA
> does...

Indeed. That would be an even-better approach. But it can also be done at
a later time.

>> 2) OpenSSL's historic inability to maintain binary compatibility;
>
> True... But if you like with a specific version you also use this one.
> So there is no runtime overhead.

Actually, no. When you link to libssl or libcrypto, you get simply
"libssl.so.0" and "libcrypto.so.0". Any version matches that soname, so an
upgrade overwrites the link.

Distributions are aware of this and have taken different steps to solve
the problem. One (RH) decided to bump the sonames on their own, which is
where libssl.so.4 came from, even though the developers have never
released that version. Other distributions decided to write the full
version in the soname, so as to keep the properly linked versions.

Point is: we can't rely on that. So, linking dynamically to any OpenSSL is
potentially a source of problems.

>> 3) OpenSSL's license.
>
> There is no different in term of GPL if you statically or dynamically
> link, all is derived work.

The difference being that QtNetwork works rather fine if OpenSSL isn't
installed. Just no SSL support.

It would be even better if it gracefully switched to another backend. It
would help support the argument.

>> Hmm... I don't like the idea of using environment variables for that.
>> I'd
>> suggest you simply put your OpenSSL libraries in the \windows\system32
>> directory.
>
> The problem is NOT windows!!!

Oops. :-)

> If new OpenSSL release is available... on POSIX.
> Now, as you said it broke the ABI or it just has an issue.
> Qt will automatically use the latest one.

I see. Yeah, it should seek to load a version that it is known to work with.

The downside is that sticking to a known, old version can mean security
fixes aren't incorporated.

> If they will have environment/configuration/whatever the user may
> instruct it to load specific library, such as /usr/lib/libssl.so.0.9.7
> and no /usr/lib/libssl.so.0.9.8.

I know the developers. They won't agree to that. I wouldn't.

> Of course linking with a specific version is better... But already
> discussed this one.

Statically linking is bloating the library, and not always possible
(requires a linker that understands the "whole-archive" option).
Dynamically linking is potentially dangerous. Only runtime loading remains
as a solution.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358