You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Kartheek Hirode <ka...@centegy.com> on 2000/10/03 19:38:58 UTC
RE: SSLSoap Release Candidate.
Hello George,
Your work is very, very appreciated. We had managed to 'write up' code for
SOAP over SSL (it works:) but taking it to Apache needs a whole magnum
effort.
Thanks bunch for taking this up.
Btw, is Sun's JSSE controlled by licensing issues? That was one of our
stumbling
blocks in commercializing our system.
Thanks again, good day,
--Kartheek
-----Original Message-----
From: Nathan Wray [mailto:nwray@mich.com]
Sent: Wednesday, September 27, 2000 3:05 AM
To: soap-dev@xml.apache.org
Subject: Re: SSLSoap Release Candidate.
George, will your changes become part of Apache SOAP or a parallel effort
SecureSoap? The concern I expressed was based on requiring JSSE for all
SOAP users, but if this is a security-specific distribution my comments are
less relevant.
George I Matkovits wrote:
> I did some thinking after reading your comments. They reflect very well on
my biases, even the possible null pointer exception, which was intentional.
> I got into Soap Security (SSL is just the start) to counter the advantages
of the MS Soap Implementation vis-a-vis Java Soap. IMHO MS defined the V1.0
standard to stack the decks against any and all Soap or Web Services (aka
Win.Net) implementations outside the Windows COM framework. (V1.1 is a bit
better but not much!) I understand why they are doing this (I had some long
discussions with very competent MS 'Technical Evangelists') and the only
REAL answer is to have a competitive Java Solution. I
> have been working towards this ASAP. What I forgotten to consider is that
many, many Java programmers come from VB kind of backgrounds. I see this on
several of the other Java Forums. Many of the apache-user forum members find
it even difficult to create a simple classpath for Apache Soap or write
almost anything more complex then a 'Hello World' program without outside
tutoring (they will improve eventually, Java will help with product
maturity). The current SSL Implementation would really require
> SSL jars to be present, IMHO 80% of the soap-user community does not quite
know how to place the current (2) jars on the classpath or install a simple
Web-Server like Tomcat. I HAVE to reorganize the code to allow INCREMENTAL
upgrade to the secure version without requiring that it be used by ALL . Now
that we will have a properties file this should be doable on the fly.
> The REAL problem is how to keep an 'UNSECURE' version off the Internet?
> Code partitioning and subclassing is just work BUT I do not have an answer
on 'how to stop an unsecure version from ESCAPING (-: e.g. its LAN
prison')!!! Any ideas, please?
> Regards - George
>
> Nathan Wray wrote:
>
> > Thank you for undertaking this George and for being so open to
suggestion, it is a pleasure to work with you.
> >
> > George I Matkovits wrote:
> >
> > > I rethink and rework the code . I will send you the source again ASAP
after
> > > working through your comments. Open source development is nice. Review
by informed people really improves quality. :-)
> > > Thank you for the comments and criticisms. - George
> > >
> > > Nathan Wray wrote:
> > >
> > > >
> > > > Thanks George, I'm on London time so I didn't get this until today.
I'm most concerned that the SOAP library won't work without SSL once these
changes are committed which I've addressed below, please review and let me
know what you think.
> > > >
> > > >
> > > >
> > > >
> > > > line 109 in SecurityUtils will throw a null pointer exception if the
"org.apache.soap.http.LogPropCreation"
> > > > is not defined, I suggest changing it to
> > > >
("true".equals(SystemProperties.get("org.apache.soap.http.LogPropCreation"))
)
> > > > which is equavalant but safer.
> > > >
> > > > similar in HTTPutils.java lines 184-215
> > > >
> > > >
> > > > Rather than searching an arbitrary number of fixed locations for the
property file, you could put it in the classpath and look in each folder of
the classpath, like
> > > >
> > > > tokenizer = new StringTokenizer(classPath, pathSeparator,
false);
> > > > foundFile = false;
> > > > while (!foundFile && (tokenizer.hasMoreTokens()))
> > > > {
> > > > path = tokenizer.nextToken() + fileSeparator +
classPathSuffix + propertyFileName;
> > > > file = new File(path);
> > > >
> > > > if (file.exists())
> > > > {
> > > > //yahoo
> > > > }
> > > > }
> > > >
> > > >
> > > > HTTPUtils.java line 237 is redundant
> > > >
> > > > Should the code rebuild the URL object? The user should correctly
build the URL object and the library should use it as is, I disagee with
re-creating it. If the user wants "http://utl HTTP/1.1" then we should rely
on them buyilding it that way. By re-building it we risk missing something,
especially if URL is eventually subclassed.
> > > >
> > > > I also disagree with the SSL system property code and provider
addition being in the SecurityUtils code. These are user issues that are
part of SSL/HTTPS and aren't strictly part of SOAP, the user code should do
these set-up calls. By adding them, SOAP can't be used without JSSE or
similar which is unnecessary and I'm sure they add overhead if someone isn't
using SSL. If we leave them as a user environment issue we can take out all
of the SSL import statements as I have done in my version.
> > > >
> > > > I like the idea of an optional SOAP logging class, but I see no
reason why the call to SecureUtils should be manditory, and the class seems
to be misnamed if it's just loading system properties.
> > > >
> > > >
> > > >
> > > >
> > > > George I Matkovits wrote:
> > > >
> > > > > Please find enclosed full source for the 'candidate'
> > > > > SSLSoap. It will work from its internal defaults even
> > > > > without the Soap.properties file! The Soap.properties file
> > > > > is in the SRC utilities directory and it should be placed
> > > > > into the CWD (beside many other places which I will document
> > > > > in an Installation Note). The code was simplified as per
> > > > > your comment but unfortunately it still needs 1 line of
> > > > > change in all the Samples code. These are also in the
> > > > > attached zip file. I build with Ant and my build (+test)
> > > > > scripts are also included. The code should be also fully
> > > > > thread safe but testing with your 1000 thread load would be
> > > > > greatly appreciated. :-) I will wait for your test results
> > > > > before commit. One of the new Classes is a Singleton with
> > > > > its normal sync and protection structures.
> > > > > The attachment was generated with jar and renamed to zip to
> > > > > fool my mail utility. The code is based on xml-CVS09182000.
> > > > > It has an early version of Sanjiva's messaging. It was
> > > > > tested with Apache-SSL and Tomcat (on both Windows2000 and
> > > > > Linux). Testing with any other Web combinations would be
> > > > > wonderful. Two of the original code modules were changed and
> > > > > three new ones have been added. I will be making more
> > > > > changes to the Properties file architecture in the upcoming
> > > > > SecureSoap Version. I will start checking this into CVS on
> > > > > Monday. Notes in the INFO directory are also out off date
> > > > > and will be updated on Monday.
> > > > > Regards and many thanks for the help - George
> > > > >
> > > > > ----------------------------------------
> > > > >
Name: Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> > > > >
Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
Type: Zip Compressed Data (application/x-zip-compressed)
> > > > >
Encoding: base64
> > > >
> > > > --
> > > > Nathan Wray
> > > > nwray@mich.com
> > > > --
> > > > "I see in the near future a crisis approaching that
> > > > unnerves me and causes me to tremble for the safety
> > > > of my country
corporations have been enthroned and
> > > > an era of corruption in high places will follow, and the
> > > > money of the country will endeavor to prolong its reign
> > > > by working upon the prejudices of the people until all
> > > > wealth is aggregated in a few hands and the republic is
> > > > destroyed. I feel at this moment more anxiety for the
> > > > safety of my country than ever before, even in the
> > > > midst of war."
> > > > --Abraham Lincoln, 1865
> > > >
> >
> > --
> > Nathan Wray
> > nwray@mich.com
> > --
> > "I see in the near future a crisis approaching that
> > unnerves me and causes me to tremble for the safety
> > of my country
corporations have been enthroned and
> > an era of corruption in high places will follow, and the
> > money of the country will endeavor to prolong its reign
> > by working upon the prejudices of the people until all
> > wealth is aggregated in a few hands and the republic is
> > destroyed. I feel at this moment more anxiety for the
> > safety of my country than ever before, even in the
> > midst of war."
> > --Abraham Lincoln, 1865
--
Nathan Wray
nwray@mich.com
--
"Can anybody cite a single interesting or
important idea or argument that's emerged
from the months of campaigning in the
current U.S. presidential race?"
Jon Katz, slashdot.org
http://slashdot.org/article.pl?sid=00/09/19/035231&mode=nested
Re: JSSE and commercial use (was Re:SSLSoap Release Candidate.)
Posted by George I Matkovits <ma...@uswest.net>.
Great. IMHO it used to be for 1.0.1 but it does not seem to be now for 1.0.2. Good news. :-)
Regards - George
Nathan Wray wrote:
>
> I don't think there are any licensing issues with using jsse commercially.
> From the Sun page at http://java.sun.com/products/jsse/ (free login required)
>
> Business Considerations
>
> Sun's release of JSSE 1.0.2 is a non-commercial reference implementation. The binary implementation may be used royalty-free as part of commercial applications. See the software license for more information.
>
> I wouldn't consider that to be a restrictive license, am I misreading it?
>
>
>
> George I Matkovits wrote:
>
> > Yes (not for commercial use) but IMHO there are compatible commercial versions
> > now! My company will also need one and I will be researching this issue ASAP.
> > 1st I have to complete and TEST... the promised Soap Server Access Control
> > code. (That is: SecureSoap).
> > Regards - George
> >
> > Kartheek Hirode wrote:
> >
> > > Hello George,
> > > Your work is very, very appreciated. We had managed to 'write up' code for
> > > SOAP over SSL (it works:) but taking it to Apache needs a whole magnum
> > > effort.
> > > Thanks bunch for taking this up.
> > >
> > > Btw, is Sun's JSSE controlled by licensing issues? That was one of our
> > > stumbling
> > > blocks in commercializing our system.
> > >
> > > Thanks again, good day,
> > > --Kartheek
> > >
> > > -----Original Message-----
> > > From: Nathan Wray [mailto:nwray@mich.com]
> > > Sent: Wednesday, September 27, 2000 3:05 AM
> > > To: soap-dev@xml.apache.org
> > > Subject: Re: SSLSoap Release Candidate.
> > >
> > > George, will your changes become part of Apache SOAP or a parallel effort
> > > SecureSoap? The concern I expressed was based on requiring JSSE for all
> > > SOAP users, but if this is a security-specific distribution my comments are
> > > less relevant.
> > >
> > > George I Matkovits wrote:
> > >
> > > > I did some thinking after reading your comments. They reflect very well on
> > > my biases, even the possible null pointer exception, which was intentional.
> > > > I got into Soap Security (SSL is just the start) to counter the advantages
> > > of the MS Soap Implementation vis-a-vis Java Soap. IMHO MS defined the V1.0
> > > standard to stack the decks against any and all Soap or Web Services (aka
> > > Win.Net) implementations outside the Windows COM framework. (V1.1 is a bit
> > > better but not much!) I understand why they are doing this (I had some long
> > > discussions with very competent MS 'Technical Evangelists') and the only
> > > REAL answer is to have a competitive Java Solution. I
> > > > have been working towards this ASAP. What I forgotten to consider is that
> > > many, many Java programmers come from VB kind of backgrounds. I see this on
> > > several of the other Java Forums. Many of the apache-user forum members find
> > > it even difficult to create a simple classpath for Apache Soap or write
> > > almost anything more complex then a 'Hello World' program without outside
> > > tutoring (they will improve eventually, Java will help with product
> > > maturity). The current SSL Implementation would really require
> > > > SSL jars to be present, IMHO 80% of the soap-user community does not quite
> > > know how to place the current (2) jars on the classpath or install a simple
> > > Web-Server like Tomcat. I HAVE to reorganize the code to allow INCREMENTAL
> > > upgrade to the secure version without requiring that it be used by ALL . Now
> > > that we will have a properties file this should be doable on the fly.
> > > > The REAL problem is how to keep an 'UNSECURE' version off the Internet?
> > > > Code partitioning and subclassing is just work BUT I do not have an answer
> > > on 'how to stop an unsecure version from ESCAPING (-: e.g. its LAN
> > > prison')!!! Any ideas, please?
> > > > Regards - George
> > > >
> > > > Nathan Wray wrote:
> > > >
> > > > > Thank you for undertaking this George and for being so open to
> > > suggestion, it is a pleasure to work with you.
> > > > >
> > > > > George I Matkovits wrote:
> > > > >
> > > > > > I rethink and rework the code . I will send you the source again ASAP
> > > after
> > > > > > working through your comments. Open source development is nice. Review
> > > by informed people really improves quality. :-)
> > > > > > Thank you for the comments and criticisms. - George
> > > > > >
> > > > > > Nathan Wray wrote:
> > > > > >
> > > > > > >
> > > > > > > Thanks George, I'm on London time so I didn't get this until today.
> > > I'm most concerned that the SOAP library won't work without SSL once these
> > > changes are committed which I've addressed below, please review and let me
> > > know what you think.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > line 109 in SecurityUtils will throw a null pointer exception if the
> > > "org.apache.soap.http.LogPropCreation"
> > > > > > > is not defined, I suggest changing it to
> > > > > > >
> > > ("true".equals(SystemProperties.get("org.apache.soap.http.LogPropCreation"))
> > > )
> > > > > > > which is equavalant but safer.
> > > > > > >
> > > > > > > similar in HTTPutils.java lines 184-215
> > > > > > >
> > > > > > >
> > > > > > > Rather than searching an arbitrary number of fixed locations for the
> > > property file, you could put it in the classpath and look in each folder of
> > > the classpath, like
> > > > > > >
> > > > > > > tokenizer = new StringTokenizer(classPath, pathSeparator,
> > > false);
> > > > > > > foundFile = false;
> > > > > > > while (!foundFile && (tokenizer.hasMoreTokens()))
> > > > > > > {
> > > > > > > path = tokenizer.nextToken() + fileSeparator +
> > > classPathSuffix + propertyFileName;
> > > > > > > file = new File(path);
> > > > > > >
> > > > > > > if (file.exists())
> > > > > > > {
> > > > > > > //yahoo
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > HTTPUtils.java line 237 is redundant
> > > > > > >
> > > > > > > Should the code rebuild the URL object? The user should correctly
> > > build the URL object and the library should use it as is, I disagee with
> > > re-creating it. If the user wants "http://utl HTTP/1.1" then we should rely
> > > on them buyilding it that way. By re-building it we risk missing something,
> > > especially if URL is eventually subclassed.
> > > > > > >
> > > > > > > I also disagree with the SSL system property code and provider
> > > addition being in the SecurityUtils code. These are user issues that are
> > > part of SSL/HTTPS and aren't strictly part of SOAP, the user code should do
> > > these set-up calls. By adding them, SOAP can't be used without JSSE or
> > > similar which is unnecessary and I'm sure they add overhead if someone isn't
> > > using SSL. If we leave them as a user environment issue we can take out all
> > > of the SSL import statements as I have done in my version.
> > > > > > >
> > > > > > > I like the idea of an optional SOAP logging class, but I see no
> > > reason why the call to SecureUtils should be manditory, and the class seems
> > > to be misnamed if it's just loading system properties.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > George I Matkovits wrote:
> > > > > > >
> > > > > > > > Please find enclosed full source for the 'candidate'
> > > > > > > > SSLSoap. It will work from its internal defaults even
> > > > > > > > without the Soap.properties file! The Soap.properties file
> > > > > > > > is in the SRC utilities directory and it should be placed
> > > > > > > > into the CWD (beside many other places which I will document
> > > > > > > > in an Installation Note). The code was simplified as per
> > > > > > > > your comment but unfortunately it still needs 1 line of
> > > > > > > > change in all the Samples code. These are also in the
> > > > > > > > attached zip file. I build with Ant and my build (+test)
> > > > > > > > scripts are also included. The code should be also fully
> > > > > > > > thread safe but testing with your 1000 thread load would be
> > > > > > > > greatly appreciated. :-) I will wait for your test results
> > > > > > > > before commit. One of the new Classes is a Singleton with
> > > > > > > > its normal sync and protection structures.
> > > > > > > > The attachment was generated with jar and renamed to zip to
> > > > > > > > fool my mail utility. The code is based on xml-CVS09182000.
> > > > > > > > It has an early version of Sanjiva's messaging. It was
> > > > > > > > tested with Apache-SSL and Tomcat (on both Windows2000 and
> > > > > > > > Linux). Testing with any other Web combinations would be
> > > > > > > > wonderful. Two of the original code modules were changed and
> > > > > > > > three new ones have been added. I will be making more
> > > > > > > > changes to the Properties file architecture in the upcoming
> > > > > > > > SecureSoap Version. I will start checking this into CVS on
> > > > > > > > Monday. Notes in the INFO directory are also out off date
> > > > > > > > and will be updated on Monday.
> > > > > > > > Regards and many thanks for the help - George
> > > > > > > >
> > > > > > > > ----------------------------------------
> > > > > > > >
> > > Name: Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> > > > > > > >
> > > Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> > > Type: Zip Compressed Data (application/x-zip-compressed)
> > > > > > > >
> > > Encoding: base64
> > > > > > >
> > > > > > > --
> > > > > > > Nathan Wray
> > > > > > > nwray@mich.com
> > > > > > > --
> > > > > > > "I see in the near future a crisis approaching that
> > > > > > > unnerves me and causes me to tremble for the safety
> > > > > > > of my country
corporations have been enthroned and
> > > > > > > an era of corruption in high places will follow, and the
> > > > > > > money of the country will endeavor to prolong its reign
> > > > > > > by working upon the prejudices of the people until all
> > > > > > > wealth is aggregated in a few hands and the republic is
> > > > > > > destroyed. I feel at this moment more anxiety for the
> > > > > > > safety of my country than ever before, even in the
> > > > > > > midst of war."
> > > > > > > --Abraham Lincoln, 1865
> > > > > > >
> > > > >
> > > > > --
> > > > > Nathan Wray
> > > > > nwray@mich.com
> > > > > --
> > > > > "I see in the near future a crisis approaching that
> > > > > unnerves me and causes me to tremble for the safety
> > > > > of my country
corporations have been enthroned and
> > > > > an era of corruption in high places will follow, and the
> > > > > money of the country will endeavor to prolong its reign
> > > > > by working upon the prejudices of the people until all
> > > > > wealth is aggregated in a few hands and the republic is
> > > > > destroyed. I feel at this moment more anxiety for the
> > > > > safety of my country than ever before, even in the
> > > > > midst of war."
> > > > > --Abraham Lincoln, 1865
> > >
> > > --
> > > Nathan Wray
> > > nwray@mich.com
> > > --
> > > "Can anybody cite a single interesting or
> > > important idea or argument that's emerged
> > > from the months of campaigning in the
> > > current U.S. presidential race?"
> > > Jon Katz, slashdot.org
> > > http://slashdot.org/article.pl?sid=00/09/19/035231&mode=nested
>
> --
> Nathan Wray
> nwray@mich.com
> --
> "I'll keep it short and sweet.
> Family. Religion. Friendship.
> These are the three demons you must slay if
> you wish to succeed in business."
>
> - Charles Montgomery Burns
> (from The Simpsons)
>
Re: JSSE and commercial use (was Re:SSLSoap Release Candidate.)
Posted by George I Matkovits <ma...@uswest.net>.
Great. IMHO it used to be for 1.0.1 but it does not seem to be now for 1.0.2. Good news. :-)
Regards - George
Nathan Wray wrote:
>
> I don't think there are any licensing issues with using jsse commercially.
> From the Sun page at http://java.sun.com/products/jsse/ (free login required)
>
> Business Considerations
>
> Sun's release of JSSE 1.0.2 is a non-commercial reference implementation. The binary implementation may be used royalty-free as part of commercial applications. See the software license for more information.
>
> I wouldn't consider that to be a restrictive license, am I misreading it?
>
>
>
> George I Matkovits wrote:
>
> > Yes (not for commercial use) but IMHO there are compatible commercial versions
> > now! My company will also need one and I will be researching this issue ASAP.
> > 1st I have to complete and TEST... the promised Soap Server Access Control
> > code. (That is: SecureSoap).
> > Regards - George
> >
> > Kartheek Hirode wrote:
> >
> > > Hello George,
> > > Your work is very, very appreciated. We had managed to 'write up' code for
> > > SOAP over SSL (it works:) but taking it to Apache needs a whole magnum
> > > effort.
> > > Thanks bunch for taking this up.
> > >
> > > Btw, is Sun's JSSE controlled by licensing issues? That was one of our
> > > stumbling
> > > blocks in commercializing our system.
> > >
> > > Thanks again, good day,
> > > --Kartheek
> > >
> > > -----Original Message-----
> > > From: Nathan Wray [mailto:nwray@mich.com]
> > > Sent: Wednesday, September 27, 2000 3:05 AM
> > > To: soap-dev@xml.apache.org
> > > Subject: Re: SSLSoap Release Candidate.
> > >
> > > George, will your changes become part of Apache SOAP or a parallel effort
> > > SecureSoap? The concern I expressed was based on requiring JSSE for all
> > > SOAP users, but if this is a security-specific distribution my comments are
> > > less relevant.
> > >
> > > George I Matkovits wrote:
> > >
> > > > I did some thinking after reading your comments. They reflect very well on
> > > my biases, even the possible null pointer exception, which was intentional.
> > > > I got into Soap Security (SSL is just the start) to counter the advantages
> > > of the MS Soap Implementation vis-a-vis Java Soap. IMHO MS defined the V1.0
> > > standard to stack the decks against any and all Soap or Web Services (aka
> > > Win.Net) implementations outside the Windows COM framework. (V1.1 is a bit
> > > better but not much!) I understand why they are doing this (I had some long
> > > discussions with very competent MS 'Technical Evangelists') and the only
> > > REAL answer is to have a competitive Java Solution. I
> > > > have been working towards this ASAP. What I forgotten to consider is that
> > > many, many Java programmers come from VB kind of backgrounds. I see this on
> > > several of the other Java Forums. Many of the apache-user forum members find
> > > it even difficult to create a simple classpath for Apache Soap or write
> > > almost anything more complex then a 'Hello World' program without outside
> > > tutoring (they will improve eventually, Java will help with product
> > > maturity). The current SSL Implementation would really require
> > > > SSL jars to be present, IMHO 80% of the soap-user community does not quite
> > > know how to place the current (2) jars on the classpath or install a simple
> > > Web-Server like Tomcat. I HAVE to reorganize the code to allow INCREMENTAL
> > > upgrade to the secure version without requiring that it be used by ALL . Now
> > > that we will have a properties file this should be doable on the fly.
> > > > The REAL problem is how to keep an 'UNSECURE' version off the Internet?
> > > > Code partitioning and subclassing is just work BUT I do not have an answer
> > > on 'how to stop an unsecure version from ESCAPING (-: e.g. its LAN
> > > prison')!!! Any ideas, please?
> > > > Regards - George
> > > >
> > > > Nathan Wray wrote:
> > > >
> > > > > Thank you for undertaking this George and for being so open to
> > > suggestion, it is a pleasure to work with you.
> > > > >
> > > > > George I Matkovits wrote:
> > > > >
> > > > > > I rethink and rework the code . I will send you the source again ASAP
> > > after
> > > > > > working through your comments. Open source development is nice. Review
> > > by informed people really improves quality. :-)
> > > > > > Thank you for the comments and criticisms. - George
> > > > > >
> > > > > > Nathan Wray wrote:
> > > > > >
> > > > > > >
> > > > > > > Thanks George, I'm on London time so I didn't get this until today.
> > > I'm most concerned that the SOAP library won't work without SSL once these
> > > changes are committed which I've addressed below, please review and let me
> > > know what you think.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > line 109 in SecurityUtils will throw a null pointer exception if the
> > > "org.apache.soap.http.LogPropCreation"
> > > > > > > is not defined, I suggest changing it to
> > > > > > >
> > > ("true".equals(SystemProperties.get("org.apache.soap.http.LogPropCreation"))
> > > )
> > > > > > > which is equavalant but safer.
> > > > > > >
> > > > > > > similar in HTTPutils.java lines 184-215
> > > > > > >
> > > > > > >
> > > > > > > Rather than searching an arbitrary number of fixed locations for the
> > > property file, you could put it in the classpath and look in each folder of
> > > the classpath, like
> > > > > > >
> > > > > > > tokenizer = new StringTokenizer(classPath, pathSeparator,
> > > false);
> > > > > > > foundFile = false;
> > > > > > > while (!foundFile && (tokenizer.hasMoreTokens()))
> > > > > > > {
> > > > > > > path = tokenizer.nextToken() + fileSeparator +
> > > classPathSuffix + propertyFileName;
> > > > > > > file = new File(path);
> > > > > > >
> > > > > > > if (file.exists())
> > > > > > > {
> > > > > > > //yahoo
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > HTTPUtils.java line 237 is redundant
> > > > > > >
> > > > > > > Should the code rebuild the URL object? The user should correctly
> > > build the URL object and the library should use it as is, I disagee with
> > > re-creating it. If the user wants "http://utl HTTP/1.1" then we should rely
> > > on them buyilding it that way. By re-building it we risk missing something,
> > > especially if URL is eventually subclassed.
> > > > > > >
> > > > > > > I also disagree with the SSL system property code and provider
> > > addition being in the SecurityUtils code. These are user issues that are
> > > part of SSL/HTTPS and aren't strictly part of SOAP, the user code should do
> > > these set-up calls. By adding them, SOAP can't be used without JSSE or
> > > similar which is unnecessary and I'm sure they add overhead if someone isn't
> > > using SSL. If we leave them as a user environment issue we can take out all
> > > of the SSL import statements as I have done in my version.
> > > > > > >
> > > > > > > I like the idea of an optional SOAP logging class, but I see no
> > > reason why the call to SecureUtils should be manditory, and the class seems
> > > to be misnamed if it's just loading system properties.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > George I Matkovits wrote:
> > > > > > >
> > > > > > > > Please find enclosed full source for the 'candidate'
> > > > > > > > SSLSoap. It will work from its internal defaults even
> > > > > > > > without the Soap.properties file! The Soap.properties file
> > > > > > > > is in the SRC utilities directory and it should be placed
> > > > > > > > into the CWD (beside many other places which I will document
> > > > > > > > in an Installation Note). The code was simplified as per
> > > > > > > > your comment but unfortunately it still needs 1 line of
> > > > > > > > change in all the Samples code. These are also in the
> > > > > > > > attached zip file. I build with Ant and my build (+test)
> > > > > > > > scripts are also included. The code should be also fully
> > > > > > > > thread safe but testing with your 1000 thread load would be
> > > > > > > > greatly appreciated. :-) I will wait for your test results
> > > > > > > > before commit. One of the new Classes is a Singleton with
> > > > > > > > its normal sync and protection structures.
> > > > > > > > The attachment was generated with jar and renamed to zip to
> > > > > > > > fool my mail utility. The code is based on xml-CVS09182000.
> > > > > > > > It has an early version of Sanjiva's messaging. It was
> > > > > > > > tested with Apache-SSL and Tomcat (on both Windows2000 and
> > > > > > > > Linux). Testing with any other Web combinations would be
> > > > > > > > wonderful. Two of the original code modules were changed and
> > > > > > > > three new ones have been added. I will be making more
> > > > > > > > changes to the Properties file architecture in the upcoming
> > > > > > > > SecureSoap Version. I will start checking this into CVS on
> > > > > > > > Monday. Notes in the INFO directory are also out off date
> > > > > > > > and will be updated on Monday.
> > > > > > > > Regards and many thanks for the help - George
> > > > > > > >
> > > > > > > > ----------------------------------------
> > > > > > > >
> > > Name: Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> > > > > > > >
> > > Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> > > Type: Zip Compressed Data (application/x-zip-compressed)
> > > > > > > >
> > > Encoding: base64
> > > > > > >
> > > > > > > --
> > > > > > > Nathan Wray
> > > > > > > nwray@mich.com
> > > > > > > --
> > > > > > > "I see in the near future a crisis approaching that
> > > > > > > unnerves me and causes me to tremble for the safety
> > > > > > > of my country
corporations have been enthroned and
> > > > > > > an era of corruption in high places will follow, and the
> > > > > > > money of the country will endeavor to prolong its reign
> > > > > > > by working upon the prejudices of the people until all
> > > > > > > wealth is aggregated in a few hands and the republic is
> > > > > > > destroyed. I feel at this moment more anxiety for the
> > > > > > > safety of my country than ever before, even in the
> > > > > > > midst of war."
> > > > > > > --Abraham Lincoln, 1865
> > > > > > >
> > > > >
> > > > > --
> > > > > Nathan Wray
> > > > > nwray@mich.com
> > > > > --
> > > > > "I see in the near future a crisis approaching that
> > > > > unnerves me and causes me to tremble for the safety
> > > > > of my country
corporations have been enthroned and
> > > > > an era of corruption in high places will follow, and the
> > > > > money of the country will endeavor to prolong its reign
> > > > > by working upon the prejudices of the people until all
> > > > > wealth is aggregated in a few hands and the republic is
> > > > > destroyed. I feel at this moment more anxiety for the
> > > > > safety of my country than ever before, even in the
> > > > > midst of war."
> > > > > --Abraham Lincoln, 1865
> > >
> > > --
> > > Nathan Wray
> > > nwray@mich.com
> > > --
> > > "Can anybody cite a single interesting or
> > > important idea or argument that's emerged
> > > from the months of campaigning in the
> > > current U.S. presidential race?"
> > > Jon Katz, slashdot.org
> > > http://slashdot.org/article.pl?sid=00/09/19/035231&mode=nested
>
> --
> Nathan Wray
> nwray@mich.com
> --
> "I'll keep it short and sweet.
> Family. Religion. Friendship.
> These are the three demons you must slay if
> you wish to succeed in business."
>
> - Charles Montgomery Burns
> (from The Simpsons)
>
JSSE and commercial use (was Re:SSLSoap Release Candidate.)
Posted by Nathan Wray <nw...@mich.com>.
I don't think there are any licensing issues with using jsse commercially.
JSSE and commercial use (was Re:SSLSoap Release Candidate.)
Posted by Nathan Wray <nw...@mich.com>.
I don't think there are any licensing issues with using jsse commercially.
Re: SSLSoap Release Candidate.
Posted by George I Matkovits <ma...@uswest.net>.
Yes (not for commercial use) but IMHO there are compatible commercial versions
now! My company will also need one and I will be researching this issue ASAP.
1st I have to complete and TEST... the promised Soap Server Access Control
code. (That is: SecureSoap).
Regards - George
Kartheek Hirode wrote:
> Hello George,
> Your work is very, very appreciated. We had managed to 'write up' code for
> SOAP over SSL (it works:) but taking it to Apache needs a whole magnum
> effort.
> Thanks bunch for taking this up.
>
> Btw, is Sun's JSSE controlled by licensing issues? That was one of our
> stumbling
> blocks in commercializing our system.
>
> Thanks again, good day,
> --Kartheek
>
> -----Original Message-----
> From: Nathan Wray [mailto:nwray@mich.com]
> Sent: Wednesday, September 27, 2000 3:05 AM
> To: soap-dev@xml.apache.org
> Subject: Re: SSLSoap Release Candidate.
>
> George, will your changes become part of Apache SOAP or a parallel effort
> SecureSoap? The concern I expressed was based on requiring JSSE for all
> SOAP users, but if this is a security-specific distribution my comments are
> less relevant.
>
> George I Matkovits wrote:
>
> > I did some thinking after reading your comments. They reflect very well on
> my biases, even the possible null pointer exception, which was intentional.
> > I got into Soap Security (SSL is just the start) to counter the advantages
> of the MS Soap Implementation vis-a-vis Java Soap. IMHO MS defined the V1.0
> standard to stack the decks against any and all Soap or Web Services (aka
> Win.Net) implementations outside the Windows COM framework. (V1.1 is a bit
> better but not much!) I understand why they are doing this (I had some long
> discussions with very competent MS 'Technical Evangelists') and the only
> REAL answer is to have a competitive Java Solution. I
> > have been working towards this ASAP. What I forgotten to consider is that
> many, many Java programmers come from VB kind of backgrounds. I see this on
> several of the other Java Forums. Many of the apache-user forum members find
> it even difficult to create a simple classpath for Apache Soap or write
> almost anything more complex then a 'Hello World' program without outside
> tutoring (they will improve eventually, Java will help with product
> maturity). The current SSL Implementation would really require
> > SSL jars to be present, IMHO 80% of the soap-user community does not quite
> know how to place the current (2) jars on the classpath or install a simple
> Web-Server like Tomcat. I HAVE to reorganize the code to allow INCREMENTAL
> upgrade to the secure version without requiring that it be used by ALL . Now
> that we will have a properties file this should be doable on the fly.
> > The REAL problem is how to keep an 'UNSECURE' version off the Internet?
> > Code partitioning and subclassing is just work BUT I do not have an answer
> on 'how to stop an unsecure version from ESCAPING (-: e.g. its LAN
> prison')!!! Any ideas, please?
> > Regards - George
> >
> > Nathan Wray wrote:
> >
> > > Thank you for undertaking this George and for being so open to
> suggestion, it is a pleasure to work with you.
> > >
> > > George I Matkovits wrote:
> > >
> > > > I rethink and rework the code . I will send you the source again ASAP
> after
> > > > working through your comments. Open source development is nice. Review
> by informed people really improves quality. :-)
> > > > Thank you for the comments and criticisms. - George
> > > >
> > > > Nathan Wray wrote:
> > > >
> > > > >
> > > > > Thanks George, I'm on London time so I didn't get this until today.
> I'm most concerned that the SOAP library won't work without SSL once these
> changes are committed which I've addressed below, please review and let me
> know what you think.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > line 109 in SecurityUtils will throw a null pointer exception if the
> "org.apache.soap.http.LogPropCreation"
> > > > > is not defined, I suggest changing it to
> > > > >
> ("true".equals(SystemProperties.get("org.apache.soap.http.LogPropCreation"))
> )
> > > > > which is equavalant but safer.
> > > > >
> > > > > similar in HTTPutils.java lines 184-215
> > > > >
> > > > >
> > > > > Rather than searching an arbitrary number of fixed locations for the
> property file, you could put it in the classpath and look in each folder of
> the classpath, like
> > > > >
> > > > > tokenizer = new StringTokenizer(classPath, pathSeparator,
> false);
> > > > > foundFile = false;
> > > > > while (!foundFile && (tokenizer.hasMoreTokens()))
> > > > > {
> > > > > path = tokenizer.nextToken() + fileSeparator +
> classPathSuffix + propertyFileName;
> > > > > file = new File(path);
> > > > >
> > > > > if (file.exists())
> > > > > {
> > > > > //yahoo
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > > HTTPUtils.java line 237 is redundant
> > > > >
> > > > > Should the code rebuild the URL object? The user should correctly
> build the URL object and the library should use it as is, I disagee with
> re-creating it. If the user wants "http://utl HTTP/1.1" then we should rely
> on them buyilding it that way. By re-building it we risk missing something,
> especially if URL is eventually subclassed.
> > > > >
> > > > > I also disagree with the SSL system property code and provider
> addition being in the SecurityUtils code. These are user issues that are
> part of SSL/HTTPS and aren't strictly part of SOAP, the user code should do
> these set-up calls. By adding them, SOAP can't be used without JSSE or
> similar which is unnecessary and I'm sure they add overhead if someone isn't
> using SSL. If we leave them as a user environment issue we can take out all
> of the SSL import statements as I have done in my version.
> > > > >
> > > > > I like the idea of an optional SOAP logging class, but I see no
> reason why the call to SecureUtils should be manditory, and the class seems
> to be misnamed if it's just loading system properties.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > George I Matkovits wrote:
> > > > >
> > > > > > Please find enclosed full source for the 'candidate'
> > > > > > SSLSoap. It will work from its internal defaults even
> > > > > > without the Soap.properties file! The Soap.properties file
> > > > > > is in the SRC utilities directory and it should be placed
> > > > > > into the CWD (beside many other places which I will document
> > > > > > in an Installation Note). The code was simplified as per
> > > > > > your comment but unfortunately it still needs 1 line of
> > > > > > change in all the Samples code. These are also in the
> > > > > > attached zip file. I build with Ant and my build (+test)
> > > > > > scripts are also included. The code should be also fully
> > > > > > thread safe but testing with your 1000 thread load would be
> > > > > > greatly appreciated. :-) I will wait for your test results
> > > > > > before commit. One of the new Classes is a Singleton with
> > > > > > its normal sync and protection structures.
> > > > > > The attachment was generated with jar and renamed to zip to
> > > > > > fool my mail utility. The code is based on xml-CVS09182000.
> > > > > > It has an early version of Sanjiva's messaging. It was
> > > > > > tested with Apache-SSL and Tomcat (on both Windows2000 and
> > > > > > Linux). Testing with any other Web combinations would be
> > > > > > wonderful. Two of the original code modules were changed and
> > > > > > three new ones have been added. I will be making more
> > > > > > changes to the Properties file architecture in the upcoming
> > > > > > SecureSoap Version. I will start checking this into CVS on
> > > > > > Monday. Notes in the INFO directory are also out off date
> > > > > > and will be updated on Monday.
> > > > > > Regards and many thanks for the help - George
> > > > > >
> > > > > > ----------------------------------------
> > > > > >
> Name: Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> > > > > >
> Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> Type: Zip Compressed Data (application/x-zip-compressed)
> > > > > >
> Encoding: base64
> > > > >
> > > > > --
> > > > > Nathan Wray
> > > > > nwray@mich.com
> > > > > --
> > > > > "I see in the near future a crisis approaching that
> > > > > unnerves me and causes me to tremble for the safety
> > > > > of my country
corporations have been enthroned and
> > > > > an era of corruption in high places will follow, and the
> > > > > money of the country will endeavor to prolong its reign
> > > > > by working upon the prejudices of the people until all
> > > > > wealth is aggregated in a few hands and the republic is
> > > > > destroyed. I feel at this moment more anxiety for the
> > > > > safety of my country than ever before, even in the
> > > > > midst of war."
> > > > > --Abraham Lincoln, 1865
> > > > >
> > >
> > > --
> > > Nathan Wray
> > > nwray@mich.com
> > > --
> > > "I see in the near future a crisis approaching that
> > > unnerves me and causes me to tremble for the safety
> > > of my country
corporations have been enthroned and
> > > an era of corruption in high places will follow, and the
> > > money of the country will endeavor to prolong its reign
> > > by working upon the prejudices of the people until all
> > > wealth is aggregated in a few hands and the republic is
> > > destroyed. I feel at this moment more anxiety for the
> > > safety of my country than ever before, even in the
> > > midst of war."
> > > --Abraham Lincoln, 1865
>
> --
> Nathan Wray
> nwray@mich.com
> --
> "Can anybody cite a single interesting or
> important idea or argument that's emerged
> from the months of campaigning in the
> current U.S. presidential race?"
> Jon Katz, slashdot.org
> http://slashdot.org/article.pl?sid=00/09/19/035231&mode=nested
Re: SSLSoap Release Candidate.
Posted by George I Matkovits <ma...@uswest.net>.
Yes (not for commercial use) but IMHO there are compatible commercial versions
now! My company will also need one and I will be researching this issue ASAP.
1st I have to complete and TEST... the promised Soap Server Access Control
code. (That is: SecureSoap).
Regards - George
Kartheek Hirode wrote:
> Hello George,
> Your work is very, very appreciated. We had managed to 'write up' code for
> SOAP over SSL (it works:) but taking it to Apache needs a whole magnum
> effort.
> Thanks bunch for taking this up.
>
> Btw, is Sun's JSSE controlled by licensing issues? That was one of our
> stumbling
> blocks in commercializing our system.
>
> Thanks again, good day,
> --Kartheek
>
> -----Original Message-----
> From: Nathan Wray [mailto:nwray@mich.com]
> Sent: Wednesday, September 27, 2000 3:05 AM
> To: soap-dev@xml.apache.org
> Subject: Re: SSLSoap Release Candidate.
>
> George, will your changes become part of Apache SOAP or a parallel effort
> SecureSoap? The concern I expressed was based on requiring JSSE for all
> SOAP users, but if this is a security-specific distribution my comments are
> less relevant.
>
> George I Matkovits wrote:
>
> > I did some thinking after reading your comments. They reflect very well on
> my biases, even the possible null pointer exception, which was intentional.
> > I got into Soap Security (SSL is just the start) to counter the advantages
> of the MS Soap Implementation vis-a-vis Java Soap. IMHO MS defined the V1.0
> standard to stack the decks against any and all Soap or Web Services (aka
> Win.Net) implementations outside the Windows COM framework. (V1.1 is a bit
> better but not much!) I understand why they are doing this (I had some long
> discussions with very competent MS 'Technical Evangelists') and the only
> REAL answer is to have a competitive Java Solution. I
> > have been working towards this ASAP. What I forgotten to consider is that
> many, many Java programmers come from VB kind of backgrounds. I see this on
> several of the other Java Forums. Many of the apache-user forum members find
> it even difficult to create a simple classpath for Apache Soap or write
> almost anything more complex then a 'Hello World' program without outside
> tutoring (they will improve eventually, Java will help with product
> maturity). The current SSL Implementation would really require
> > SSL jars to be present, IMHO 80% of the soap-user community does not quite
> know how to place the current (2) jars on the classpath or install a simple
> Web-Server like Tomcat. I HAVE to reorganize the code to allow INCREMENTAL
> upgrade to the secure version without requiring that it be used by ALL . Now
> that we will have a properties file this should be doable on the fly.
> > The REAL problem is how to keep an 'UNSECURE' version off the Internet?
> > Code partitioning and subclassing is just work BUT I do not have an answer
> on 'how to stop an unsecure version from ESCAPING (-: e.g. its LAN
> prison')!!! Any ideas, please?
> > Regards - George
> >
> > Nathan Wray wrote:
> >
> > > Thank you for undertaking this George and for being so open to
> suggestion, it is a pleasure to work with you.
> > >
> > > George I Matkovits wrote:
> > >
> > > > I rethink and rework the code . I will send you the source again ASAP
> after
> > > > working through your comments. Open source development is nice. Review
> by informed people really improves quality. :-)
> > > > Thank you for the comments and criticisms. - George
> > > >
> > > > Nathan Wray wrote:
> > > >
> > > > >
> > > > > Thanks George, I'm on London time so I didn't get this until today.
> I'm most concerned that the SOAP library won't work without SSL once these
> changes are committed which I've addressed below, please review and let me
> know what you think.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > line 109 in SecurityUtils will throw a null pointer exception if the
> "org.apache.soap.http.LogPropCreation"
> > > > > is not defined, I suggest changing it to
> > > > >
> ("true".equals(SystemProperties.get("org.apache.soap.http.LogPropCreation"))
> )
> > > > > which is equavalant but safer.
> > > > >
> > > > > similar in HTTPutils.java lines 184-215
> > > > >
> > > > >
> > > > > Rather than searching an arbitrary number of fixed locations for the
> property file, you could put it in the classpath and look in each folder of
> the classpath, like
> > > > >
> > > > > tokenizer = new StringTokenizer(classPath, pathSeparator,
> false);
> > > > > foundFile = false;
> > > > > while (!foundFile && (tokenizer.hasMoreTokens()))
> > > > > {
> > > > > path = tokenizer.nextToken() + fileSeparator +
> classPathSuffix + propertyFileName;
> > > > > file = new File(path);
> > > > >
> > > > > if (file.exists())
> > > > > {
> > > > > //yahoo
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > > HTTPUtils.java line 237 is redundant
> > > > >
> > > > > Should the code rebuild the URL object? The user should correctly
> build the URL object and the library should use it as is, I disagee with
> re-creating it. If the user wants "http://utl HTTP/1.1" then we should rely
> on them buyilding it that way. By re-building it we risk missing something,
> especially if URL is eventually subclassed.
> > > > >
> > > > > I also disagree with the SSL system property code and provider
> addition being in the SecurityUtils code. These are user issues that are
> part of SSL/HTTPS and aren't strictly part of SOAP, the user code should do
> these set-up calls. By adding them, SOAP can't be used without JSSE or
> similar which is unnecessary and I'm sure they add overhead if someone isn't
> using SSL. If we leave them as a user environment issue we can take out all
> of the SSL import statements as I have done in my version.
> > > > >
> > > > > I like the idea of an optional SOAP logging class, but I see no
> reason why the call to SecureUtils should be manditory, and the class seems
> to be misnamed if it's just loading system properties.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > George I Matkovits wrote:
> > > > >
> > > > > > Please find enclosed full source for the 'candidate'
> > > > > > SSLSoap. It will work from its internal defaults even
> > > > > > without the Soap.properties file! The Soap.properties file
> > > > > > is in the SRC utilities directory and it should be placed
> > > > > > into the CWD (beside many other places which I will document
> > > > > > in an Installation Note). The code was simplified as per
> > > > > > your comment but unfortunately it still needs 1 line of
> > > > > > change in all the Samples code. These are also in the
> > > > > > attached zip file. I build with Ant and my build (+test)
> > > > > > scripts are also included. The code should be also fully
> > > > > > thread safe but testing with your 1000 thread load would be
> > > > > > greatly appreciated. :-) I will wait for your test results
> > > > > > before commit. One of the new Classes is a Singleton with
> > > > > > its normal sync and protection structures.
> > > > > > The attachment was generated with jar and renamed to zip to
> > > > > > fool my mail utility. The code is based on xml-CVS09182000.
> > > > > > It has an early version of Sanjiva's messaging. It was
> > > > > > tested with Apache-SSL and Tomcat (on both Windows2000 and
> > > > > > Linux). Testing with any other Web combinations would be
> > > > > > wonderful. Two of the original code modules were changed and
> > > > > > three new ones have been added. I will be making more
> > > > > > changes to the Properties file architecture in the upcoming
> > > > > > SecureSoap Version. I will start checking this into CVS on
> > > > > > Monday. Notes in the INFO directory are also out off date
> > > > > > and will be updated on Monday.
> > > > > > Regards and many thanks for the help - George
> > > > > >
> > > > > > ----------------------------------------
> > > > > >
> Name: Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> > > > > >
> Secure_Soap_ALL_fromCVS09182000-on0924VerE_MyREL_2_0SSL-A0(fromB5).zip
> Type: Zip Compressed Data (application/x-zip-compressed)
> > > > > >
> Encoding: base64
> > > > >
> > > > > --
> > > > > Nathan Wray
> > > > > nwray@mich.com
> > > > > --
> > > > > "I see in the near future a crisis approaching that
> > > > > unnerves me and causes me to tremble for the safety
> > > > > of my country
corporations have been enthroned and
> > > > > an era of corruption in high places will follow, and the
> > > > > money of the country will endeavor to prolong its reign
> > > > > by working upon the prejudices of the people until all
> > > > > wealth is aggregated in a few hands and the republic is
> > > > > destroyed. I feel at this moment more anxiety for the
> > > > > safety of my country than ever before, even in the
> > > > > midst of war."
> > > > > --Abraham Lincoln, 1865
> > > > >
> > >
> > > --
> > > Nathan Wray
> > > nwray@mich.com
> > > --
> > > "I see in the near future a crisis approaching that
> > > unnerves me and causes me to tremble for the safety
> > > of my country
corporations have been enthroned and
> > > an era of corruption in high places will follow, and the
> > > money of the country will endeavor to prolong its reign
> > > by working upon the prejudices of the people until all
> > > wealth is aggregated in a few hands and the republic is
> > > destroyed. I feel at this moment more anxiety for the
> > > safety of my country than ever before, even in the
> > > midst of war."
> > > --Abraham Lincoln, 1865
>
> --
> Nathan Wray
> nwray@mich.com
> --
> "Can anybody cite a single interesting or
> important idea or argument that's emerged
> from the months of campaigning in the
> current U.S. presidential race?"
> Jon Katz, slashdot.org
> http://slashdot.org/article.pl?sid=00/09/19/035231&mode=nested