PROPOSAL: commons-ssl

Hi,

Please take a look at "not-yet-commons-ssl", currently hosted here:

http://juliusdavies.ca/commons-ssl/

This java library was developed over the last year with Apache Commons
in mind. I've been hanging out on the httpclient mailing list for 2
years, learning about https and ssl and java thanks to the
EasySSLProtocolSocketFactory and AuthSSLProtocolSocketFactory written
by Oleg Kalnichevski and Adrian Sutton.

If you google for "java ssl" you'll notice that HTTPClient is actually
the first "*.apache.org" site to appear (sometimes 2nd page, sometimes
3rd page of results):

http://www.google.ca/search?q=java+ssl

Meanwhile if you just google for "ssl", you'll notice that "www.modssl.org" and
"www.apache-ssl.org" are on the first page of results. Both of those
sites contain (probably older?) versions of this documentation:

http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#selfcert

As a Java developer I found these two different "ways" of setting up
SSL to be a source of confusion. The OpenSSL/Apache documentation
about setting up SSL is very good, very handy. But it just doesn't
work with Java, because Java only understands "JKS" files created by
"keytool". (Oh wait... months later I discover that Java can also
handle "PKCS #12" by pretending the file is a special type of JKS
file.)

Once I finally started to understand these two different "ways", I
started trying to build an easier way to work with both ways. The
goal of "commons-ssl" is bridge that gap. I also tried to make SSL
and Java easier to work with by not requiring the user to know so
much.

With Commons-SSL the user no longer needs to know:

1. What kind of keystore file is this? JKS or PKCS #12? Commons-SSL
will just figure this out on its own. (We should probably also start
considering these newer JCEKS files, but that's not in place yet.)

2. The user created a PKCS #12 file using "openssl" but forgot to say
"-outform DER". Commons-SSL can still deal with that file.

3. The user created a "Traditional SSLeay" private key instead of
PKCS8 by accident. Commons-SSL doesn't mind.

If Commons-SSL could have a motto, I think it would be this: "You
bring the files and the password, I'll do the rest." Perhaps add this
sub-title: "If your password is wrong I'll throw a
ProbablyBadPasswordException".

Whereas pre-Commons-SSL, Java's motto would be: "You bring the files,
the password, make sure you know the type, and if it's PKCS #12, make
sure it's in DER. If your RSA private key and associated X509 chain
are in separate files, you're going to have to transform them into
PEM, start up Windows Notepad to cut & paste them into a single file,
and then use 'openssl pkcs12' to get them into DER."

Perhaps add this sub-title: "If your password is wrong I might throw
a PaddingException or a DigestException. Depends on the vendor and
version of Java.".


That's the highest goal: Make SSL easier for the users. Make it
easier for those courageous souls downloading our software and running
it on their machines.

The next goal: Make SSL easier for the developer. In Java changing
aspects of an SSLSocketFactory or SSLServerSocketFactory is quite
awkward. Many of the approaches in use today end up polluting the
entire JVM. You want to connect to "https://MySelfSignedSite.com/"
and suddenly all your LDAPS and RMI-SSL and JDBC-SSL calls aren't
checking the server certificate either! The HTTPClient group came up
with a very novel solution: "https-easy://".

Commons-SSL tried to take this further and generalize it. The
developer can now create a single isolated SSLSocketFactory very easy
(SSLClient extends SSLSocketFactory).

SSLClient client = new SSLCLient();

[Notice how I'm borrowing from HttpClient's own usage pattern:
HTTPClient client = new HttpClient();]

The developer can then modify that SSLSocketFactory to suit their needs:

client.setCheckHostname( false );
client.setCheckCRL( false );
client.setCheckExpiry( true );
client.setMaxTrustChainDepth( 6 ); // not yet implemented

client.addTrustMaterial( new TrustMaterial( "/path/to/cert.pem" ) );
client.setKeyMaterial( new KeyMaterial( "/path/to/key.pem",
"/path/to/certs.pem", "secret".toCharArray() ) );


That's the library! Now some details about this "PROPOSAL" and how it
might fit in with Apache:

Meritocracy, Community:
------------------------------------
So far, yes, it's just been me committing whenever I like. This has
been convenient to try and get the library into a useable state. I
think the library has good coherency because only one person has been
working on it so far. But on the other hand, SSL is touchy stuff, and
it needs eyes looking at it. I will never be able to declare that
"yes, this library doesn't compromise your security" by myself. I
think I'm ready to let go now, and let others extend this in exciting
ways.

The flip side of this requirement: I like to think I would make a
good member of the Apache Community! I generally try to post helpful
emails to some of the mailing lists. So while Commons-SSL doesn't
have much of a community around it yet, HttpClient and other projects
might enjoy having me around! [Mind you, I'm staying around on those
mailing lists whether you accept this code or not. So it's not much
of an argument for accepting the code. :-p]


Core Developers:
------------------------------------
Definitely a weak spot with Commons-SSL right now. There's only me.
Some people hanging out on the HTTPClient mailing list have shown
interest in *using* the library, but no-one has time to start writing
code.

Still, SSL is a fun little niche. I imagine a few people will show up
eventually, whether I'm around or not! I'm a shameless optimist.


Alignment with existing Apache subprojects
------------------------------------
Here's where Commons-SSL is very strong. It's actually allowing all
these server-socket-creating Java applications so point to the Apache
httpd TLS FAQ! We're actually bridging an old split, between OpenSSL
and Sun's Java, perhaps like the Pope's visit to Turkey right now?

In terms of code use: we're using code from directory.apache.org,
we've also using code from commons-codec. In terms of helping other
projects: Commons-SSL has lots of hooks in place for HTTPClient, and
anyone who uses SSLSocketFactory or SSLServerSocketFactory can drop
Commons-SSL into their project quite seamlessly.

I think Commons-SSL would be good for many open-source projects. Here
are a few ideas:

http://jtds.sourceforge.net/
http://telnetd.sourceforge.net/
http://directory.apache.org/ (to help when being an ldaps:// server)
http://tomcat.apache.org/ (so support APR-SSL config when APR isn't around)

That's just the server side. It's very handy on the client side, too.
Already two open source projects (that I know of) are using
Commons-SSL:

http://xfire.codehaus.org/HTTP+Transport
http://www.soapui.org/


There's one last topic to address in this proposal:

Where Should Commons-SSL Ultimately Live?
------------------------------------
First there's the question of Incubation, or Sandbox. I quite like
Incubation because it provides an ideal "software project template".
That's my way of understanding it. Incubation shoots for perfection.
While I don't think I can achieve perfection, I like to try.

Sandbox, on the other hand, seems to be a quicker way to bring the
code into the family. It's probably more suitable for small projects
like this, whereas Incubation is more geared for larger projects like
"directory.apache.org" (congratulations on their graduation!). But
even a small project can benefit from implementing the many high goals
and excellent thinking that's been put into Incubation. Personally I
don't really know which I prefer. I guess the fact that I'm just a
single developer makes me lean towards sandbox. Suddenly a lot of
apache people will be able to commit to Commons-SSL! That's exciting.

Unless I attract some pretty motivated people to this project quite
soon, incubation will take a long time. I have a day job, a family.
Like all of us, I don't have as much time as I would like for
Commons-SSL. But it's just a mild leaning towards sandbox. I'm very
happy with either.

Aside from the question of Sandbox or Incubation, there's also the
question of final destination.

I can think of three places:

#1. commons

#2. http-components

#3. commons-net


#1 - Commons seems the most obvious place to me, but #2 -
Http-Components also seems like a very interesting chioce. I don't
know enough about #3 - commons-net to really comment, but it seems
worth including in the list.

#2 - http-components is especially interesting because two features of
SSL depend strongly on HTTP: CRL checking and OCSP. It would be
weird to have people downloading http-components so that they can
create SSLServerSockets! But there is a lot of overlap, and "https"
is definitely the most varied and uhh... "exciting" arena for
interesting SSL problems these days.

Probably if we're shooting for purity-of-design, commons is the safe
bet. But lumping in with http-components like a good old-fashioned
"static linking" good make for an interesting experiment. We could
unwind it at a future date if we didn't like it. (Famous last words.
Note: I didn't say we could unwind it "easily"!).

I'm going to just leave this email as a "PROPOSAL" for now, and let
people on general@jakarta transform this into the many votes it
probably needs. I guess it needs at least these three separate votes:

1. Vote to accept the code in some fashion.

2. Vote for Incubation or Sandbox.

3. Vote for final destination.


Oh, one final note. If this gets sandboxed, I don't need to be a
committer at this time. I'm more than happy to just email patches.


--
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

Re: PROPOSAL: commons-ssl

Julius Davies wrote:
> Oh, one final note. If this gets sandboxed, I don't need to be a
> committer at this time. I'm more than happy to just email patches.

Don't worry, David. I am sure you have plenty of fans here who will be
more than happy to vote for you as a committer!

Re: PROPOSAL: commons-ssl

Hey, that sounds very cool. Nice job too in organizing your email and
hitting many of the important highlights required to be an Apache
projects.

WILL

On 12/1/06, Julius Davies wrote:
> Hi,
>
> Please take a look at "not-yet-commons-ssl", currently hosted here:
>
> http://juliusdavies.ca/commons-ssl/
>
> This java library was developed over the last year with Apache Commons
> in mind. I've been hanging out on the httpclient mailing list for 2
> years, learning about https and ssl and java thanks to the
> EasySSLProtocolSocketFactory and AuthSSLProtocolSocketFactory written
> by Oleg Kalnichevski and Adrian Sutton.
>
> If you google for "java ssl" you'll notice that HTTPClient is actually
> the first "*.apache.org" site to appear (sometimes 2nd page, sometimes
> 3rd page of results):
>
> http://www.google.ca/search?q=java+ssl
>
> Meanwhile if you just google for "ssl", you'll notice that "www.modssl.org" and
> "www.apache-ssl.org" are on the first page of results. Both of those
> sites contain (probably older?) versions of this documentation:
>
> http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#selfcert
>
> As a Java developer I found these two different "ways" of setting up
> SSL to be a source of confusion. The OpenSSL/Apache documentation
> about setting up SSL is very good, very handy. But it just doesn't
> work with Java, because Java only understands "JKS" files created by
> "keytool". (Oh wait... months later I discover that Java can also
> handle "PKCS #12" by pretending the file is a special type of JKS
> file.)
>
> Once I finally started to understand these two different "ways", I
> started trying to build an easier way to work with both ways. The
> goal of "commons-ssl" is bridge that gap. I also tried to make SSL
> and Java easier to work with by not requiring the user to know so
> much.
>
> With Commons-SSL the user no longer needs to know:
>
> 1. What kind of keystore file is this? JKS or PKCS #12? Commons-SSL
> will just figure this out on its own. (We should probably also start
> considering these newer JCEKS files, but that's not in place yet.)
>
> 2. The user created a PKCS #12 file using "openssl" but forgot to say
> "-outform DER". Commons-SSL can still deal with that file.
>
> 3. The user created a "Traditional SSLeay" private key instead of
> PKCS8 by accident. Commons-SSL doesn't mind.
>
> If Commons-SSL could have a motto, I think it would be this: "You
> bring the files and the password, I'll do the rest." Perhaps add this
> sub-title: "If your password is wrong I'll throw a
> ProbablyBadPasswordException".
>
> Whereas pre-Commons-SSL, Java's motto would be: "You bring the files,
> the password, make sure you know the type, and if it's PKCS #12, make
> sure it's in DER. If your RSA private key and associated X509 chain
> are in separate files, you're going to have to transform them into
> PEM, start up Windows Notepad to cut & paste them into a single file,
> and then use 'openssl pkcs12' to get them into DER."
>
> Perhaps add this sub-title: "If your password is wrong I might throw
> a PaddingException or a DigestException. Depends on the vendor and
> version of Java.".
>
>
> That's the highest goal: Make SSL easier for the users. Make it
> easier for those courageous souls downloading our software and running
> it on their machines.
>
> The next goal: Make SSL easier for the developer. In Java changing
> aspects of an SSLSocketFactory or SSLServerSocketFactory is quite
> awkward. Many of the approaches in use today end up polluting the
> entire JVM. You want to connect to "https://MySelfSignedSite.com/"
> and suddenly all your LDAPS and RMI-SSL and JDBC-SSL calls aren't
> checking the server certificate either! The HTTPClient group came up
> with a very novel solution: "https-easy://".
>
> Commons-SSL tried to take this further and generalize it. The
> developer can now create a single isolated SSLSocketFactory very easy
> (SSLClient extends SSLSocketFactory).
>
> SSLClient client = new SSLCLient();
>
> [Notice how I'm borrowing from HttpClient's own usage pattern:
> HTTPClient client = new HttpClient();]
>
> The developer can then modify that SSLSocketFactory to suit their needs:
>
> client.setCheckHostname( false );
> client.setCheckCRL( false );
> client.setCheckExpiry( true );
> client.setMaxTrustChainDepth( 6 ); // not yet implemented
>
> client.addTrustMaterial( new TrustMaterial( "/path/to/cert.pem" ) );
> client.setKeyMaterial( new KeyMaterial( "/path/to/key.pem",
> "/path/to/certs.pem", "secret".toCharArray() ) );
>
>
> That's the library! Now some details about this "PROPOSAL" and how it
> might fit in with Apache:
>
> Meritocracy, Community:
> ------------------------------------
> So far, yes, it's just been me committing whenever I like. This has
> been convenient to try and get the library into a useable state. I
> think the library has good coherency because only one person has been
> working on it so far. But on the other hand, SSL is touchy stuff, and
> it needs eyes looking at it. I will never be able to declare that
> "yes, this library doesn't compromise your security" by myself. I
> think I'm ready to let go now, and let others extend this in exciting
> ways.
>
> The flip side of this requirement: I like to think I would make a
> good member of the Apache Community! I generally try to post helpful
> emails to some of the mailing lists. So while Commons-SSL doesn't
> have much of a community around it yet, HttpClient and other projects
> might enjoy having me around! [Mind you, I'm staying around on those
> mailing lists whether you accept this code or not. So it's not much
> of an argument for accepting the code. :-p]
>
>
> Core Developers:
> ------------------------------------
> Definitely a weak spot with Commons-SSL right now. There's only me.
> Some people hanging out on the HTTPClient mailing list have shown
> interest in *using* the library, but no-one has time to start writing
> code.
>
> Still, SSL is a fun little niche. I imagine a few people will show up
> eventually, whether I'm around or not! I'm a shameless optimist.
>
>
> Alignment with existing Apache subprojects
> ------------------------------------
> Here's where Commons-SSL is very strong. It's actually allowing all
> these server-socket-creating Java applications so point to the Apache
> httpd TLS FAQ! We're actually bridging an old split, between OpenSSL
> and Sun's Java, perhaps like the Pope's visit to Turkey right now?
>
> In terms of code use: we're using code from directory.apache.org,
> we've also using code from commons-codec. In terms of helping other
> projects: Commons-SSL has lots of hooks in place for HTTPClient, and
> anyone who uses SSLSocketFactory or SSLServerSocketFactory can drop
> Commons-SSL into their project quite seamlessly.
>
> I think Commons-SSL would be good for many open-source projects. Here
> are a few ideas:
>
> http://jtds.sourceforge.net/
> http://telnetd.sourceforge.net/
> http://directory.apache.org/ (to help when being an ldaps:// server)
> http://tomcat.apache.org/ (so support APR-SSL config when APR isn't around)
>
> That's just the server side. It's very handy on the client side, too.
> Already two open source projects (that I know of) are using
> Commons-SSL:
>
> http://xfire.codehaus.org/HTTP+Transport
> http://www.soapui.org/
>
>
> There's one last topic to address in this proposal:
>
> Where Should Commons-SSL Ultimately Live?
> ------------------------------------
> First there's the question of Incubation, or Sandbox. I quite like
> Incubation because it provides an ideal "software project template".
> That's my way of understanding it. Incubation shoots for perfection.
> While I don't think I can achieve perfection, I like to try.
>
> Sandbox, on the other hand, seems to be a quicker way to bring the
> code into the family. It's probably more suitable for small projects
> like this, whereas Incubation is more geared for larger projects like
> "directory.apache.org" (congratulations on their graduation!). But
> even a small project can benefit from implementing the many high goals
> and excellent thinking that's been put into Incubation. Personally I
> don't really know which I prefer. I guess the fact that I'm just a
> single developer makes me lean towards sandbox. Suddenly a lot of
> apache people will be able to commit to Commons-SSL! That's exciting.
>
> Unless I attract some pretty motivated people to this project quite
> soon, incubation will take a long time. I have a day job, a family.
> Like all of us, I don't have as much time as I would like for
> Commons-SSL. But it's just a mild leaning towards sandbox. I'm very
> happy with either.
>
> Aside from the question of Sandbox or Incubation, there's also the
> question of final destination.
>
> I can think of three places:
>
> #1. commons
>
> #2. http-components
>
> #3. commons-net
>
>
> #1 - Commons seems the most obvious place to me, but #2 -
> Http-Components also seems like a very interesting chioce. I don't
> know enough about #3 - commons-net to really comment, but it seems
> worth including in the list.
>
> #2 - http-components is especially interesting because two features of
> SSL depend strongly on HTTP: CRL checking and OCSP. It would be
> weird to have people downloading http-components so that they can
> create SSLServerSockets! But there is a lot of overlap, and "https"
> is definitely the most varied and uhh... "exciting" arena for
> interesting SSL problems these days.
>
> Probably if we're shooting for purity-of-design, commons is the safe
> bet. But lumping in with http-components like a good old-fashioned
> "static linking" good make for an interesting experiment. We could
> unwind it at a future date if we didn't like it. (Famous last words.
> Note: I didn't say we could unwind it "easily"!).
>
> I'm going to just leave this email as a "PROPOSAL" for now, and let
> people on general@jakarta transform this into the many votes it
> probably needs. I guess it needs at least these three separate votes:
>
> 1. Vote to accept the code in some fashion.
>
> 2. Vote for Incubation or Sandbox.
>
> 3. Vote for final destination.
>
>
> Oh, one final note. If this gets sandboxed, I don't need to be a
> committer at this time. I'm more than happy to just email patches.
>
>
> --
> yours,
>
> Julius Davies
> 416-652-0183
> http://juliusdavies.ca/
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


--
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

Re: PROPOSAL: commons-ssl

Hi Julius,

it's great to see that you finally got the proposal ball rolling :-)

I didn't look into your code, so my comments are based on the proposal
itself and on your web page. I like the positive attitude with which
you present the advantages of the project. However, I a missing a
clear definition of the _project_scope_. That may seem like a small
detail, but it really is a precondition for finding both an appropriate
name and home for your code base.
From your description, I understand that the purpose is
- giving easy access to different types of key material and certificates
- verifying certificates and certificate chains
- bridging different Java APIs (?)

The working title "Commons-SSL" does not really reflect this. Do you
plan to implement the SSL protocol as part of the project? Probably
not, so the title is misleading. An all-encompassing name might also
be offensive to people working on other SSL-related projects. I think
you should spend the time and define not only a motto, but a very clear
scope of the project. Both in terms of what's in scope as well as what's
out of scope. From there on, we can work on finding a name and home.

Please do not underestimate the importance of this step. Finding a
name may seem like a minor detail, but the problem of defining the
scope is very real. Only a few months ago, there was a long discussion
on this list about a proposal for "testing.apache.org". I haven't read
anything about it anymore after the supporters realized that a scope of
"everything that has to do with testing" was overly broad. We don't
want to see that happen to your proposal.


I am also a little worried about this statement on your web page:

> The PKCS12 key derivation function (for some PKCS8 version 1.5 encrypted
> keys) was cut & paste from BouncyCastle (bouncycastle.org). They
> originally got it from RSA's PKCS12 specification
> (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf),
> so we hope this copy & paste operation is okay!

The BouncyCastle license (http://bouncycastle.org/licence.html)
is quite specific that the license must remain intact. You can
not just relicense their code under the Apache License. That's
assuming that the part you copied and pasted was not explicitly
released with a different license.

cheers,
Roland

Re: PROPOSAL: commons-ssl

Hi, Roland,

I have already noticed some confusion about the "commons-ssl" name -
someone emailed httpclient-dev asking:

"Does this SSL support TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA?"

I had to explain that Commons-SSL just sits on top of the JSSE and JCE
to try and make working with SSL and Java easier. Your point about
the name is a good one.

Regarding the BouncyCastle code, I sent an email to the BouncyCastle
mailing list. Here's the reply I got:


On 11/28/06, David Hook wrote:
>
> Thanks for the feedback!
>
> Cool.
>
> In regards:
>
> >Is there any way I can have ONLY these 100 lines and license it under
> > Apache 2.0? I would be more than happy to attribute it to you guys in
> > my NOTICE.txt file, as well as in comments in the code, and on my main
> > web page.
>
> If attribution is included we have no issue with the section of code
> being included in a product distributed under Apache 2.0.
>
> Regards,
>
> David
>

I hope that's sufficient to address the licensing concern.

yours,

Julius


On 12/1/06, Roland Weber wrote:
> Hi Julius,
>
> it's great to see that you finally got the proposal ball rolling :-)
>
> I didn't look into your code, so my comments are based on the proposal
> itself and on your web page. I like the positive attitude with which
> you present the advantages of the project. However, I a missing a
> clear definition of the _project_scope_. That may seem like a small
> detail, but it really is a precondition for finding both an appropriate
> name and home for your code base.
> From your description, I understand that the purpose is
> - giving easy access to different types of key material and certificates
> - verifying certificates and certificate chains
> - bridging different Java APIs (?)
>
> The working title "Commons-SSL" does not really reflect this. Do you
> plan to implement the SSL protocol as part of the project? Probably
> not, so the title is misleading. An all-encompassing name might also
> be offensive to people working on other SSL-related projects. I think
> you should spend the time and define not only a motto, but a very clear
> scope of the project. Both in terms of what's in scope as well as what's
> out of scope. From there on, we can work on finding a name and home.
>
> Please do not underestimate the importance of this step. Finding a
> name may seem like a minor detail, but the problem of defining the
> scope is very real. Only a few months ago, there was a long discussion
> on this list about a proposal for "testing.apache.org". I haven't read
> anything about it anymore after the supporters realized that a scope of
> "everything that has to do with testing" was overly broad. We don't
> want to see that happen to your proposal.
>
>
> I am also a little worried about this statement on your web page:
>
> > The PKCS12 key derivation function (for some PKCS8 version 1.5 encrypted
> > keys) was cut & paste from BouncyCastle (bouncycastle.org). They
> > originally got it from RSA's PKCS12 specification
> > (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf),
> > so we hope this copy & paste operation is okay!
>
> The BouncyCastle license (http://bouncycastle.org/licence.html)
> is quite specific that the license must remain intact. You can
> not just relicense their code under the Apache License. That's
> assuming that the part you copied and pasted was not explicitly
> released with a different license.
>
> cheers,
> Roland
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


--
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

Re: PROPOSAL: commons-ssl

Hi Julius,

> Regarding the BouncyCastle code, I sent an email to the BouncyCastle
> mailing list. Here's the reply I got:
>
> [...]
>> If attribution is included we have no issue with the section of code
>> being included in a product distributed under Apache 2.0.
> [...]
>
> I hope that's sufficient to address the licensing concern.

The "attribution" part probably means that the code must still carry
the BouncyCastle license rather than the Apache license. I guess a
lawyer will have to look into this, unless the BouncyCastle license
has been discussed before.

cheers,
Roland

Re: PROPOSAL: commons-ssl

Also (note this is getting technical), Apache policy is to acknowledge
copyrights in the NOTICE file not the source code. This is a new
policy, effective Nov 1 2006. See:

http://www.apache.org/legal/src-headers.html

WILL

On 12/1/06, Roland Weber wrote:
> Hi Julius,
>
> > Regarding the BouncyCastle code, I sent an email to the BouncyCastle
> > mailing list. Here's the reply I got:
> >
> > [...]
> >> If attribution is included we have no issue with the section of code
> >> being included in a product distributed under Apache 2.0.
> > [...]
> >
> > I hope that's sufficient to address the licensing concern.
>
> The "attribution" part probably means that the code must still carry
> the BouncyCastle license rather than the Apache license. I guess a
> lawyer will have to look into this, unless the BouncyCastle license
> has been discussed before.
>
> cheers,
> Roland
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


--
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

Re: PROPOSAL: commons-ssl

Julius Davies wrote:
....
> I had to explain that Commons-SSL just sits on top of the JSSE and JCE
> to try and make working with SSL and Java easier. Your point about
> the name is a good one.

The counterpoint to name argument. Just single example, I'm sure there are many
more: commons-logging sits on top of log4j/java logger/logkit/... and tries to
make working with all them seamless.

commons-ssl may be not the best name but it isn't terribly bad either.

Vadim

....

> On 12/1/06, Roland Weber wrote:
>>
>> The working title "Commons-SSL" does not really reflect this. Do you
>> plan to implement the SSL protocol as part of the project? Probably
>> not, so the title is misleading. An all-encompassing name might also
>> be offensive to people working on other SSL-related projects. I think
>> you should spend the time and define not only a motto, but a very clear
>> scope of the project. Both in terms of what's in scope as well as what's
>> out of scope. From there on, we can work on finding a name and home.
>>
>> Please do not underestimate the importance of this step. Finding a
>> name may seem like a minor detail, but the problem of defining the
>> scope is very real. Only a few months ago, there was a long discussion
>> on this list about a proposal for "testing.apache.org". I haven't read
>> anything about it anymore after the supporters realized that a scope of
>> "everything that has to do with testing" was overly broad. We don't
>> want to see that happen to your proposal.

Re: PROPOSAL: commons-ssl

Also, just to be clear, when Roland says "I guess a lawyer will have
to look into that", there's a specific internal Apache mailing list
("legal-discuss") for resolving exactly these kind of issues.

To me this seems a perfect candidate for the incubator, and possibly
to move into Jakarta upon graduation. The challenge is that you have
to get others interested enough to join the project. They don't have
to be Apache people (although you'll need a couple of Apache mentors).
Probably before incubation. (though others should feel free to
disagree).

Part of the reason that the community aspect is so important is that
there's a belief that multi-person projects are more sustainable than
single-developer projects. We had a long conversation about this in
the Jakarta BOF at ApacheCon US. There's a history of projects that
have come into Jakarta with good code and no community that have
(ultimately) ended up with no support. It frustrates users and is a
tricky issue to resolve.

WILL

On 12/1/06, Will Glass-Husain wrote:
> Also (note this is getting technical), Apache policy is to acknowledge
> copyrights in the NOTICE file not the source code. This is a new
> policy, effective Nov 1 2006. See:
>
> http://www.apache.org/legal/src-headers.html
>
> WILL
>
> On 12/1/06, Roland Weber wrote:
> > Hi Julius,
> >
> > > Regarding the BouncyCastle code, I sent an email to the BouncyCastle
> > > mailing list. Here's the reply I got:
> > >
> > > [...]
> > >> If attribution is included we have no issue with the section of code
> > >> being included in a product distributed under Apache 2.0.
> > > [...]
> > >
> > > I hope that's sufficient to address the licensing concern.
> >
> > The "attribution" part probably means that the code must still carry
> > the BouncyCastle license rather than the Apache license. I guess a
> > lawyer will have to look into this, unless the BouncyCastle license
> > has been discussed before.
> >
> > cheers,
> > Roland
> >
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>


--
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

Re: PROPOSAL: commons-ssl -> commons-sslutils?

On Fri, 2006-12-01 at 15:20 -0500, Vadim Gritsenko wrote:
> Julius Davies wrote:
> ...
> > I had to explain that Commons-SSL just sits on top of the JSSE and JCE
> > to try and make working with SSL and Java easier. Your point about
> > the name is a good one.
>
> The counterpoint to name argument. Just single example, I'm sure there are many
> more: commons-logging sits on top of log4j/java logger/logkit/... and tries to
> make working with all them seamless.
>
> commons-ssl may be not the best name but it isn't terribly bad either.
>
> Vadim
>

Folks,

What about Commons-SSLUtils? This name seems consistent with already
existent Commons projects (DBUtils)

Julius,

Since "what-some-day-might-become-commons-ssl" is partially based on
some little bits of code I wrote, you can safely add me to the initial
list of committers. I will not be able to do a lot in terms of coding,
given my HttpComponents commitments, but I could help by doing some code
reviews once in a while and participating in design decisions.

Cheers,

Oleg


> ...
>
> > On 12/1/06, Roland Weber wrote:
> >>
> >> The working title "Commons-SSL" does not really reflect this. Do you
> >> plan to implement the SSL protocol as part of the project? Probably
> >> not, so the title is misleading. An all-encompassing name might also
> >> be offensive to people working on other SSL-related projects. I think
> >> you should spend the time and define not only a motto, but a very clear
> >> scope of the project. Both in terms of what's in scope as well as what's
> >> out of scope. From there on, we can work on finding a name and home.
> >>
> >> Please do not underestimate the importance of this step. Finding a
> >> name may seem like a minor detail, but the problem of defining the
> >> scope is very real. Only a few months ago, there was a long discussion
> >> on this list about a proposal for "testing.apache.org". I haven't read
> >> anything about it anymore after the supporters realized that a scope of
> >> "everything that has to do with testing" was overly broad. We don't
> >> want to see that happen to your proposal.
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: PROPOSAL: commons-ssl -> commons-sslutils?

------=_Part_8814_6354200.1165011230151
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 12/1/06, Oleg Kalnichevski wrote:
>
> On Fri, 2006-12-01 at 15:20 -0500, Vadim Gritsenko wrote:
> > Julius Davies wrote:
> > ...
> > > I had to explain that Commons-SSL just sits on top of the JSSE and JCE
> > > to try and make working with SSL and Java easier. Your point about
> > > the name is a good one.
> >
> > The counterpoint to name argument. Just single example, I'm sure there
> are many
> > more: commons-logging sits on top of log4j/java logger/logkit/... and
> tries to
> > make working with all them seamless.
> >
> > commons-ssl may be not the best name but it isn't terribly bad either.
> >
> > Vadim
> >
>
> Folks,
>
> What about Commons-SSLUtils? This name seems consistent with already
> existent Commons projects (DBUtils)


Calling it Commons-anything presupposes where it would land up after
incubation. That's not something that we should be doing, as the final
resting place of an incubated project is not determined until incubation has
successfully completed.

On the other hand, I think SSLUtils would be a fine name to run with.

--
Martin Cooper


Julius,
>
> Since "what-some-day-might-become-commons-ssl" is partially based on
> some little bits of code I wrote, you can safely add me to the initial
> list of committers. I will not be able to do a lot in terms of coding,
> given my HttpComponents commitments, but I could help by doing some code
> reviews once in a while and participating in design decisions.
>
> Cheers,
>
> Oleg
>
>
> > ...
> >
> > > On 12/1/06, Roland Weber wrote:
> > >>
> > >> The working title "Commons-SSL" does not really reflect this. Do you
> > >> plan to implement the SSL protocol as part of the project? Probably
> > >> not, so the title is misleading. An all-encompassing name might also
> > >> be offensive to people working on other SSL-related projects. I think
> > >> you should spend the time and define not only a motto, but a very
> clear
> > >> scope of the project. Both in terms of what's in scope as well as
> what's
> > >> out of scope. From there on, we can work on finding a name and home.
> > >>
> > >> Please do not underestimate the importance of this step. Finding a
> > >> name may seem like a minor detail, but the problem of defining the
> > >> scope is very real. Only a few months ago, there was a long
> discussion
> > >> on this list about a proposal for "testing.apache.org". I haven't
> read
> > >> anything about it anymore after the supporters realized that a scope
> of
> > >> "everything that has to do with testing" was overly broad. We don't
> > >> want to see that happen to your proposal.
> >
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

------=_Part_8814_6354200.1165011230151--