[gambit-list] HTTPS client

Mikael mikael.rcv at gmail.com
Wed Dec 18 09:35:25 EST 2013


I suggest relating to OpenSSL as only one among the unlimited zillions of
protocols out there,

and that by this reason, including OpenSSL support in Gambit is not the
solution, but rather, to update Gambit's IO system to support
implementation of non-leaky extremely-high-performance
application/user-level ports.

Next in line are various compression and crypto protocols.


2013/12/18 Marc Feeley <feeley at iro.umontreal.ca>
>
> There is no builtin support for SSL.  I have considered implementing this
> with OpenSSL or PolarSSL (which has the advantage of being lightweight and
> portable, see https://polarssl.org), but



> it is a non trivial job due to the complex API required for SSL.


Yes. Also because OpenSSL is maintained by only one guy who gives part time
to it, and its code is extremely bloated from its development process (this
is what the experts on #crypto say anyhow).


Protocols and their support libraries are a complete jungle - for instance;
I personally gave approximately one man month to implement an OpenSSL
channel wrapper in Gambit. The whimsical documentation was on several key
points indicative at best and inspiration from others' user code was
required. The result is a very good integration, however at the same time,

Factors like this put an upper ceiling on what quality is actually possible
to achieve for a particular integration/wrapper implementation, and this in
turn means there will always be situations when a particular implementation
is subqualitative and "in the way" and there is a palpable use of using
some-other implementation, for someone to make his own new one, and so on.

 Moreover, this would add an external library dependency for Gambit (the
> only one), which is a problem for portability, so a configure option would
> likely be added to disable SSL support.
>
> If someone wants to tackle this (i.e. implementing builtin support for
> SSL), I can help with the integration with Gambit's I/O system.  It would
> sure be nice to be able to open secure connections with Gambit.
>
> Marc



I've pondered a bit how such an application/user-level ports interface
would look.

To start with, a key decision would be if there should be support for
something like zerocopying IO, i.e. you have a sandwhich of a number of
such ports atop of each other and one or many of them is doing passive
passthrough/forwarding only for N bytes/chars/seconds - will the IO system
support that.

Perhaps that could be easily implemented if there's a convention that on
such use, the user must not mutate the structures fed into the IO system
any more.

This kind of design decisions could take a titanic-kind of direction though
if carefully made and thought through it could be enormously useful also;

any code and modules relating to data streams, IO, and also data processing
more generally, do at some point end up benefitting of having a qualitative
interface with Gambit's IO system, through such an application/user-level
ports interface.


I would be glad to participate in a conversation on the topic on how such a
application/user-level ports interface ought to look more specifically.

Mikael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131218/e15545e3/attachment.htm>


More information about the Gambit-list mailing list