Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Mar 2020 14:20:28 +0100
From: Solar Designer <>
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.



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.