81–90 of 98 posts
Survey: Do you depend on RubyGems for every deploy? Or do you have your own gem server? Or cache them at some point earlier in your pipeline? We rely on RubyGems and had a meeting yesterday about changing that when one of the gems we use had a version just disappear.
Gems get yanked. Its a danger of this approach.
If you are not updating gems, does it hurt to continue deploying with a custom buildpack? Heroku shouldn't repull gems if the gemspec hasn't been altered. Is that logic correct? Does anybody have another suggestion for safely working around this issue? I don't have a clear sense for how long this will take to resolve and don't wish to slow down our release pace too much.
Survey: Do you depend on RubyGems for every deploy? Or do you have your own gem server? Or cache them at some point earlier in your pipeline? We rely on RubyGems and had a meeting yesterday about changing that when one of the gems we use had a version just disappear.
I was looking for a RubyGems proxy a couple of weeks ago but was unable to find anything suitable. What I would like to find is something similar to Artifactory for Maven. You include the proxy in your Gemfile and if it doesn't have the Gem it downloads it from RubyGems and caches it locally. This type of proxy wouldn't help in this particular case but it would allow you to keep traffic to RubyGems.org down and also…
You're probably aware, but it's possible to host private gems in a simple static webserver. We have our CI server copy gems over and run a script that calls "gem generate_index -d /path/to/gems".
Completely featureless, of course. Lacks the newer rubygems.org api (so bundler is stuck downloading the whole index), and obsolete versions will stick around without manual intervention (which, if you have too many, is a pathological case for bundler's resolver).
The DAY I manage to convince the big wigs where I work that we should switch from a typical shared environment to Heroku, this happens. Talk about luck. :( Hopefully I can spin this and not leave a bad taste in their mouths. We (engineers) understand what's happening, management doesn't and they don't give a shit.
So, whos is a few bugs? I has bet that DDT has crasehd his supr cool turboo charegd racecar and drived agin to proof his not afrid of anytang (DDT iz d a bomb). Yuse has a hng in ther an tell evbody how greta Rubby is.
Peepl will see, they is not stpid. Javacs is cowering in fear. Even Rubby bugs ar more scarier than ayn Javacs bugs!
(I membre frtsi time I saw a Rubby bug in my cdoe. IUt was a code smell bu t I kilt it wthi a desgn patren)
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…
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…
I only recently realized how easy it was to run your own PyPI - it just has to handle a few HTTP GET / POSTs. If you want to run your own PyPI internally, here's a very simple PyPI server (~150 lines of Python) that I wrote: https://github.com/steiza/simplepypi
What I've personally been looking for is an easy to setup caching proxy for PyPI. Something that is pip-compatible and serves files if it has them but will also fetch and then store packages if it doesn't. That way you could build up a collection of 3rd party packages over time, without having to explicitly manage it.
It probably wouldn't be hard to roll my own with a reverse proxy but it never gets moved to the front burner.
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.
You still wouldn't say "an why", as "w" isn't a vowel. If Anything, I can understand "an yamel" as more legitimate (as "y" is at least sort of a vowel).
What's more annoying: the odd (and wrong) belief that "An green apple" is grammatically correct. [1]
[0] http://english.stackexchange.com/questions/1016/do-you-use-a...
[1] http://english.stackexchange.com/questions/152/when-should-i...
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…
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…
I only recently realized how easy it was to run your own PyPI - it just has to handle a few HTTP GET / POSTs. If you want to run your own PyPI internally, here's a very simple PyPI server (~150 lines of Python) that I wrote: https://github.com/steiza/simplepypi