Re: Libressl question

[Theo de Raadt]

> libtls is tied to libressl as a matter of convenience and happenstance,
> but it doesn't need to be that way.

If I recall, libtls requires the ability to pass certs as memory rather
than directly loading it from a file.  And OpenSSL native lacks any way
of doing this, and their team rejected the API which loads the file into
memory, for handling later.  Which is pretty foundational for use in
privsep programs which should not have a view on /etc.

Re: Libressl question

[Ted Unangst]

Brent Cook wrote:
> On Mon, Feb 12, 2018 at 09:27:16AM -0600, ed...@pettijohn-web.com wrote:
> > Has there been any discussion of packaging libtls separately from libressl 
> > for portable use? With my limited skills I was able to write a program to 
> > talk to smtpd and starttls using nothing but the manuals. I seriously doubt 
> > I could have done so with the gnu tls library. This really shows how well 
> > it is written as far as the code involved, but also the quality of the 
> > manuals. I only had one hickup and if I can think of a way to word it 
> > better I'll send a patch for that manual.

I missed this question. My answer is about the same as Brent's regarding what
needs to be done. I do think it's worthwhile (somebody should totally do this
for values of somebody that may not be me :)). I'll add that I think the API
we developed was an important contribution and I'd like to see more people use
it. libtls is tied to libressl as a matter of convenience and happenstance,
but it doesn't need to be that way.

The API should (i hope so) be independent of implementation. One of the goals
was to help solve the monoculture problem by allowing differing
implementations to be more easily swapped. There have been a few experiments
over time to prove the viability of this approach, but nothing supported. And
the API was in flux for a long time, but I think it's settled down now. We
still add new stuff (sessions), but one could start with a core.

To sum up, go forth and good luck. :)



>   I had a working version a couple of years ago against OpenSSL. There
>   were a few challenges even with a closely-related library:
> 
> 1. libtls can and does reply on LibreSSL-specific features in the
>core library, e.g. for privilege separation. These would either
>need to be ported into OpenSSL or a compatibility interface
>provided in addition to the libtls interface.
> 
> 2. Which version of the OpenSSL API / ABI to support? Now that
>OpenSSL is incompatible between 1.1 and 1.0, even more
>workarounds may be needed.
> 
> 3. The libtls API is usually defined in terms of the LibreSSL
>version it ships with, and changed somewhat quickly.
>Would libtls-standalone be shipped as part of the target library?
>How would we sync API / ABI changes between them.
> 
> You could probably port libtls to have a gnutls backend, though you may
> have to implement more lower-level changes in gnutls as well to support
> some of the features. The longer-term support, release, and
> fragmentation issues also remain.
> 

Re: Libressl question

[Brent Cook]

On Mon, Feb 12, 2018 at 09:27:16AM -0600, ed...@pettijohn-web.com wrote:
> Has there been any discussion of packaging libtls separately from libressl 
> for portable use? With my limited skills I was able to write a program to 
> talk to smtpd and starttls using nothing but the manuals. I seriously doubt I 
> could have done so with the gnu tls library. This really shows how well it is 
> written as far as the code involved, but also the quality of the manuals. I 
> only had one hickup and if I can think of a way to word it better I'll send a 
> patch for that manual.
>
> Thanks,
>
> Edgar

Hi Edgar,

  I had a working version a couple of years ago against OpenSSL. There
  were a few challenges even with a closely-related library:

1. libtls can and does reply on LibreSSL-specific features in the
   core library, e.g. for privilege separation. These would either
   need to be ported into OpenSSL or a compatibility interface
   provided in addition to the libtls interface.

2. Which version of the OpenSSL API / ABI to support? Now that
   OpenSSL is incompatible between 1.1 and 1.0, even more
   workarounds may be needed.

3. The libtls API is usually defined in terms of the LibreSSL
   version it ships with, and changed somewhat quickly.
   Would libtls-standalone be shipped as part of the target library?
   How would we sync API / ABI changes between them.

You could probably port libtls to have a gnutls backend, though you may
have to implement more lower-level changes in gnutls as well to support
some of the features. The longer-term support, release, and
fragmentation issues also remain.