+1,
I think the PureTLS support is not usefull anymore, but the proposed
API change looks well.
Peter
Am 30.01.2008 um 06:16 schrieb Bill Barker:
"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Bill Barker wrote:
"Mark Thomas" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
