Definition of "provides bindings" for OpenSSL

[Todd Lipcon <to...@apache.org>]

Hi all,

In Apache Kudu we're adding some code that uses the OpenSSL library for the
following purposes:
- Encryption of network traffic using TLS
- Generation of RSA public/private key pairs
- Signing of data using public/private keys

We won't ship OpenSSL libraries or source code, but we will #include
<ssl/ssl.h> and friends, and will require OpenSSL development
libraries/headers to be on the system at build time and runtime.

Based on my reading of https://www.apache.org/dev/crypto.html this means we
need to go through the notification process as outlined on that page. Is
that correct? I was hoping the FAQ would address this, but I found the
wording confusing:

> IF MY PROJECT SHIPS A BINARY THAT PROVIDES BINDINGS TO OPENSSL, BUT DOES
NOT INCLUDE ITS SOURCE OR BINARIES, WHAT NOTIFICATIONS MUST BE MADE?

"provides bindings" to me sounds like a library like Apache Commons Crypto
whose main purpose it is to wrap OpenSSL and "provide bindings" to some
downstream user who wants to use cryptographic functionality. But, maybe
it's meant to be interpreted as "binds against OpenSSL" or "dynamically
links against OpenSSL" which describes what we are doing.

Could someone please clarify?

Thanks
-Todd

-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Definition of "provides bindings" for OpenSSL

[Todd Lipcon <to...@apache.org>]

Having dug through various archives, it seems like "provides bindings"
means any kind of linkage with a crypto library like SSL. So, I'll just go
ahead and add Kudu to the ECCN matrix and go through the notification
process to unblock our dev work.

The suggestion to update the FAQ still stands, though, to save future
projects the confusion.

-Todd

On Mon, Oct 31, 2016 at 2:40 PM, Todd Lipcon <to...@apache.org> wrote:

> A related question: it seems that a lot of the projects listed on the
> Export List[1] are listing Java SE's JCE libraries as crypto software. If
> we use javax.net.ssl.* classes, do we need to also list Java as
> cryptographic software that we depend on?
>
> It looks like the export list is pretty inconsistent in this manner - eg
> Hadoop just lists its own source repository despite using Java SSL
> libraries. And HBase isn't listed at all despite supporting hosting SSL via
> a dependency on Jetty.
>
> One thought: if this stuff is important to get right, maybe it could be
> added to a tool like RAT? Or maybe on the "howto" page we can give some
> more clear "checklist" style directions, like:
>
> Does your software have a direct dependency on OpenSSL?
> Does your software have an indirect dependency on OpenSSL (eg via another
> library like libcurl?)
> Does your software have a direct dependency on Java SSL-related classes
> (eg javax.net.ssl.*)
> ... indirect dependency via a dependency on software like Tomcat, Jetty,
> etc
>
> I think that would be much more helpful than the somewhat vague
> descriptions on the page today, since 99% of projects probably fall into
> one of the above broad buckets rather than doing any of their own crypto
> implementation.
>
> -Todd
>
> [1] http://www.apache.org/licenses/exports/
>
> On Mon, Oct 31, 2016 at 12:47 PM, Todd Lipcon <to...@apache.org> wrote:
>
>> Hi all,
>>
>> In Apache Kudu we're adding some code that uses the OpenSSL library for
>> the following purposes:
>> - Encryption of network traffic using TLS
>> - Generation of RSA public/private key pairs
>> - Signing of data using public/private keys
>>
>> We won't ship OpenSSL libraries or source code, but we will #include
>> <ssl/ssl.h> and friends, and will require OpenSSL development
>> libraries/headers to be on the system at build time and runtime.
>>
>> Based on my reading of https://www.apache.org/dev/crypto.html this means
>> we need to go through the notification process as outlined on that page. Is
>> that correct? I was hoping the FAQ would address this, but I found the
>> wording confusing:
>>
>> > IF MY PROJECT SHIPS A BINARY THAT PROVIDES BINDINGS TO OPENSSL, BUT
>> DOES NOT INCLUDE ITS SOURCE OR BINARIES, WHAT NOTIFICATIONS MUST BE MADE?
>>
>> "provides bindings" to me sounds like a library like Apache Commons
>> Crypto whose main purpose it is to wrap OpenSSL and "provide bindings" to
>> some downstream user who wants to use cryptographic functionality. But,
>> maybe it's meant to be interpreted as "binds against OpenSSL" or
>> "dynamically links against OpenSSL" which describes what we are doing.
>>
>> Could someone please clarify?
>>
>> Thanks
>> -Todd
>>
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Definition of "provides bindings" for OpenSSL

[Todd Lipcon <to...@apache.org>]

A related question: it seems that a lot of the projects listed on the
Export List[1] are listing Java SE's JCE libraries as crypto software. If
we use javax.net.ssl.* classes, do we need to also list Java as
cryptographic software that we depend on?

It looks like the export list is pretty inconsistent in this manner - eg
Hadoop just lists its own source repository despite using Java SSL
libraries. And HBase isn't listed at all despite supporting hosting SSL via
a dependency on Jetty.

One thought: if this stuff is important to get right, maybe it could be
added to a tool like RAT? Or maybe on the "howto" page we can give some
more clear "checklist" style directions, like:

Does your software have a direct dependency on OpenSSL?
Does your software have an indirect dependency on OpenSSL (eg via another
library like libcurl?)
Does your software have a direct dependency on Java SSL-related classes (eg
javax.net.ssl.*)
... indirect dependency via a dependency on software like Tomcat, Jetty, etc

I think that would be much more helpful than the somewhat vague
descriptions on the page today, since 99% of projects probably fall into
one of the above broad buckets rather than doing any of their own crypto
implementation.

-Todd

[1] http://www.apache.org/licenses/exports/

On Mon, Oct 31, 2016 at 12:47 PM, Todd Lipcon <to...@apache.org> wrote:

> Hi all,
>
> In Apache Kudu we're adding some code that uses the OpenSSL library for
> the following purposes:
> - Encryption of network traffic using TLS
> - Generation of RSA public/private key pairs
> - Signing of data using public/private keys
>
> We won't ship OpenSSL libraries or source code, but we will #include
> <ssl/ssl.h> and friends, and will require OpenSSL development
> libraries/headers to be on the system at build time and runtime.
>
> Based on my reading of https://www.apache.org/dev/crypto.html this means
> we need to go through the notification process as outlined on that page. Is
> that correct? I was hoping the FAQ would address this, but I found the
> wording confusing:
>
> > IF MY PROJECT SHIPS A BINARY THAT PROVIDES BINDINGS TO OPENSSL, BUT DOES
> NOT INCLUDE ITS SOURCE OR BINARIES, WHAT NOTIFICATIONS MUST BE MADE?
>
> "provides bindings" to me sounds like a library like Apache Commons Crypto
> whose main purpose it is to wrap OpenSSL and "provide bindings" to some
> downstream user who wants to use cryptographic functionality. But, maybe
> it's meant to be interpreted as "binds against OpenSSL" or "dynamically
> links against OpenSSL" which describes what we are doing.
>
> Could someone please clarify?
>
> Thanks
> -Todd
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>



-- 
Todd Lipcon
Software Engineer, Cloudera