[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200324132028.GA11041@openwall.com>
Date: Tue, 24 Mar 2020 14:20:28 +0100
From: Solar Designer <solar@...nwall.com>
To: tlsify@...ts.openwall.com
Subject: Re: Interface design considerations
On Mon, Mar 23, 2020 at 03:43:19PM +0100, Joakim Sindholt wrote:
> On Mon, Mar 23, 2020 at 02:34:37PM +0100, Solar Designer wrote:
> > Or maybe we could have a wrapper program around tlsify for debugging?
> > Or just a different build of tlsify (with an extra source+object file,
> > producing a slightly larger binary) including also this functionality?
> > It does feel ridiculous not to include it as a standard tlsify feature
> > if we have it in the source tree anyway and it's tiny, though.
>
> Let's not GNU this up with tonnes of neat little options built in.
> Tlsify just transparently layers TLS. Nothing else. No conditional
> functionality. There might even be multiple implementations of the
> interface in the future. What we need is a solid spec so people DON'T
> end up embracing, extending and extinguishing us with some bloated
> rube-goldberg nightmare machine.
OK, multiple implementations is a valid reason to keep the spec and the
reference implementation limited to the basic functionality, and have
everything else as wrappers. Besides hopefully avoiding EEE, this will
also allow for replacing base tlsify implementations (e.g., those using
different TLS libraries), wrappers, and complete client/server programs
using tlsify separately from each other.
> Tlsify will also be capable of being a TLS server. For now I've focused
> exclusively on using it as a client but that will change.
Great!
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
