Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 10594 invoked from network); 30 Jan 2008 05:16:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Jan 2008 05:16:47 -0000 Received: (qmail 129 invoked by uid 500); 30 Jan 2008 05:16:36 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 99980 invoked by uid 500); 30 Jan 2008 05:16:36 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 99969 invoked by uid 99); 30 Jan 2008 05:16:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2008 21:16:36 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jak-tomcat-dev@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Jan 2008 05:16:08 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JK5It-0003f0-VV for dev@tomcat.apache.org; Wed, 30 Jan 2008 05:16:07 +0000 Received: from pool-71-104-90-127.lsanca.dsl-w.verizon.net ([71.104.90.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 05:16:07 +0000 Received: from wbarker by pool-71-104-90-127.lsanca.dsl-w.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 05:16:07 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: dev@tomcat.apache.org From: "Bill Barker" Subject: Re: svn commit: r616522 - in /tomcat/trunk/java/org/apache/tomcat/util/net/puretls: PureTLSImplementation.java PureTLSSocket.java PureTLSSocketFactory.java PureTLSSupport.java Date: Tue, 29 Jan 2008 21:16:19 -0800 Lines: 95 Message-ID: References: <20080129211828.13A681A9832@eris.apache.org> <479FA18F.5080002@apache.org> <479FEA13.7070800@hanik.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pool-71-104-90-127.lsanca.dsl-w.verizon.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-RFC2646: Format=Flowed; Response Sender: news X-Virus-Checked: Checked by ClamAV on apache.org "Filip Hanik - Dev Lists" wrote in message news:479FEA13.7070800@hanik.com... > Bill Barker wrote: >> "Mark Thomas" wrote in message >> news:479FA18F.5080002@apache.org... >> >>> markt@apache.org wrote: >>> >>>> Author: markt >>>> Date: Tue Jan 29 13:18:25 2008 >>>> New Revision: 616522 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=616522&view=rev >>>> Log: >>>> Tab police. No function change >>>> >>>> Modified: >>>> >>>> tomcat/trunk/java/org/apache/tomcat/util/net/puretls/PureTLSImplementation.java >>>> >>>> tomcat/trunk/java/org/apache/tomcat/util/net/puretls/PureTLSSocket.java >>>> >>>> tomcat/trunk/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java >>>> >>>> tomcat/trunk/java/org/apache/tomcat/util/net/puretls/PureTLSSupport.java >>>> >>> Before I spend any more time looking at >>> http://issues.apache.org/bugzilla/show_bug.cgi?id=44318 am I correct in >>> thinking that PureTLS has never been part of of the TC6 build and that I >>> could just remove these four files instead? >>> >>> If we do want to keep PureTLS support the main problem appears to be >>> http://svn.apache.org/viewvc?view=rev&revision=428884 which added a JSSE >>> dependency into o.a.t.util.net.SSLImplementation >>> >>> As far as I can tell, PureTLS doesn't support nio anyway so... >>> >>> Thoughts? >>> >>> >> >> I remember that there was talk of removing PureTLS support. The PureTLS >> library isn't actively developed anymore (some security fixes, but not >> much else), and it still depends on a hacked version of Cryptix. But >> nobody has stepped up to actually remove it. >> >> That having been said, I'd prefer to remove the JSSE dependancy from >> SSLImplementation, since it makes it nearly impossible to develop a >> non-JSSE SSLImplementation (e.g. I there was talk of developing one for >> Mozilla's SSL stack, but nothing ever happened). Without having thought >> it out much, something like changing >> abstract public SSLSupport getSSLSupport(SSLSession session); >> to >> abstract public SSLSupport getNioSSLSupport(Socket sock); >> > if we are gonna remove it, why remove it only for one connector. The code > used is the same by both the BIO and the NIO connector > not sure we need the abstraction at all > I'm for removing support for PureTLS, since it is largely unmaintained at the moment. But the abstraction is usefull to be able to support SSL providers (e.g. Mozilla meantioned above) that don't implement JSSE. It wasn't about getting removing it from the NIO Connecter, just making the signature not depend on JSSE. So for JSSE, something like: public SSLSupport getNioSSLSupport(Socket sock) { return factory.getSSLSupport(((SSLSocket)sock).getSession()); } I just prefer to keep where we have plug-in structure such as here, that we don't just throw it away in favor of only supporting Sun's solution. > >> In the JSSE case, you can get the SSLSession from the Socket, so it would >> be a small change to the existing code. >> > same code can be reused for both connectors. > > Filip >> >>> Mark >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org >> For additional commands, e-mail: dev-help@tomcat.apache.org >> >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org