Re: [PATCH] certificate_db/ssl_crtd fixes

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 13 Nov 2012 20:48:56 +1300

On 11/11/2012 10:41 p.m., Tsantilas Christos wrote:
> On 11/10/2012 06:25 AM, Amos Jeffries wrote:
>> Christos,
>> which of these bugs (if either) are closed by this patch?
>> http://bugs.squid-cache.org/show_bug.cgi?id=3405
>> http://bugs.squid-cache.org/show_bug.cgi?id=3436
> Looks that it fixes the 3405 bug. But maybe we still need to make some
> improvements.

Great. Ported back to 3.3 citing bug 3405.

There is at least one clear conflict which makes a semantic change I'm
not confident enough about to resolve properly for the port back to 3.2:
Ssl::CertificateDb::addCertAndPrivateKey() condition "if (rrow != NULL)"
return result changed from false in 3.2 to true in 3.3 as a result of
the stable cert feature update. I am quite uncomfortable just back
porting this false->true change and not sure that the false is correct
for this patch either. If you wish to supply a patch against 3.2 I
would be happy to have it applied but IMO it is not urgent.

>
> We need to make more work to fix the 3436 bug. Currently the ssl_crtd
> helper will crash for every simple failure. For example if it fails to
> add to certificate db a certificate, because the TXT_DB_insert openSSL
> function fails.
> We should not let ssl_crtd daemon crash on every single error, but just
> trying to not leave garbage on DB on failures.
> This patch make a step, because try to clean up the database after
> failures. But the ssl_crtd still crashes on failures....
>

BTW, I am starting out on adding GnuTLS and other SSL library support by
Squid.
That db_TXT_DB_insert function was a good step. If there are any other
pieces of SSL code you find which can be shuffled into operational-step
pieces like that it would be a great help if it were done. I am having
to identify what the core operation for each SSL call and usage is about
and find the matching feature usage in each library. The more modular we
can make Squid code usages the better.

Amos
Received on Tue Nov 13 2012 - 07:49:07 MST

This archive was generated by hypermail 2.2.0 : Tue Nov 13 2012 - 12:00:06 MST