Friday, December 26, 2014
On Friday, 26 December 2014 17:56:39 UTC-5, Matt Jones wrote:
On Sunday, 21 December 2014 15:55:26 UTC-5, Star Light wrote:If it's true. It sounds like some pretty wild stuff. Anyone care to comment about this?Followup to my original comment: the Github page only has specs. Rubygems has a gem, but it's got binary components without source and obfuscated source (RubyEncoder). I certainly wouldn't load this code anyplace that wasn't heavily sandboxed. I have no evidence that it's malicious, but have the same amount that it *isn't*.There's some interesting ideas in there, but nothing interesting enough that I'd want to bring un-debuggable, un-updatable mystery code in that also locks me to MRI.The barrage of "announcement" posts across rails-talk, ruby, ruby-dev, and ruby-core certainly haven't helped make a positive impression.
A final addon: the thing doesn't even WORK. Brand-new Ruby install on a brand-new Vagrant VM:
vagrant@precise32:~$ irb
irb(main):001:0> require 'jackbox'
TypeError: can't create instance of singleton class
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:188:in `new'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:188:in `block (2 levels) in decorate'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:51:in `suppress_warnings'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:179:in `block in decorate'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:208:in `[]'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:208:in `decorate'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox/examples/dir.rb:18:in `block in <class:Dir>'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox/examples/dir.rb:17:in `class_eval'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox/examples/dir.rb:17:in `<class:Dir>'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox/examples/dir.rb:15:in `<top (required)>'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:404:in `require_relative'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:404:in `<encoded>'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:2:in `RGLoader_load'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/jackbox-0.9.3.1/lib/jackbox.rb:2:in `<top (required)>'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:135:in `require'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
from /home/vagrant/.rbenv/versions/2.1.5/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:144:in `require'
from (irb):1
from /home/vagrant/.rbenv/versions/2.1.5/bin/irb:11:in `<main>'
---------------------------------------
System info:
vagrant@precise32:~$ ruby -v
ruby 2.1.5p273 (2014-11-13 revision 48405) [i686-linux]
vagrant@precise32:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04 LTS
Release: 12.04
Codename: precise
-------------------------------------
I'd add that EVEN IF THIS WORKED, it would be terrible - it's loading the file from lib/jackbox/examples/dir.rb, which redefines - ahem, "decorates" - methods of the stdlib Dir class to have entirely different semantics. For instance, `Dir.new(some_path)` now writes to the filesystem...
Some of the rest, on further examination, feels like over-abstraction / sugaring. For instance, here's how `lets` is implemented:
def lets(sym = nil, &block)
if sym.class == Symbol
define_method(sym, &block)
else
sym ? sym : block
end
rescue StandardError
raise LetsError
end
(BTW: RubyEncoder just makes this harder, not impossible. Not even particularly difficult, once you get used to reading YARV bytecode. RubyVM::InstructionSequence.disasm FTW!)
Digging into this, the first example for `lets` is USELESS. `lets bar =->(arg){ arg * arg }` is actually parsed as `lets(bar = ->(arg){ arg * arg })`. This works, but `lets` does exactly fuckall since the actual local-variable-setting part is a side-effect of its argument.
Other fun things, in no particular order:
* attempting an install on Ruby 1.9.3 fails, since the gem was built expecting `byebug` to be available but that gem requires Ruby 2.0.0. The gemspec appears to be *attempting* to deal with this by including a conditional on RUBY_VERSION, but that code runs at gem-build time, not gem-load time. :(
* `with` appears to work by decorating `method_missing`, using `instance_exec` on the target, and then undecorating. Bonus points if you wondered what happens if the block exits the scope abnormally (via `raise` or `throw`).
* the directory example reimplements Dir.exists? to do exactly the same thing as the Ruby version, only in Ruby instead of C. This is unlikely to be a performance issue, but it makes one wonder why it was included at all.
* disassembly of the included libraries shows additional oddities - there are two Mach-O format libs (ext/jackbox/jackbox.so and ext/jackbox/jackbox.bundle) and a DLL, but no corresponding library for Linux. The OS X libraries also don't appear to DO anything - just FFI stubs and utility functions.
* I'll leave the detailed object-oriented theory criticisms to somebody who's passionate about it, but some of the examples seem like classic is-a / has-a reversals to my eye. A Spaceship isn't a fuel line, or a capsule - it HAS those things. Mixins seem like the exactly wrong choice for that case.
* there's a namespace whose purpose I'm still unclear on under Jackbox::Meta::Abstract and Jackbox::Meta::DSL. Neither of the latter have (at first inspection) any methods of interest.
* needless to say, thanks to the RubyEncoder non-security garbage, the gem doesn't even WORK on 2.2.0.
LHA, if you're reading this, you've got some interesting ideas. You need to work on packaging and presentation, though - shipping useless binary extensions and obfuscated source isn't going to endear you to many people. It would be a great deal easier to discuss these ideas without having to trawl through YARV disassembly.
--Matt Jones
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/f9156a84-6a9a-4d96-8d68-3e2628ea6373%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment