On 08/08/2016 08:06 AM, Amos Jeffries wrote: > IMO, eCAP has pretty much stabilized.
We will need a new major eCAP version/release to accommodate backwards-incompatible C++11 builds as discussed at http://bugs.squid-cache.org/show_bug.cgi?id=4376#c19 https://bugs.launchpad.net/ecap/+bug/1595488 > Any objections to auto-enabling it whenever available? I fear the above problem needs to be solved first, but my response is not an objection -- this is not my area of expertise... IIRC, the primary reason why eCAP was not enabled by default (where available) was _not_ its stability but the fact that it is trivial to inject arbitrary code into Squid (via squid.conf) when loadable modules are enabled. IIRC, folks thought that there is too much risk in enabling that squid.conf vulnerability/attack vector by default. > That would also mean adding it as a builddependency on our farm nodes. > So we can explicitly fail build if eCAP code is overlooked in changes > like rev.14778. That should have been done long time ago IMHO. Testing eCAP builds should not depend on whether it is enabled by default. Cheers, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev