ObjFW  History of src/OFTLSStream.m of f2e96ebd9a89f730

Not implemented using any TLS library yet. file: [3b181aebf6] check-in: [43864736e7] user: js, branch: tls-server, size: 6516 [annotate] [blame] [check-ins using] [diff]

This allows for a much cleaner solution to avoid the internal read
buffer of e.g. a TLS connection never being processed while waiting for
a delimiter. file: [0b19f7bfbb] check-in: [a61e0594b4] user: js, branch: trunk, size: 4331 [annotate] [blame] [check-ins using] [diff]

These implementations all depend on additional libraries that are
otherwise not needed for an ObjFW application that does not use TLS,
meaning they would add unnecessary dependencies for a lot of
applications and waste memory. file: [ab25ba8801] check-in: [8f8af474fc] user: js, branch: trunk, size: 4331 [annotate] [blame] [check-ins using] [diff]

This implements OFTLSStream using Apple's Secure Transport. While Secure
Transport is declared deprecated by Apple, Apple so far has failed to
provide a suitable replacement. They recommend Network.framework as a
replacement, however it can neither work on arbitrary sockets, nor can
it do STARTTLS. file: [6023c3c0c6] check-in: [112eb62f7b] user: js, branch: trunk, size: 4220 [annotate] [blame] [check-ins using] [diff]

The previous API could never work cleanly and would always require
hacks, as it needed intercepting all interactions of OFTCPSocket with
the raw socket and did not work at all if the OFTCPSocket had anything
in its read buffer before starting the TLS handshake. This also could
not be fixed easily, as it would have required the object to contain two
read buffers, one for the unencrypted connection and one for the
encrypted connection. There was also no clean way to perform the
handshake in a non-blocking way.

The new API is a lot cleaner and requires none of the hacks, but using
it requires slightly more work. But this is more than made up for by
making a fully asynchronous handshake possible. It uses the concept of a
stream wrapping another stream, meaning the entire connecting part is
being handled by OFTCPSocket and then the connected socket is passed off
to OFTLSStream to wrap it. This also makes for a lot cleaner separation
of concerns. file: [53f8754aca] check-in: [d30efa8bbf] user: js, branch: trunk, size: 3817 [annotate] [blame] [check-ins using] [diff]

This should make it easier to add TLS support using various
implementations. file: [d6f41e909e] check-in: [34cb121dc5] user: js, branch: trunk, size: 4757 [annotate] [blame] [check-ins using]