Ok, I did a bit more research on the export restrictions regarding BouncyCastle.
According to the BouncyCastle site, BC is:
"approved classified under ECCN code 5D002 and approved for export
under License Exception TSU."
License exception TSU ("Technology and Software - unrestricted)
applies to software that is freely available on the internet, either
in "object code" or source form. The relevant legal paragraphs are
here:
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=59ee1d5eeb8f1d444ba88927fa1eaaff&rgn=div5&view=text&node=15:2.1.3.4.25&idno=15#15:2.1.3.4.25.0.1.13
I originally thought that TSU would mean we would have to notify the
US government that we're shipping BC, pursuant to Section 740.13.e.3,
"Notification requirement", but I had not seen this full document at
that point. Rereading it now, section 740.13.e applies to *source
code*, which we are obviously not shipping for BC. The compiled and
packaged libraries would fall under 740.13.d, "General Software Note:
mass market software".
So 740.13.d does not have notification requirements, but does make
mention of symmetric-key crypto exceeding 64 bits and additional
restrictions therein. However, it goes on to state that such software
would move from BC's classification of 5D002 which is what BC claims
they're classified under (as of 2007).
Ultimately we will want a lawyer to look at this, but BC's claimed
classification and export license exemption appear to indicate that we
would not have to license it (at least) and probably not even have to
notify the US government that we're shipping it.
This does bring up a logistical issue...there are folks who will not
want to touch a JRuby distribution with BC included, so it's likely
that we'll need to provide artifacts that omit BC completely. That
means we'll still ideally want as much as possible to function when BC
is not available.
At the moment, I believe I have the "builtin" version ready to go and
will merge it to master as a single squashed commit (for ease of
reversion if we decide to back off from this). It passes nearly all
openssl Ruby tests in 1.8 mode, and fails many (but seems to function
properly) in 1.9 mode.
I'll need help from openssl/crypto folks to clean up as many of the
remaining issues as possible.
- Charlie
On Fri, Apr 27, 2012 at 4:50 AM, Charles Oliver Nutter
<head...@headius.com> wrote:
> Ok, we need to discuss this a bit. I think it's time we rolled
> jruby-ossl (OpenSSL) directly into JRuby and maintained it there.
>
> There are many reasons why this will make life easier:
>
> * No requirement to install a gem to get SSL support, which is
> sometimes impossible of only SSL sources are available
> * Ability to use SSL without loading RubyGems. Less of a gain under
> 1.9 mode, which always has RubyGems loaded.
> * Fewer goofy issues and bug reports due to our stubbed-out versions
> not being fully functional and sometimes not properly intercepting SSL
> calls that need the gem.
>
> We originally did not include jruby-ossl in JRuby because we (and Sun,
> at the time) were concerned about us shipping crypto -- the
> BouncyCastle libraries as part of JRuby proper. I've done some
> research on the exportability of BouncyCastle, and all signs
> (including BC's site and the US government's sites on the subject)
> seem to indicate that because BC is open-source and freely available,
> all we need to do is notify the US government of our intention to ship
> it as part of JRuby. So I think it's time we bit the bullet.
>
> I will handle contacting US gov't folks to confirm this, but in the
> meantime I've created the builtin_ssl branch (on github/headius/jruby)
> that folds jruby-ossl code back into JRuby proper. It appears to be
> passing tests.
>
> Thoughts? Concerns?
>
> - Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
