noc | 5 May 11:40 2016

Build failed in Jenkins: trunk-matrix » gcc,d-debian-jessie #638

See <,label=d-debian-jessie/638/>

[...truncated 44549 lines...]
make[4]: *** Waiting for unfinished jobs....
/bin/bash: ../../libtool: No such file or directory
Makefile:871: recipe for target 'Action.lo' failed
make[4]: *** [Action.lo] Error 127
/bin/bash: ../../libtool: No such file or directory
/bin/bash: ../../libtool: No such file or directory
Makefile:871: recipe for target 'ActionPasswordList.lo' failed
make[4]: *** [ActionPasswordList.lo] Error 127
Makefile:871: recipe for target 'ActionWriter.lo' failed
make[4]: *** [ActionWriter.lo] Error 127
make[4]: Leaving directory '<,label=d-debian-jessie/ws/btlayer-02-maximus/squid-4.0.9-BZR/_build/src/mgr'>
Makefile:6923: recipe for target 'install-recursive' failed
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory '<,label=d-debian-jessie/ws/btlayer-02-maximus/squid-4.0.9-BZR/_build/src'>
Makefile:7441: recipe for target 'install' failed
make[2]: *** [install] Error 2
make[2]: Leaving directory '<,label=d-debian-jessie/ws/btlayer-02-maximus/squid-4.0.9-BZR/_build/src'>
Makefile:574: recipe for target 'install-recursive' failed
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory '<,label=d-debian-jessie/ws/btlayer-02-maximus/squid-4.0.9-BZR/_build'>
Makefile:782: recipe for target 'distcheck' failed
make: *** [distcheck] Error 1 result is 2
BUILD: .././test-suite/buildtests/layer-02-maximus.opts
configure: BUILD LIBRARIES: 
configure: BUILD EXTRA LIBRARIES: -ldl -lm -lnsl -lresolv -lcap -lrt -ldl -ldl
(Continue reading)

Alex Rousskov | 4 May 18:58 2016

HttpHeader::delById leaks


    AFAICT, the following trunk code leaks every "deleted" header field:

> HttpHeader::delById(Http::HdrType id)
> {
>     //replace matching items with nil and count them
>     std::replace_if(entries.begin(), entries.end(),
>     [&](const HttpHeaderEntry *e) {
>         if (e && e->id == id) {
>             ++count;
>             return true;
>         }
>         return false;
>     },
>     nullptr);

The leak was created in trunk r14285 dated 2015-09-05: Refactor
HttpHeader into gperf-generated perfect hash.

> $ bzr grep  delById | wc -l
> 39

Please fix if you can.

Thank you,

(Continue reading)

Christos Tsantilas | 3 May 11:32 2016

Handshake Error: ccs received early (part2)

Squid currently does not handle SSL server responses that start with an 
SSL Alert Record. Squid fails to parse the Server Hello message and also 
fails to detect and handle resuming sessions.

This is a patch only for squid-3.5.
For the trunk the fix will be included in the new SSL messages parser, 
which also fixes others problems too and improve peek-and-splice related 
source code and performance.

This is a Measurement Factory project.
squid-dev mailing list
squid-dev <at>
Amos Jeffries | 2 May 05:18 2016

Re: [PATCH] Don't force -b 2048 into sslcrtd_program arguments

On 29/04/2016 4:21 p.m., Amos Jeffries wrote:
> On 29/04/2016 4:03 p.m., Nathan Hoad wrote:
>> Hello,
>> Attached is a patch that moves the filesystem block size retrieval for the
>> default certificate generation helper out of Ssl::Helper::Init() and into
>>, so that non-default helpers can work as expected
>> without having to handle this argument.
>> My usecase: I'm using nc for sslcrtd_program, to connect to a daemon that
>> generates certificates. nc (understandably) rejects the argument that this
>> patch moves. I realise I could have written a wrapper script of some sort
>> to bypass the issue completely, but this feels like the more correct thing
>> to do.
>> As mentioned in the patch preamble, I wanted to use fsBlockSize, but due to
>> the sheer number of dependencies it introduces, it seemed infeasible to do
>> so. I cannot see how to do this without a substantial code shift.
> Yes this is the right approach to fix. Squid should not be imposing
> command line parameters on any helpers.
> +1.
> Amos

Applied as trunk rev.14658.

(Continue reading)

Florian Schüttler | 27 Apr 21:01 2016

Piping existing SSL session into squid SSL session cache

Dear developers,

I am trying to evaluate a special use case for which I would appreciate
some advice on implementation issues.

I have a scenario in which clients (<10) are connected to a server using
an application protocol inside a TLS connection. These clients should
now be able to reuse the existing TLS session for a TLS connection to
Squid running on the same server by passing the session (e.g. using two
OpenSSL s_client instances and parameter -sess_out resp. -sess_in). That
would save an expensive key exchange operation. So far, my application
server writes the session info to a named pipe when the handshake is
completed using OpenSSL's PEM_write_SSL_SESSION().

I would now like to implement a feature in Squid which periodically
reads the pipe and adds this session information to the staticSslContext
in Squid using PEM_read_SSL_SESSION(). Ideally, this would integrate
into the event scheduling infrastructure (commEngine?) and not just be
hacked into the main loop, but I can not find easy documentation about
how to achieve this. Can anyone give me some pointers?

Best regards,
Florian Schüttler
squid-dev mailing list
squid-dev <at>
Alex Rousskov | 27 Apr 19:14 2016

[PATCH] Accumulate less


    The attached patch changes Squid to accumulate fewer unknown-size
responses to avoid overwhelming disks.

Patched Squid starts swapping out an unknown-size entry as soon as
size-based cache_dir selection is no longer affected by the entry
growth. If the entry eventually exceeds the selected cache_dir size
limits, terminate the swapout. This approach avoids generating hundreds
or even thousands of disk write requests in a tight doPages() loop
when the entire large response without Content-Size is received.

The following description assumes that Squid deals with a cachable
response that lacks a Content-Length header. These changes should not
affect other responses.

Prior to these changes, StoreEntry::mayStartSwapOut() delayed swapout
decision until the entire response was received or the already
accumulated portion of the response exceeded the [global] store entry
size limit, whichever came first. This logic protected Store from
entries with unknown sizes. AFAICT, that protection existed for two reasons:

* Incorrect size-based cache_dir selection: When cache_dirs use
  different min-size and/or max-size settings, Squid cannot tell which
  cache_dir the unknown-size entry belongs to and, hence, may select the
  wrong cache_dir.

* Disk bandwidth/space waste: If the growing entry exceeds all cache_dir
  max-size limits, the swapout has to be aborted, resulting in waste of
  previously spent resources (primarily disk bandwidth and space).
(Continue reading)

noc | 25 Apr 11:40 2016

Build failed in Jenkins: trunk-matrix » gcc,d-ubuntu-utopic #629

See <,label=d-ubuntu-utopic/629/>

[...truncated 21395 lines...]
libtool: compile:  ccache g++ -DHAVE_CONFIG_H -I../../.. -I../../../include -I../../../lib
-I../../../src -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow
-Woverloaded-virtual -Werror -Wno-deprecated-register -pipe -g -std=c++11 -MT ModUdp.lo -MD -MP -MF
.deps/ModUdp.Tpo -c ../../../src/log/ -o ModUdp.o
depbase=`echo CustomLog.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ../../libtool  --tag=CXX   --mode=compile ccache g++ -DHAVE_CONFIG_H   -I../../..
-I../../../include -I../../../lib -I../../../src -I../../include     -Wall -Wpointer-arith
-Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -Wno-deprecated-register -pipe
-g  -std=c++11 -MT CustomLog.lo -MD -MP -MF $depbase.Tpo -c -o CustomLog.lo
../../../src/log/ &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  ccache g++ -DHAVE_CONFIG_H -I../../.. -I../../../include -I../../../lib
-I../../../src -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow
-Woverloaded-virtual -Werror -Wno-deprecated-register -pipe -g -std=c++11 -MT CustomLog.lo -MD -MP
-MF .deps/CustomLog.Tpo -c ../../../src/log/ -o CustomLog.o
depbase=`echo TcpLogger.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ../../libtool  --tag=CXX   --mode=compile ccache g++ -DHAVE_CONFIG_H   -I../../..
-I../../../include -I../../../lib -I../../../src -I../../include     -Wall -Wpointer-arith
-Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -Werror -Wno-deprecated-register -pipe
-g  -std=c++11 -MT TcpLogger.lo -MD -MP -MF $depbase.Tpo -c -o TcpLogger.lo
../../../src/log/ &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  ccache g++ -DHAVE_CONFIG_H -I../../.. -I../../../include -I../../../lib
-I../../../src -I../../include -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow
-Woverloaded-virtual -Werror -Wno-deprecated-register -pipe -g -std=c++11 -MT TcpLogger.lo -MD -MP
-MF .deps/TcpLogger.Tpo -c ../../../src/log/ -o TcpLogger.o
(Continue reading)

Amos Jeffries | 23 Apr 14:30 2016

[PATCH] helpers queue update

This is a hopefully minor update to the helper lookup queueing.

It removes the only use of MEM_DLINK_NODE for custom link-list
implementation and replaces it all with a std::queue.

Also, de-duplicates the *Dequeue() functions by merging them into helper
class as a single nextRequest() getter method.

This has had some basic testing and seems to work so far. Though I have
added one TODO where I think we have some potential for a memory leak
and/or hung transactions if helpers are constantly dying but not also
killing Squid.

=== modified file 'src/'
--- src/	2016-01-01 00:12:18 +0000
+++ src/	2016-04-22 20:07:50 +0000
 <at>  <at>  -54,8 +54,6  <at>  <at> 
 static void helperServerFree(helper_server *srv);
 static void helperStatefulServerFree(helper_stateful_server *srv);
 static void Enqueue(helper * hlp, Helper::Request *);
-static Helper::Request *Dequeue(helper * hlp);
-static Helper::Request *StatefulDequeue(statefulhelper * hlp);
 static helper_server *GetFirstAvailable(helper * hlp);
 static helper_stateful_server *StatefulGetFirstAvailable(statefulhelper * hlp);
 static void helperDispatch(helper_server * srv, Helper::Request * r);
 <at>  <at>  -667,7 +665,8  <at>  <at> 
(Continue reading)

Amos Jeffries | 14 Apr 14:31 2016

[PATCH] Remove SquidList / link_list

This patch replaces the remaining use of Squid custom link_list type
with STL std::queue or std::list templates. Removing the now unneeded
custom type completely.

It builds on the previous libmem old_api cleanup patch and has yet to be
run tested, though the unit tests we have for the types all pass.

=== modified file 'src/'
--- src/	2016-03-18 09:38:10 +0000
+++ src/	2016-04-12 12:09:40 +0000
 <at>  <at>  -357,8 +357,6  <at>  <at> \
 	ipcache.h \
-	SquidList.h \
- \ \
 	LogTags.h \
 	lookup_t.h \
 <at>  <at>  -1058,8 +1056,6  <at>  <at> 
 	MasterXaction.h \ \
 	Notes.h \
-	SquidList.h \
- \ \ \
(Continue reading)

Amos Jeffries | 14 Apr 14:23 2016

[PATCH] PeerConnector shuffling to libsecurity

I have used the term Encryptor rather than Connector because these Job
classes require an pre-opened connection over some other transport and
just initiate encryption for it (be it raw TCP, PROXY, HTTP CONNECT or
other). Not starting from a closed connection.

This patch shuffles the Ssl::PeerConnector to Security::TlsPeerEncryptor
and Ssl::BlindPeerConnector to Security::BlindTlsPeerEncryptor.

As libsecurity API classes both are now always built. But in the absence
of OpenSSL they currently are expected to result in an error just as if
crypto had failed. At present the classes should still only be actually
used from within code wrapped in USE_OPENSSL. So that is not easily

To do this in a minimal way I had to also shuffle the BIO type
enumeration out to the namespace level. That seems not to have had any
significant effect.

This shuffling is a required step to simplify converting the basic TLS
I/O logic to libsecurity and for GnuTLS to actually begin adding useful
implementation bits.

=== modified file 'src/'
--- src/	2016-03-12 20:27:35 +0000
+++ src/	2016-04-05 09:05:34 +0000
 <at>  <at>  -45,9 +45,9  <at>  <at> 
 #include "pconn.h"
(Continue reading)

noc | 12 Apr 18:24 2016

Jenkins build is back to normal : trunk-matrix » gcc,d-ubuntu-vivid #614

See <,label=d-ubuntu-vivid/614/>

squid-dev mailing list
squid-dev <at>