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:
>>
>> https://github.com/LouHenryAlvarez/jackbox
>>
>> 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+unsubscr...@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.
