On 09/07/2017 12:14 AM, scsijon wrote:
>
>>
>> Part of my frustration is openssl and bearssl don't have quite the same
>> command line syntax. There's no standard "stunnel blah" command line I
>> can use that's implementation independent. Otherwise I'd just do the
>> "pipe it through a child
Part of my frustration is openssl and bearssl don't have quite the same
command line syntax. There's no standard "stunnel blah" command line I
can use that's implementation independent. Otherwise I'd just do the
"pipe it through a child process" thing and be done with it. (Might
still, it's
On 09/05/2017 04:52 PM, Robert Thompson wrote:
> When you get back to this, probably the two most useful places for
> seeing how much existing tls code is required for ktls would be
>
> https://github.com/ktls/af_ktls-tool/blob/master/client.c
>
When you get back to this, probably the two most useful places for seeing
how much existing tls code is required for ktls would be
https://github.com/ktls/af_ktls-tool/blob/master/client.c
https://github.com/ktls/af_ktls-tool/blob/master/xlibgnutls.c
The af_ktls-tool contains a bunch of testing
On 09/04/2017 08:22 PM, Robert Thompson wrote:
> From the toybox point of view, wouldn't this introduce direct link
> dependency on ssl/tls libraries?
There's already an optional dependency to accelerate hash calculations
(CONFIG_TOYBOX_LIBCRYPTO), and another to accelerate zlib, so I'm ok
with
Date: Sun, 3 Sep 2017 23:12:05 -0500
From: Rob Landley <r...@landley.net>
To: toybox <toybox@lists.landley.net>
Subject: [Toybox] [RFC] ktls is in 4.13.
Message-ID: <2ada100d-1403-989e-c2bc-4f5fef1d9...@landley.net>
Content-Type: text/plain; charset=utf-8
The kernel just m
>From the toybox point of view, wouldn't this introduce direct link
dependency on ssl/tls libraries?
If that's acceptable, the ktls stuff looks like a simple addition (on top
of base in-toybox tls) with potential performance improvements, once the
code settles down.
On Sun, Sep 3, 2017 at 11:12
