That should be pretty easy to scale up. The past couple of weeks have established a decent precedent. Just have an endpoint called vuln_present or similar.

"return true;"

This actually sets up a single point of failure for many apps. If a hacker were to hack rails.org, they could take down any site polling it.

Well, not quite (when the messages are signed and the key is not stored on rails.org). However, as was pointed out, said attacker could indeed collect the ip-addresses of the polling servers - hence the idea to use twitter for the broadcast (a few comments down).

Of course Twitter is not exactly the most reliable platform but the likelihood of a twitter-downtime to coincide with a critical vulnerability seems relatively low.

You can set up a system like Debian or Ubuntu to automatically install security updates.

I want my rails instances to shutdown within minutes of an announcement, not hours or days.

Headline of the future:

> Tens of Thousands of Rails Applications Remotely Disabled Following Rails.org Intrusion

Yes, that is to be expected - and absolutely worth it.

The aftermath of an incident like the current one is a lot more expensive than an unplanned downtime.

Just playing devil's advocate here: a truly evil attacker could use the access logs from all the apps phoning home to build a list of vulnerable targets! :)

Well, you are right, the idea wasn't thought out very well. I was in a bit of a bad mood during patching up various rails deployments around here...

However, perhaps they could just promise to post a signed message, in a specified format, on a dedicated twitter account, if such a thing happens again. This would seem like a relatively low-tech approach, about adequate for such a rare event (just keep that secret key secret!).

The community can then roll their own gems to watch said twitter-account and act according to any user preference. Perhaps one of these gems would even make it into rails-core after sufficient review.

Obviously one can always argue whether such a rare case deserves dedicated infrastructure. But on the other hand we have yet to see how many rails deployments will be bitten by this incident in the long term. It's not uncommon to see years of exploitation for a vulnerability in a popular piece of server software.

Your entire thread of comments here make me want to gouge my eyes out. A signed message on twitter? Low tech? What in the hell are you talking about?

I'm going to be the asshole here, because it is vitally important that no one responsible for security ever listen to what you're saying. You're advocating some Orwellian kill-switch mechanism based on unspecified "signed messages" over a third-party social messaging service (limited to 140 chars, no less), and throwing in meaningless phrases like "low tech". What about this problem leads you to believe we all need something low tech?

I am not qualified to design such a system. You are negatively qualified to even comment on such a system. Please stop.

I'll try to put this more politely:

Since you apparently neither understand what was discussed (an optional rather than an "Orwellian" kill-switch), nor the implementation options (a signed message via any broadcast mechanism), nor why using twitter as the transport would be feasible and "low-tech" versus most alternatives, you should perhaps refrain from commenting on this thread at all. - And especially not in that tone.

That's the reason I do not publish a full list of Rails driven sites I have in my database at http://isItRails.com/

I'm guessing that might not work great considering last time I checked almost no one was using the debian packages due to antipathy between the debian maintainers and rubygems folks. Any know of any progress on that front?

I'm saying for Debian packages in general; I don't think anyone uses the Ruby packages in Debian/Ubuntu. It's a bit sad that people got in such a tizzy over it, because the Ruby people could learn a lot from Debian about packaging stuff and managing it over time.