The SSL libraries, code, and jars have been merged into master.
Please beat the hell out of it and let me know if anything's broken.
- Charlie
On Sat, Apr 28, 2012 at 3:40 PM, Charles Oliver Nutter
<head...@headius.com> wrote:
> 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
