[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Strange TLS behaviour with slapd 2.3.30 on Debian Etch

Howard Chu <hyc@symas.com> writes:

> Yes, callgrind is pretty cool, much more useful than old gprof-style
> profilers. Though as you note, the runtimes of any valgrind tool can
> be pretty extreme. My tweaked version of FunctionCheck is also useful
> when you can afford to compile an instrumented version of your
> code. Faster runtimes in exchange for extra compile time - frequently
> it's a worthwhile tradeoff.
> http://highlandsun.com/hyc/#fncchk

Interesting, does the code still run and is useful?  The latest comment
about it was from 2005.  To be able to use it, I need to set up a useful
benchmark environment first though.

>>> Not being an TLS/SSL expert, I'm wondering why you need to add all
>>> those certificates in the first place. I thought the whole point of
>>> all those<subject hash>.<serial>  links in /etc/openssl/certs (or
>>> whatever) was that a client could find a CA certificate simply by
>>> hashing the subject.
>> GnuTLS doesn't support hashed certificate directories.  Further, TLS
>> servers need to send a list of names of trusted certificates to clients,
>> so the server has to open and parse all local trust roots anyway.  Right
>> now, this is done for clients too, since the relevant code in GnuTLS
>> doesn't know whether it will be used as a client or server.  I hope the
>> new code will be fast enough so that it isn't a bottle-neck.  I suppose
>> that it could be optimized further, so that it isn't done for clients at
>> all, but let's not optimize prematurely.
> You're already approaching GnuTLS version 2.4. If optimizing now is
> premature, when will it actually be time to optimize?

If anyone wants to contribute by profiling/optimizing something in
GnuTLS, doing it now is fine with me.