Claudio Jeker wrote:
On Thu, Jun 23, 2005 at 02:29:11PM -0700, Q L.D. wrote:
Hello!
I'm just wondering, what exactly where the updates that went into
tcpserver patch (to allow SSL/TLS) in 20050405 version? I mean the
ucspi-tcp-ssl-20050405.patch.
I simply still have several systems running with
ucspi-tcp-ssl-20020705.patch and everything seems to be fine.
This newer patch is almost 6 times bigger than the older one, so I
wanted to see if it would make sense to install it on all machines or
some machines are better off with older patch. I did notice at least
these changes:
1. manpages - GREAT! No need to get this then
http://smarden.org/pape/djb/manpages/ucspi-tcp-0.88-man.tar.gz
It seems like Andre added those. Not a bad idea IMO.
Yes, I agree. It's a great idea. Very convenient.
2. interesting add-on - disabling Nagle algorithm (TCP_NODELAY)
on sockets.
I think this is a stock ucspi-tcp feature and the old patch supported the
same flags.
Oh, you're right. New patch simply added manpage, not the feature itself.
3. Seems like errno.patch has been incorporated into this patch.
Also makes me wonder what would be proper sequence as far as
applying patches goes - should I apply nobase.patch first, then
a_record.patch and then new ucspi-tcp-ssl patch?
Uhm, I don't know. What are the nobase.patch and a_record.patch?
These are RBL related patches from here -
http://www.qmail.org/moni.csi.hu/pub/glibc-2.3.1/
Technically I already figured out that they can be applied in the order
I mentioned - nobase.patch first followed by a_record.patch and then the
new ucspi-tcp-ssl patch.
Maybe these two patches (a_record and nobase) can be simply incorporated
into future version of ucspi-tcp-ssl?
4. Seems like it adds some of inetd services - e.g.
date, who, finger. Not sure why these were added.
Those are stock ucspi-tcp services.
I should get more sleep. I didn't notice that what the patch was
actually adding is manpages for all this stuff :)
6. Bug fixes in the ssl wrapper. It is possible to stall a connection
becasue not all SSL deciphered data is passed on. It looks like this bug
is hard to trigger.
I see. Probably it's really hard to trigger, because I have never
encountered it. But the good thing is that you guys fixed it anyway.
7. Introduce some per IP and per netblock connect limits.
Currently there are some bugs in that code that got fixed lately. A new
release should be available on the first July.
O, cool. That's a feature I can definitely use. I will wait for that new
release then.
Thanks a lot Claudio & Andre!
