Why Bundler 1.1 will be much faster

Sure, I would definitely read and spread it.

Yes, I would be interested in that.

Also, why don't you do the recursive lookup internally instead of having bundler do several calls? It seems like performance would be strictly better because it saves network round trips.

I'd love to see it also

Which classic brute force Ruby solution was the right call, seeing as how Bundler (a) improves ad-hoc packaging dramatically and (b) has gained widespread adoption.

They did the simplest thing that could possibly work, and ended up delivering 65% solution; now they're iterating. The hard work was getting people to adopt Bundler in the first place.

I'd love to have git be a part of the solution here, really, any other solution would be awesome. Hit me up in #rubygems on IRC or email me (nick [at] quaran.to) and we can talk about it :)

There's another HN thread that says "Ruby's Marshal library is not quite as blatantly insecure as pickle..." http://news.ycombinator.com/item?id=813306.

I'd be willing to stake some money on a bet that they're going to regret the decision to build key Ruby infrastructure on Marshal, say, within 12 months.

Having said that, I cannot at this moment tell you how to take over a Ruby runtime with a malicious Marshal byte string.

AFAIK Marshal is pretty safe, it's not the most safe or reliable data transport BUT it is on everyone's machine who has Ruby, on all versions.

I'd much rather be using JSON but I was told Marshal or plaintext...I'll go with Marshal. :/

I don't know what the specific issue with pickle is, but ruby's Marshal format is pretty bulletproof at this point. It is a data only format with pretty strict verification of the stream as it builds the object tree.

Also, Marshal doesn't allow any kind of code to be included into the stream, so there is no ability for stream to perform remote code injection.

Marshal call back into Ruby for non-builtin types, but it does so by simply calling a method on the constant and passing either the raw Marshal data or a previous created object tree. This provides enough protection that there haven't been any reported cases of it being exploited and no know issues exist with it.

What about the old Marshal problems? I just played with Marshal on my rails console again and it seems it still encapsulates all sorts of implementation details. I haven't tried whether it's now compatible across Ruby versions, but I recall the Marshal format changed a few times, introducing incompatibility.

tl;dr: Why, oh why, Marshal, and not, say, JSON?

AFAIK, Ruby's Marshal only calls internal stuff like allocate and special Marshal methods (e.g. marshal_dump and marshal_load) on classes in the Marshal data. It doesn't even actually use new or initialize to create instances, and it doesn't go through methods to set up the object. So unless you have a class that overrides Marshal hooks or Ruby internals in an insecure way, it shouldn't allow arbitrary code execution (barring buffer overflows and the like that could allow arbitrary code execution from any function).

Basically, I'm not convinced Marshal is necessarily any more risky than something like YAML would be, even though it feels scarier. But I haven't done an extensive audit or anything — I just looked over the Marshal code a while back because I was curious what it was doing.

The RubyGems index needs a ton of work. It's definitely not ideal right now, this was the easiest thing we could do to get Bundler happier and speedier.

I would love to see a more apt-get like system where you cache things locally, but that has its own implications/difficulties as well.

Basically, it's hard to keep the time down from "gem push" to "gem install" if you go towards more distributed/delayed indexing systems...but I'm willing to compromise if it's way better.

That's a great question. I suppose they split it up into separate requests since downloading all of the dependencies at the same time might end up being slow and returning a lot of data, especially for something like Rails with a lot of dependencies. Or maybe separate requests was fast enough and a good trade off between speed/data and number of requests.

as you have seen in the article, bundler needs dependencies of all versions as it might have to deal with older releases. Building the whole dependency graph for all versions of a gem with many dependencies in itself will a) take a very long time and b) probably be huge - likely much bigger than the whole gem index that was downloaded up until 1.1. The time required for parsing those MB after MB of data of which most will be thrown away will quickly get significant.

Another option would be to query for all dependencies of a specific version of a gem. That would reduce the amount of data, but it would still mean more work for the server and it would produce a lot more data to cache (much of which would never be queried more than once)

With the currently applied method, only the data that's really required must be queried and it can easily be cached on the server side too.

I suspect its a question of server resources. Dependency analysis is bundler's job and its better to let thousands of cpus run the algorithm. This leaves rubygems.org to simply service simple queries quickly without much load even though it means there will be many queries as part of each bundle.

We could try more than one layer. At the time we wrote it (last summer) the Bundler guys wanted to just start with one layer.