[squid-dev] Patches proposal

Amos Jeffries squid3 at treenet.co.nz
Wed Feb 17 18:27:01 UTC 2016


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



More information about the squid-dev mailing list