[squid-dev] Patches proposal

[Alex Rousskov]

On 02/17/2016 11:27 AM, Amos Jeffries wrote:
> On 18/02/2016 6:43 a.m., Alex Rousskov wrote:
>> On 02/17/2016 10:29 AM, Amos Jeffries wrote:
>>> 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 current helper name does not answer the question: If the current
helper was badly renamed to wrongly limit its scope, then we should
surely rename it again to avoid that limitation.


> The redis version requires a whole new library linkage, its header files
> and code for its API use.

Yes, but why is that important here? Many Squid features require "whole
library linkage and header files". Those dependencies do not result in
ten Squid binary names as far as we are concerned.


> As a result the two binaries will act very
> differently when passed the same data.

They will act exactly the same from the caller point of view. The
database is one of the many internal optimizations.


> With a lot of policy and security implications around those differences.

Same with configuring Squid to use different cache_dirs, but we do not
create many Squid executables because of the many cache_dir types.


> 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.

That sounds like a valid argument, although you seem to be invalidating
it below. Not sure our cycles are best spent accommodating such cases,
but you know better.


> In the generic builders this is best supported by providing different
> packages with different binaries inside.

Which means the "generic builder" is no longer "generic". It is a person
that understands the difference between various Squid pieces. Such a
person can create multiple binaries using ./configure options and/or VMs.


> Which gets very annoying and/or
> tricky if the difference is ./configure parameters
> (--with/--without-hiredis) to produce different buinaries.

You may be right, but it is not obvious to me why different ./configure
options is such a big deal to a person who already understands the
difference between two certificate generation helpers that Squid builds
by default and who have installed enough libraries for both helpers to
be built by default.


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

The letters "file" is a red herring IMO. They can and perhaps should be
changed.


William, when creating two binaries, please do not duplicate C++ code.
If that complicates things, just think of all the benefits for the
generic distro builders accommodating installers with special requirements!


Thank you,

Alex.