71–80 of 98 posts
A tangent, but I always thought "YAML" was pronounced /'jæm.ḷ/, however the post's use of "an YAML" suggests it's actually pronounced /waɪ.eɪ.ɛm.ɛl/. Weird.
A tangent, but I always thought "YAML" was pronounced /'jæm.ḷ/, however the post's use of "an YAML" suggests it's actually pronounced /waɪ.eɪ.ɛm.ɛl/. Weird.
Earlier quoted context omitted.
bundle package puts all your app's dependencies in vendor/cache. That can then be put into a git submodule. The problem then becomes the Gemfile and Gemfile.lock, which should really be in that submodule as well. You need to pass flags to bundler commands because it assumes the Gemfile is in the project root.
I don't think Heroku's deploy is smart enough to recognize that you've packaged, right? It'll still try to bundle install, which would break in the current situation. I think a full solution requires packaging, and using a modified buildpack that skips the bundle step.
Places the gem binaries in vendor/cache, as noted. SCM those.
"While installing gems, Bundler will check vendor/cache and then your system's gems. If a gem isn't cached or installed, Bundler will try to install it from the sources you have declared in your Gemfile."
http://gembundler.com/bundle_install.html
Heroku uses this tree lookup AFAIK.
Earlier quoted context omitted.
The way we handle that for our Python deploys is to have a separate "deploy" git repo which includes complete .tar.gz files of all of our dependencies, then have our pip requirements.txt file point to those file paths rather than using external HTTP URLs. To avoid packages sneakily trying to download their own dependencies from the internet we run pip install with a "--proxy http://localhost:9999 argument (where noth…
We do something very similar, but like you said there are the occasional sneaky devils trying to download their own dependencies. Nine times out of ten it seems like it's some version of distribute that they insist on fetching. The non-existant proxy trick seems useful, I'll have to try that out.
Earlier quoted context omitted.
This is not that vulnerability. Their Rails is just fine. This is related to the fact that gems use YAML to store their metadata.
Semi related CVEs aside (CVE-2013-0333 and CVE-2013-0156): YAML's security problems have been known for years by the community. YAML aside, don't trust user input. This is egg on rubygems's face and the ruby community. I don't think http://rubycentral.org/ has full-time staff for rubygems either. Gems, specifically should be signed. They are not, this type of exploit will continue to happen, hell, remember when githu…
Earlier quoted context omitted.
I don't think Heroku's deploy is smart enough to recognize that you've packaged, right? It'll still try to bundle install, which would break in the current situation. I think a full solution requires packaging, and using a modified buildpack that skips the bundle step.
$ bundle package Places the gem binaries in vendor/cache, as noted. SCM those. "While installing gems, Bundler will check vendor/cache and then your system's gems. If a gem isn't cached or installed, Bundler will try to install it from the sources you have declared in your Gemfile." http://gembundler.com/bundle_install.html Heroku uses this tree lookup AFAIK.
UPDATE:
For others' edification, the default heroku ruby buildpack respects vendor/cache, but will purge it in the following scenarios:
* if vendor/ruby_version exists
* if vendor/heroku/buildpack_version exists, but vendor/heroku/ruby_version does not
* if the bundler cache exists, but vendor/heroku/ruby_version file specifies a different version of ruby than the one actually being used.Earlier quoted context omitted.
Sounds like a good reason to switch to "everything must be signed"
Just to reiterate the parent: This is only valuable if we trust the signatures - which I wouldn't if they were, say, just held along side the "hacked" gems server.
This should also be a reminder to everyone that you shouldn't be reliant on a single point of failure for your deploys. It's something that we in the Python community have already encountered (and hopefully learned from) due to the historical unreliability of our equivalent package repo, PyPI. Have an internal repo that's accessible by your deploy servers, which in turn locally caches anything that you might have pre…
That's a very good point to make. .NET developers, you can set up a similar cache for NuGet packages to avoid downtime (and reduce bandwidth usage): http://www.hanselman.com/blog/HowToAccessNuGetWhenNuGetorgIs...
Earlier quoted context omitted.
From a manager perspective, this sort of alert (as well as recent Heroku emails telling you specifically which app(s) needed patching for the recent Rails CVE issues) is a great example of one of the extra benefits of Heroku. A team of engineers 'watching your back' at no extra charge is a good thing.
Agreed. I was surprised when I received an email from Heroku letting me know that a few of my apps needed to be updated after the Rails vulnerabilities were uncovered. They also named the apps that needed to be updated, which makes my job that much simpler.
Earlier quoted context omitted.
That's a very good point to make. .NET developers, you can set up a similar cache for NuGet packages to avoid downtime (and reduce bandwidth usage): http://www.hanselman.com/blog/HowToAccessNuGetWhenNuGetorgIs...
Is bandwidth usage really a concern?