Sorry. Inadvertently sent an empty reply. 

> On 24 Dec 2015, at 23:36, Tim Hume <[email protected]> wrote:
> 
> 
> 
>>> On 24 Dec 2015, at 02:16, Gilles Chehade <[email protected]> wrote:
>>> 
>>>> On Wed, Dec 23, 2015 at 07:56:25PM +0600, Denis Fateyev wrote:
>>>> On Wed, Dec 23, 2015 at 6:23 PM, Gilles Chehade <[email protected]> wrote:
>>>> 
>>>> 
>>>> Would your distribution be affected if LibreSSL became a requirement ?
>>>> 
>>>> OpenSMTPD is starting to rely on LibreSSL-specific functions that will
>>>> force us to go through painful hacks to maintain that dual SSL support
>>>> and I'd like to know if switching to a LibreSSL-only mode is an option
>>>> at this point or still too early.
>>> 
>>> 
>>> It would be a problem in RHEL (and its derivatives like CentOS, Scientific,
>>> Oracle, et al), and Fedora.
>>> There were no plans of implementing Libressl support before, and there are
>>> no plans to do it now.
>> 
>> I don't really get this, maybe there's a misunderstanding:
>> 
>> I understand that RHEL and others don't intend to switch to LibreSSL for
>> their default SSL library and I'm not suggesting they should, this isn't
>> our call, it's unreasonable to assume every system will switch and there
>> is no debate about this.
>> 
>> What I'm wondering is if there's any reason that would prevent RHEL, for
>> example, to package LibreSSL in the same way that libasr was packaged so
>> that OpenSMTPD could specifically depend on it.
>> 
>> The system would keep its default SSL library.
>> 
>> 
>>> As you might realize, linking Libressl statically is also not an option.
>> 
>> Yes, obviously I'm not advocating this ;-)
>> 
>> 
>>> In my opinion, there is no point to forcibly depend on Libressl unless big
>>> commercial players are interested in it.
>> 
>> Actually there are very strong rationales for this, I'll if you want but
>> the bottom line:
>> 
>> - we're currently trying to support OpenSSL and LibreSSL as being the
>> same library and we're hitting corner cases that require us to hack
>> around detection, hack around compat and backport parts of LibreSSL
>> code in standalone files just so OpenSSL keeps working.
>> 
>> - we're facing cases of OpenSSL-induced #ifdefs because depending who
>> built it, it lacks AES_GCM, it lacks SNI, it lacks this and that. I
>> have broken SNI support at least once because of this.
>> 
>> - ultimately, we want to get rid of the OpenSSL historical interface
>> and rely on LibreSSL's libtls which will make TLS code readable. I
>> think we can all agree that it's scary that the most dangerous bit
>> of code in OpenSMTPD is also the less readable and the most error-
>> prone, we should take some steps towards changing this...
>> 
>> 
>> 
>> 
>> -- 
>> Gilles Chehade
>> 
>> https://www.poolp.org                                          @poolpOrg
>> 
>> -- 
>> You received this mail because you are subscribed to [email protected]
>> To unsubscribe, send a mail to: [email protected]
> 
> -- 
> You received this mail because you are subscribed to [email protected]
> To unsubscribe, send a mail to: [email protected]
> 

--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]

Reply via email to