Currently seeing the message “warning, you do not have the jruby-openssl
gem installed” every time you use jruby to do a gem installation leaves
a feeling of…hackishness.
Suggestion: since ruby-debug, rake, et all, are all pre-bundled, perhaps
it would be possible to bundle
jruby-openssl
gem as well, but only load it “on demand” (like when SSL is actually
used?)
That would be kind.
-r
On Thu, Aug 5, 2010 at 2:04 PM, Roger P. [email protected] wrote:
Currently seeing the message “warning, you do not have the jruby-openssl
gem installed” every time you use jruby to do a gem installation leaves
a feeling of…hackishness.
+1 – low-priority but I’ve also been meaning to look into this; it
seems
rather bizarre getting messages like:
$ jruby -S gem list --local jruby-openssl
*** LOCAL GEMS ***
jruby-openssl (0.6)
$ jruby script/console
config.gem: Unpacked gem jruby-openssl-0.6 in vendor/gems has no
specification file. Run ‘rake gems:refresh_specs’ to fix this.
Loading development environment (Rails 2.3.4)
…
JRuby limited openssl loaded. http://jruby.org/openssl
gem install jruby-openssl for full support.
Eh? I mean, seriously, wtf??
–
Hassan S. ------------------------ [email protected]
twitter: @hassan
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
I’m pretty sure the reason jruby-openssl is not bundled is a legal one
- the US has fairly retarded laws regarding exporting crypto software
outside the country … even when said software originated outside the
country.
On 6 August 2010 07:29, Hassan S. [email protected]
wrote:
*** LOCAL GEMS ***
Eh? I mean, seriously, wtf??
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Yup, this and the licensing are the two reasons we’re not comfortable
bundling BouncyCastle (the crypto libraries we use to implement SSL).
If someone wants to devote lawyer time to clearing up the stupid US
crypto export restrictions for us, we’d love to sort this stuff out
One thing we have slowly improved is how much functionality we can
support without BC in play, but we’ll probably never be able to do all
of it.
On Thu, Aug 5, 2010 at 4:36 PM, Wayne M. [email protected]
wrote:
specification file. Run ‘rake gems:refresh_specs’ to fix this.
  http://xircles.codehaus.org/manage_email
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Thu, Aug 5, 2010 at 4:29 PM, Hassan S.
[email protected] wrote:
specification file. Run ‘rake gems:refresh_specs’ to fix this.
Loading development environment (Rails 2.3.4)
…
JRuby limited openssl loaded. http://jruby.org/openssl
gem install jruby-openssl for full support.
Eh? I mean, seriously, wtf??
Yeah, that’s pretty ugly. The need to bundle jruby-ossl in every app
is at the very least annoying. I think we’d at least like to fix cases
like this where bundling/unpacking still acts oddly and doesn’t find
ossl.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Thu, Aug 5, 2010 at 10:36 PM, Wayne M. [email protected]
wrote:
I’m pretty sure the reason jruby-openssl is not bundled is a legal one
- the US has fairly retarded laws regarding exporting crypto software
outside the country … even when said software originated outside the
country.
Yeah I thought it was something like that. Or a clash with the licensing
terms of the SSL library
(bouncy castle) that Java uses and is at the core of jruby-openssl.
Yes, perhaps. The thing I worry about here is if a library is
insufficiently tested without jruby-ossl installed, it’s possible that
much later on it will fail. That’s a testing problem, perhaps, but
being silent in general about a missing library seems like it would
make it more likely people would forget when they don’t have it
installed.
We’re open to improvements here, though. The logic for this is all in
Ruby:
http://github.com/jruby/jruby/blob/master/lib/ruby/site_ruby/shared/jruby/openssl
Starting with the stub.rb file, which gets loaded when you require
‘openssl’.
On Sat, Aug 7, 2010 at 9:38 AM, Roger P. [email protected] wrote:
  http://xircles.codehaus.org/manage_email
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
A thoughts:
only display the warnings when somebody actually uses missing
functionality, not at require time.
Thanks.
Charles Nutter wrote:
Yup, this and the licensing are the two reasons we’re not comfortable
bundling BouncyCastle (the crypto libraries we use to implement SSL).
If someone wants to devote lawyer time to clearing up the stupid US
crypto export restrictions for us, we’d love to sort this stuff out
One option may be to have the one click installers install that gem at
install time. Thus avoiding the warning messages later, and hopefully
avoiding restrictions by not “distributing it with openssl” or what not.
In this point I am definitely no lawyer, but hey, some OSS does it like
that.
Hi all,
I’m not a lawyer, too!
On Sat, Aug 7, 2010 at 23:10, Charles Oliver N.
[email protected] wrote:
Yup, this and the licensing are the two reasons we’re not comfortable
bundling BouncyCastle (the crypto libraries we use to implement SSL).
If someone wants to devote lawyer time to clearing up the stupid US
crypto export restrictions for us, we’d love to sort this stuff out
Interesting. I’ve never thought about it that US export control is a
reason. Is it about “Cryptography”? Or something other than that?
JRuby OpenSSL does not implement “Cryptography” by itself (it uses JCE
and BC for that) so we can distribute it as a part of JRuby if it does
not include JCE (not included already, of course) and BC? Is there any
lawyer-minded person?
Anyway, we made BC out to its own gem from jruby-openssl gem (Version
0.7.1)
Half of jruby-openssl features requires BC jars (PKey, ASN1, X509,
PKCS7 and SSL) but rest features does not (Random, HMAC, BN, Digest
and Cipher). And the rest features works without installing BC gem.
I think I can reduce “jruby-openssl” warning if jruby can bundle
jruby-openssl (or just include as an ext to reduce rubygems loading
overhead?). Let me know if you need.
Regards,
// NaHi
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Mon, Aug 9, 2010 at 11:42 AM, Nick S. [email protected]
wrote:
On Mon, Aug 9, 2010 at 4:58 AM, NAKAMURA, Hiroshi [email protected] wrote:
Interesting. I’ve never thought about it that US export control is a
reason. Is it about “Cryptography”? Or something other than that?
It is entirely related to cryptography. Several of the algorithms that
BC implements are considered “strong cryptography” which the current
US export laws seek to keep out of the hands of “terrorists” and the
like. Of course it’s nonsense, because all these algorithms are freely
available through a million other channels.
If we had a lawyer on hand, (s)he might be able to tell us whether BC
actually poses an export problem, since it’s actually an off-shore
hosted project (Australia, I think) and we’re just re-packaging it. To
date, we have not had a legal resource that could clarify things for
us.
I think I can reduce “jruby-openssl” warning if jruby can bundle
jruby-openssl (or just include as an ext to reduce rubygems loading
overhead?). Let me know if you need.
My thoughts exactly. Now that we’ve moved bouncy-castle-jars to an
external dependency, we can bundle the jruby-ossl code in JRuby.
This is an excellent idea! If we could ship jruby-ossl directly in
JRuby and only provide the warning (as an error, really) when you hit
crypto stuff that requires BC, it may be the perfect compromise. We
should proceed to do that.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Mon, Aug 9, 2010 at 4:58 AM, NAKAMURA, Hiroshi [email protected]
wrote:
Interesting. I’ve never thought about it that US export control is a
PKCS7 and SSL) but rest features does not (Random, HMAC, BN, Digest
and Cipher). And the rest features works without installing BC gem.
I think I can reduce “jruby-openssl” warning if jruby can bundle
jruby-openssl (or just include as an ext to reduce rubygems loading
overhead?). Let me know if you need.
My thoughts exactly. Now that we’ve moved bouncy-castle-jars to an
external dependency, we can bundle the jruby-ossl code in JRuby.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Thu, Aug 12, 2010 at 2:21 PM, Charles Oliver N.
[email protected] wrote:
If we had a lawyer on hand, (s)he might be able to tell us whether BC
actually poses an export problem, since it’s actually an off-shore
hosted project (Australia, I think) and we’re just re-packaging it. To
date, we have not had a legal resource that could clarify things for
us.
The closest we got was that if we hosted the strong-crypto files on a
website that was registered and/or “certified” with the government,
we’d be ok. Exactly where we register this fact, I have no idea.
Not sure how hosting the files on rubygems.org gets around this (does
it just shift responsibility?).
/Nick
and Cipher). And the rest features works without installing BC gem.
crypto stuff that requires BC, it may be the perfect compromise. We
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Thu, Aug 12, 2010 at 3:00 PM, Nick S. [email protected]
wrote:
The closest we got was that if we hosted the strong-crypto files on a
website that was registered and/or “certified” with the government,
we’d be ok. Exactly where we register this fact, I have no idea.
Not sure how hosting the files on rubygems.org gets around this (does
it just shift responsibility?).
I don’t know that they’re doing anything special. The files are
actually hosted on rubygems.org-controlled servers, so legally I think
they’d need to register as providing those libraries…if BC actually
required registration (which is still pretty fuzzy to me).
At any rate, it seems like it’s rubygems.org’s problem (perhaps
similar to any maven servers that have BC or other crypto stuff) and
if we just reduce our exposure by pushing BC libs as a gem, we may be
in OK shape.
I know we also talked about trying to implement more of jruby-ossl
using built-in crypto stuff that does ship with the JVM/JDK. Anything
we can do to reduce dependencies on BC will be a big help.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Hi Nick and Charles,
On Fri, Aug 13, 2010 at 04:21, Charles Oliver N.
[email protected] wrote:
If we had a lawyer on hand, (s)he might be able to tell us whether BC
actually poses an export problem, since it’s actually an off-shore
hosted project (Australia, I think) and we’re just re-packaging it. To
date, we have not had a legal resource that could clarify things for
us.
Thanks for the explanation. I understood. Let’s leave this issue as it
is now.
should proceed to do that.
Thanks for confirmation. I’ll create a ticket and a branch for the
migration.
- merge JRuby-OSSL repo to JRuby repo
- without BC jars inclusion
Please track the progress at the ticket I’ll create.
Regards,
// NaHi
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email