[squid-dev] OpenSSL 1.1 regression

[Ingo Schwarze]

Hi,

Alex Rousskov wrote on Thu, May 18, 2017 at 10:48:15AM -0600:
> On 05/18/2017 10:23 AM, Christos Tsantilas wrote:

>> However is not easy to always use this method. The OpenSSL-1.1.0 put
>> many API changes trying to hide structure members from user and replace
>> with API calls instead. Also has many API changes, I suppose to make API
>> more consistent.
>> 
>> This is resulted to many changes and it will not be easy to check
>> availability for each of the investigated functions and API changes.

That is indeed very true.

Basically, OpenSSL-1.0.x and OpenSSL-1.1.x are two quite different
APIs, and it is impossible to support both in the same application
program without either littering the code with lots of #ifdefs (no
matter whether testing for version numbers or features) or defining
large numbers of private wrappers.  Both solutions are hard to
maintain, cause a lot of work, and both are problematic from a
security perspective because both substantially hinder code auditing.
OpenSSL does not offer any kind of migration path from OpenSSL-1.0.x
to OpenSSL-1.1.x but dumps the maintenance cost of having to support
both APIs in parallel on each and every application software project.

That is exactly why - just as an example - OpenSSH decided to not
support the OpenSSL-1.1.x API at all, for now.  Of course, i don't
have the slightest idea whether that would be viable for squid.

> Individual feature tests are not panacea. When dealing with a large
> across-the-board change like the one you are describing above, [...]

FTR, i fully agree that *individual* feature tests are not a good
fit for *large-scale* API changes, and well-designed feature group
tests can occasionally help.  But even with those, supporting two
very different APIs in the same program tends to get messy no matter
what and will usually obfuscate the code.

Yours,
  Ingo