Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby deploys temporarily disabled

status.heroku.com

Post reply on HN
Print view View original

51–60 of 98 posts

Re: Ruby deploys temporarily disabled

#51

Post by awj »

martingordon wrote: post #15

Between this hack and the recent Rails vulnerabilities, it seems like a perfect storm. I wonder if either the hack attempted to tamper with the Rails gems to catch late updaters or to remove the ability to use RubyGems to update to the latest versions and keep vulnerable sites vulnerable.

It more looks like this was a natural extension of (part of) the Rails vulnerabilities. People saw that YAML on Ruby has a giant gaping security hole in it and was commonly used to decode user-supplied data.

I would not be surprised if we see even more of this as people feel out all of the other places that YAML is used as a user-facing data interchange format.

Re: Ruby deploys temporarily disabled

#52

Post by Legion »

redeemedfadi wrote: post #43
scotje wrote: post #29

Earlier quoted context omitted.

If you use bundler, "bundle package" can help reduce or eliminate your dependency on external gem repositories. At least for deployments. I generally try to follow the "vendor everything" philosophy: http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-a...

I couldn't get through this whole article due to the dude in the corner staring at me... :-/

Not that this line of discussion is particularly constructive, but I agree. I'm not sure why someone would think a giant head staring at the reader is a good idea, but it's not.

On a 27" monitor, it's almost like a child sized head right up in your face. I can only imagine it being even worse on bigger screens.

Re: Ruby deploys temporarily disabled

#54

Post by profquail »

Pewpewarrows wrote: post #6

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...

Re: Ruby deploys temporarily disabled

#55

Post by aneth4 »

This is why you vendor gems, and the current accepted practice of not vendoring gems is dead wrong.

I've been chastised before in rails irc for this. I strongly believe the source of all depndencies possible should be in your repository.

Re: Ruby deploys temporarily disabled

#56

Post by pvh »

pardner wrote: post #53

Seems odd, however, that status.heroku.com lists the issue only on the development side, suggesting production apps are not affected? http://screencast.com/t/L36Hpx5dx

Running apps are not affected, but your ability to do development is. The threat vector affects app compilation, not app execution/scaling, which doesn't touch the tainted rubygems.org repositories.

Re: Ruby deploys temporarily disabled

#58

Post by tobych »

steiza wrote: post #47
Pewpewarrows wrote: post #6

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

We're trying out DjangoPyPI 2 to host our own PyPI. Seems very actively maintained, and works a treat, despite it being still early days.

http://djangopypi2.readthedocs.org/en/latest/

For now though we'll probably just create a new git repo with a folder full of source distros (tarballs and zips), as mentioned above.

Re: Ruby deploys temporarily disabled

#59

Post by acdha »

stock_toaster wrote: post #22
Pewpewarrows wrote: post #6

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…

> It's something that we in the Python community have already learned due to the historical unreliability of our equivalent package repo, PyPI. learned sounds a touch condescending to me for some reason. The python community has certainly run into it, but (anecdote time) in my experience people still often rely on pypi for their deploys (but use the --mirrors option to pip). Encountered may be more appropriate.

I read “learned“ as in “learned the hard way”, which definitely has a different feel

Re: Ruby deploys temporarily disabled

#60

Post by delano »

aneth4 wrote: post #55

This is why you vendor gems, and the current accepted practice of not vendoring gems is dead wrong. I've been chastised before in rails irc for this. I strongly believe the source of all depndencies possible should be in your repository.

That's how Maven works but to a fault. The huge dependency repo tends to bog down deployments/releases.

Today I use bundler but my solution back in the (java) day was to separate code releases from dependency releases (separate directories basically).

e.g.

    /path/2/project 
    /path/2/project-resources
Post reply on HN