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.