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
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
