[squid-dev] Patches proposal

[Eliezer Croitoru]

I want to add couple cycles of mine to the subject.

On 18/02/2016 01:11, Alex Rousskov wrote:
>
>>>> >>>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.

+1

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

+1 but.. adding something.
Portability for some systems might be an issue. We can distinguish full 
fledged servers from some embedded systems(routers, switches etc..)

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

OK so we are talking about "functionality" in general.
However I do see one specific issue with a DISK and Redis DB.
If for any reason the site headers will contain HSTS rules and the Redis 
DB(mem only..) will be restarted then the certificate would be different 
and the client will probably(to my understating) get some nice error 
page from the browser.
So it's exactly the same as long the Redis DB is persistent and\or was 
not restarted recently.

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

I am sorry but if for example RedHat or any other distribution will have 
some issue
with one helper having the option to use more then one back-end they are 
in more troubles then builder\maintainer.
And what I mean is that this is not the first binary to do so.

>> >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 should be the default for any builder. A generic builder can never 
decide what to do with any more then minimal complexity packages(ie one 
or couple binaries).

>> >Which gets very annoying and/or
>> >tricky if the difference is ./configure parameters
>> >(--with/--without-hiredis) to produce different binaries.
> 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.

I think that the point would be choosing the defaults rather then the 
additions. For some builders adding "hiredis" support by default means 
they need to kind of "audit" or "validate" another whole side to the 
package. It might not only be just adding "hiredis" to the build but 
also testing couple other things.

I am not in the point to decide what to implement and what to do but 
"--without-hiredis" is fine for my RPMs(not saying William should 
implement it) . It will allow me to take in account that in the future I 
will want to add this dependency to the main package or to even package 
the specific binary by it's own to not affect the core package 
dependencies and giving the system admin the option to choose the 
packages installation policy.

Eliezer