[squid-dev] [PATCH] Bug 4662 adding --with-libressl build option

[Amos Jeffries]

On 31/01/2017 7:04 a.m., Alex Rousskov wrote:
> On 01/29/2017 04:26 AM, Amos Jeffries wrote:
>> This is I think all we need to do code-wise to resolve the Bug 4662
>> issues with LibreSSL being incompatible with OpenSSL 1.1.
>>
>> The libraries cannot both be linked either way. If both --with-* options
>> are provided LibreSSL currently overrides OpenSSL. I picked that
>> preference order because AFAICS the LibreSSL has the lower overall
>> security footprint while providing the same (or better) needed
>> functionality.
>>
>>
>> NP: If there are no objections I would like to fast-track this and apply
>> in ~3 days (allowing for today being a sunday) for a slightly late
>> 4.0.18 beta.
> 
> I do not think these changes should be committed. As you probably know
> from earlier communication, I think we should avoid using both
> USE_OPENSSL and USE_LIBRESSL in the code if LibreSSL is [treated as] a
> replacement for OpenSSL. I have suggested several ways to avoid the
> dangerous and needless repetition of (USE_OPENSSL || USE_LIBRESSL)
> conditions, and we even seemed to agree on one of those solutions.
> 

IMO we only agreed on the HAVE_* macro usage for determining whether the
1.1 API was in use. Which is included in this patch.


I don't think the repetition of (USE_OPENSSL || USE_LIBRESSL) is either
needless or dangerous. No more than USE_OPENSSL was in the same spot.
Fixing the sheer number of uses is not in scope, tempting as it was to
drop some more completely.

Keep it simple. Only one macro per library. --with-foo sets USE_FOO.

The rest is normal precompiler operators which anyone knowing C/C++
should be able to easily read and can combine the libraries in all sorts
of fancy ways _iff_ necessary.

Going by that policy both libraries get named for code they support and
the || is used.


NP: I am only adding the "|| USE_LIBRESSL" parts in this patch because I
happen to know that the existing code is being used with LibreSSL and
found to be working. Future code will have to prove itself separately
for each library, OR at the submitters discretion (passing audit and QA
also) list the librares believed to be safe with it.


> 
> FWIW, I do not think bug 4662 blocks 4.0.18 beta.
> 

It is not a blocker, but I would like to avoid declaring LibreSSL as no
longer supported by v4 since the fix is not exactly hard.

Amos