[squid-dev] Patches proposal

[Amos Jeffries]

On 18/02/2016 6:43 a.m., Alex Rousskov wrote:
> On 02/17/2016 10:29 AM, Amos Jeffries wrote:
>> On 18/02/2016 5:59 a.m., William Lima wrote:
>>>> the other uses Redis for certificate caches.
> 
>>> A polished version of this would be a very welcomed addition for busy
>>> bumping proxies IMO!
>>>
>>> AFAICT, this polishing would require generalizing Ssl::CertificateDb
>>> into a base class providing open/get/put/close API to ssl_crtd and
>>> containing any code common to the supported db flavors. Two
>>> Ssl::CertificateDb kids would then cover the two known flavors:
>>>
>>> * OpenSslDb: The current clunky on-disk OpenSSL cache (available if
>>> ssl_crtd was built with OpenSSL headers/library);
>>>
>>> * RedisDb: A shiny Redis database client (available if ssl_crtd was
>>> built with Redis headers/library).
>>>
>>> The selection between the two kids will be determined, in part, by a
>>> command line option.
> 
> 
> 
>> FYI: the model we have for helpers is that each backend type is
>> represented by a different helper binary that end-users configure to be
>> used (or not).
> 
> It is not clear where a helper configuration ends and "backend type"
> begin. IMHO, it is better to have
> 
> * a single helper that may be configured to use one of the two caching
> modes (with reasonable defaults making that customization optional!) than
> 
> * two helpers, each supporting only one caching mode (requiring the
> admin to always explicitly pick the right helper!).
> 
> 
>> The OpenSSL local filesystem one is now called "security_file_certgen".
>> A Redis DB helper would be "security_redis_certgen".
> 
> Why create a whole new binary?
> 

Because the "file" in its name means the data is stored to the local
filesystem in some "flat-file" DB format. My understanding is that redis
uses its own binary DB format.

The redis version requires a whole new library linkage, its header files
and code for its API use. As a result the two binaries will act very
differently when passed the same data. Depending solely on which backend
was chosen. With a lot of policy and security implications around those
differences.

For the squid.conf viewpoint the difference is trivial. But for the
maintenance, support, security, and distributor activities it makes a
lot of things easier to deal with two binaries.


> 
>> Being able to build or omit helpers based on what the final environment
>> contains is important for our redistributors and portability.
> 
> This is not about building or omitting a helper AFAICT. It is about what
> the helper does. Why not control that via a command line option, with
> good defaults (among other things such as ./configure tests)?

It is. A generic distro builder who builds two helpers leaves the
installers with the option to actually install only one binary if the
other does not meet local policy/security requirements.

In the generic builders this is best supported by providing different
packages with different binaries inside. Which gets very annoying and/or
tricky if the difference is ./configure parameters
(--with/--without-hiredis) to produce different buinaries.

Its also about explaining to users why this "file" helper does not
necessarily store things to the local FS, where all the others do.

Amos