4 ms·

Would it ever be possible to have a self-updating framework? As in, I use Rails to develop web applications. In the past months, I've had to painstakingly go b

Would it ever be possible to have a self-updating framework? As in, I use Rails to develop web applications. In the past months, I've had to painstakingly go back to every single app I've ever worked on, and manually update it in whatever minor way it needed updating. Now, I'm going to do that again. If you consider that I'm going to continue to build Rails applications, the number of apps I will have to update every time a security vulnerability comes out will be larger and larger. For a framework that prides itself on sane defaults, it doesn't seem quite sane to have to worry about taking down, updating, and then relaunching every app you ever had when one of these vulnerabilities come out. I don't mean updating a Rails 2.3 app to 3.2 automatically, just applying these security patches automatically, or prompting the user to do so. Our operating systems do it, our IDEs do it, our programs do it, why can't a framework? I'm not saying it would be easy, but I'm sick of having to be subscribed to these email groups just to start the manual process of fixing everything.

kmfrk 14y ago
I think it would have to be handled by the platform provider. Someone like Heroku could make it happen. Or you could set up a cron-like worker to perform a pip-review (https://github.com/nvie/pip-tools https://github.com/nvie/pip-tools) of sorts. I don't know if I like the idea of a single point of failure; whatever service pushes the update would have a big, fat Wile E. Coyote target on its back. I am currently trying to figure out something similar for a Django-based app at the moment. I include a version in the settings file that I plan on comparing against some sort of version array on a central website. If a new security update is available, a conditional notification will show up for admins, but they will still have to update somewhat manually - I can't set up a cron job to trigger the whole procedure, especially because it might wreck their service, depending on how it works.
- eggbrain 14y ago
  'I don't know if I like the idea of a single point of failure; whatever service pushes the update would have a big, fat Wile E. Coyote target on its back.' This is a solved problem though, right? Antivirus companies deal with this when they push out definition updates that render backdoors ineffective, and yet while they probably are targeted by the virus makers, they have been quite resilient.
  - jiggy2011 14y ago
    Not sure about the AV servers themselves but a common thing for malware to do is to MITM or rebind DNS entries so that AV software updates are served from the attackers server.
- michaelmior 14y ago
  Something like Gemnasium? https://gemnasium.com/ https://gemnasium.com/
  - kmfrk 14y ago
    That still doesn't automate the process, and there is no telling whether 1.0.1 is a small update or a security update. Having said that, I really want a service like this, and I wanted to make one for Python (PIP) at one point, but hopefully someone more competent will do it or has already. A different version notation is needed to know whether the version delta between your installation and the most recent contains vital security updates.
nobodysfool 14y ago
Web2py you can patch on the fly, and it is a full service framework similar to Rails. Of course, the issue with patching on the fly is that since there is no 'taking down, updating, relaunching' step, every request to your server has to re-process the same files over and over again. It's a trade off that you'd have to consider. Also, upgrading versions (at least from 2.2.x to 2.3.2) is just a matter of clicking the 'upgrade' button. The only issue with that is, you don't get an updated scaffolding, you'd have to recreate your app in new scaffolding, or replace pieces manually if you want that.
aidos 14y ago
Possibly, unfortunately there's every possibility that you'd end up patching up things that broke out of the blue just as frequently that way. Having said that I've never had problems with the having Linux automatically run the security patches for me.
- eggbrain 14y ago
  Agreed, there is a small possibility that the patching might break the app in a major way, but for the majority of apps (especially those developed by one person just for fun), the benefit of being patched will likely outweigh the chance that the app breaks. For those with larger organizations and larger apps, it would be the same process that big companies do whenever a windows operating system patch comes out: they test, test, test, and once they are sure the update will work ok, they deploy the patch.
jarin 14y ago
Yep, there is a pretty easy way to do it. In your Gemfile, put: gem "rails", "~>3.2.0" Then when there's an update, run: bundle update rails Edit: fixed the gem directive
- eggbrain 14y ago
  That assumes you know about the vulnerability, though. If you aren't subscribed to an email group, you might not find out for some period of time. The majority of Rails programmers, or beginners even, aren't a part of these email groups, so they might leave vulnerable code up on their servers indefinitely -- not good. It might be better to have a cronjob that nightly runs the bundle update command, then restart the server. But again, this depends on you being smart enough to realize this, which since we are talking about sane defaults, isn't something we might want to assume.
  - deleted 14y ago
    [deleted]
  - jarin 14y ago
    It's probably a good idea to subscribe to rails-security. https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security https://groups.google.com/forum/?fromgroups#!forum/rubyonrai... I probably wouldn't allow a production app to update itself without human intervention.
    - eggbrain 14y ago
      The whole issue is that Rails has tried to package what's 'probably a good idea' into the framework by default for quite a while. Unless every guide ever tells you to subscribe to the rails-security group, only those 'in the know' will know to do so. What's better, to have access to these updates by default, or having half the Rails apps out there potentially being compromised?
- jlogsdon 14y ago
  You would really want to do gem 'rails', '~>3.2.0` otherwise you could get upgraded to '3.3' or '3.4' which is more likely to break something.
densh 14y ago
Stop installing latest shiniest things manually and start using default package manager of your linux distribution. Then all the security maintenance you will probably need is to do equivalent of "apt-get update; apt-get upgrade" once in a while. Yes, it was that easy before all these people who knew better came and decided that they really need latest ruby installed via rvm, latest gems etc. All these ruby/rails deployment "best practices" stroke me as advice given by people who had close to zero experience of maintaining a mission-critical application for a large period of time.
- lengarvey 14y ago
  And this common refrain is the shrill cry of someone who hasn't had to manage a Ruby on Rails application. Application libraries are the domain of the developer, not operations. Your job is to give me a stable system for me to deploy on top of, not to dictate what I can and cannot deploy. Rubygems and bundler makes updating your application stupidly easy. I blogged about it here: http://bottledup.net/2013/01/10/bundler-and-gemfile/ http://bottledup.net/2013/01/10/bundler-and-gemfile/ but if you have a good Gemfile and automated CI then all you need to do is `bundle update rails` and then deploy your code. This is at least as easy as using apt to update your stuff.
- tptacek 14y ago
  This is the worst possible option and I strongly recommend you minimize your dependencies on your OS package manager; if possible, build your web server from source too. You need to be prepared at all times to deploy workarounds to newly disclosed security problems. Package managers can and do delay fixes to accommodate the lowest common denominator of users. You cannot run a high profile application and be at the mercy of whoever is administrating your OS package manager.
  - stouset 14y ago
    While I usually agree with your advice, I think this approach, while theoretically correct, is actually damaging to the majority of your audience here. The closest analogy I can think of is that it's like requiring users to change passwords every 30 days: great in theory, but in practice it's a disaster. The problem is that it is simply untenable for all but the highest-profile sites. Finding good ops people, even in the bay area, is extremely hard. Most sites are only going to realize that a security update has been released when their package manager tells them it has, and updating that package is usually a 30s process. The companies I've seen have a hard enough time keeping track of security updates with package management. For a small to medium team with two, one, or even zero dedicated ops people, asking them to custom-compile (for example) a webserver, ruby implementation, and other critical libraries (openssl, glibc, etc.), subscribe to the relevant security mailing lists, and follow along with updates and security patches is tantamount to having them leave unpatched vulnerabilities on their systems for months or even years. If you ask your users to change passwords every 30 days, there are inevitably going to be a few who take it seriously and generate and remember secure passwords every single time. But the vast majority are going to use weaker passwords than they otherwise would have, and duplicate those passwords across accounts as much as they can figure out how. Likewise, if you ask already overworked ops guys to manually compile and keep track of security vulnerabilities for their webserver and dozens of libraries, a few are inevitably going to keep on top of things and release fixes minutes after vulnerabilities are announced. But the vast majority are going to simply give up after a month or two and be significantly worse off than if they just use Ubuntu's automatic security package updates.
eric970 14y ago
Welcome to the life of a software dev.
- oellegaard 14y ago
  *RoR software dev
jrochkind1 14y ago
> Would it ever be possible to have a self-updating framework? The problem is, with Rails, you'd never know when the self-updater would update you to a release that broke backwards compat and broke your app.
- altcognito 14y ago
  That's what regression and unit tests are for.
  - jiggy2011 14y ago
    Assuming you have perfect tests.. Still doesn't fix the fundamental problem though. Let's say you automatically install updates on a staging server and automatically deploy to production if all tests pass. What do you do when you're faced with a choice of deploying an app with a few failed tests (for perhaps not totally clear reasons) or leaving an old version up with a vulnerability?
    - altcognito 14y ago
      I missed this earlier. I think it's a good question and point about tests. More and more companies are relying on having good tests, but the situation you propose certainly can arise. It would be a technical and business decision at that point. What is the exposure? What is the risk? What is missing? How long would it take to replace it? What kind of PR do you want to send out. If I got a message that said -- hey, we know this feature is broken, but your security is more important to us, I probably would accept that as a customer.
millennia 14y ago
Rails does this already - bundle update (if gem version is set with ~>) You could easily automate this (cap,puppet,chef) if you have a lot of installs. If you genuinely don't want to test updates, you could run it on a schedule. What it doesn't do, and can't do, is guarantee that security updates will never break your app, but they do quite a good job of isolating them, you do have to do some testing. There is possibly an argument for lts releases which receive few new features and focus on bugs, but what you're complaining about here are really the complexities of running multiple web apps/servers, not something a framework can really help with. I don't think you have to worry about this update if you have already updated tho latest anyway (which you should have done if on 3.2.x).
jiggy2011 14y ago
Because you've built a ton of custom stuff on top of it that may be relying on various quirks or be designed around bad design decisions made in earlier versions. You will still get this problem with browsers also for example. The amount of times a firefox update has resulting in half of my plugins breaking.

kmfrk 14y ago

I think it would have to be handled by the platform provider. Someone like Heroku could make it happen. Or you could set up a cron-like worker to perform a pip-review (https://github.com/nvie/pip-tools https://github.com/nvie/pip-tools) of sorts. I don't know if I like the idea of a single point of failure; whatever service pushes the update would have a big, fat Wile E. Coyote target on its back. I am currently trying to figure out something similar for a Django-based app at the moment. I include a version in the settings file that I plan on comparing against some sort of version array on a central website. If a new security update is available, a conditional notification will show up for admins, but they will still have to update somewhat manually - I can't set up a cron job to trigger the whole procedure, especially because it might wreck their service, depending on how it works.

eggbrain 14y ago
'I don't know if I like the idea of a single point of failure; whatever service pushes the update would have a big, fat Wile E. Coyote target on its back.' This is a solved problem though, right? Antivirus companies deal with this when they push out definition updates that render backdoors ineffective, and yet while they probably are targeted by the virus makers, they have been quite resilient.
- jiggy2011 14y ago
  Not sure about the AV servers themselves but a common thing for malware to do is to MITM or rebind DNS entries so that AV software updates are served from the attackers server.
michaelmior 14y ago
Something like Gemnasium? https://gemnasium.com/ https://gemnasium.com/
- kmfrk 14y ago
  That still doesn't automate the process, and there is no telling whether 1.0.1 is a small update or a security update. Having said that, I really want a service like this, and I wanted to make one for Python (PIP) at one point, but hopefully someone more competent will do it or has already. A different version notation is needed to know whether the version delta between your installation and the most recent contains vital security updates.

nobodysfool 14y ago

Web2py you can patch on the fly, and it is a full service framework similar to Rails. Of course, the issue with patching on the fly is that since there is no 'taking down, updating, relaunching' step, every request to your server has to re-process the same files over and over again. It's a trade off that you'd have to consider. Also, upgrading versions (at least from 2.2.x to 2.3.2) is just a matter of clicking the 'upgrade' button. The only issue with that is, you don't get an updated scaffolding, you'd have to recreate your app in new scaffolding, or replace pieces manually if you want that.

aidos 14y ago

Possibly, unfortunately there's every possibility that you'd end up patching up things that broke out of the blue just as frequently that way. Having said that I've never had problems with the having Linux automatically run the security patches for me.

eggbrain 14y ago
Agreed, there is a small possibility that the patching might break the app in a major way, but for the majority of apps (especially those developed by one person just for fun), the benefit of being patched will likely outweigh the chance that the app breaks. For those with larger organizations and larger apps, it would be the same process that big companies do whenever a windows operating system patch comes out: they test, test, test, and once they are sure the update will work ok, they deploy the patch.

jarin 14y ago

Yep, there is a pretty easy way to do it. In your Gemfile, put: gem "rails", "~>3.2.0" Then when there's an update, run: bundle update rails Edit: fixed the gem directive

eggbrain 14y ago
That assumes you know about the vulnerability, though. If you aren't subscribed to an email group, you might not find out for some period of time. The majority of Rails programmers, or beginners even, aren't a part of these email groups, so they might leave vulnerable code up on their servers indefinitely -- not good. It might be better to have a cronjob that nightly runs the bundle update command, then restart the server. But again, this depends on you being smart enough to realize this, which since we are talking about sane defaults, isn't something we might want to assume.
- deleted 14y ago
  [deleted]
- jarin 14y ago
  It's probably a good idea to subscribe to rails-security. https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-security https://groups.google.com/forum/?fromgroups#!forum/rubyonrai... I probably wouldn't allow a production app to update itself without human intervention.
  - eggbrain 14y ago
    The whole issue is that Rails has tried to package what's 'probably a good idea' into the framework by default for quite a while. Unless every guide ever tells you to subscribe to the rails-security group, only those 'in the know' will know to do so. What's better, to have access to these updates by default, or having half the Rails apps out there potentially being compromised?
jlogsdon 14y ago
You would really want to do gem 'rails', '~>3.2.0` otherwise you could get upgraded to '3.3' or '3.4' which is more likely to break something.

densh 14y ago

Stop installing latest shiniest things manually and start using default package manager of your linux distribution. Then all the security maintenance you will probably need is to do equivalent of "apt-get update; apt-get upgrade" once in a while. Yes, it was that easy before all these people who knew better came and decided that they really need latest ruby installed via rvm, latest gems etc. All these ruby/rails deployment "best practices" stroke me as advice given by people who had close to zero experience of maintaining a mission-critical application for a large period of time.

lengarvey 14y ago
And this common refrain is the shrill cry of someone who hasn't had to manage a Ruby on Rails application. Application libraries are the domain of the developer, not operations. Your job is to give me a stable system for me to deploy on top of, not to dictate what I can and cannot deploy. Rubygems and bundler makes updating your application stupidly easy. I blogged about it here: http://bottledup.net/2013/01/10/bundler-and-gemfile/ http://bottledup.net/2013/01/10/bundler-and-gemfile/ but if you have a good Gemfile and automated CI then all you need to do is `bundle update rails` and then deploy your code. This is at least as easy as using apt to update your stuff.
tptacek 14y ago
This is the worst possible option and I strongly recommend you minimize your dependencies on your OS package manager; if possible, build your web server from source too. You need to be prepared at all times to deploy workarounds to newly disclosed security problems. Package managers can and do delay fixes to accommodate the lowest common denominator of users. You cannot run a high profile application and be at the mercy of whoever is administrating your OS package manager.
- stouset 14y ago
  While I usually agree with your advice, I think this approach, while theoretically correct, is actually damaging to the majority of your audience here. The closest analogy I can think of is that it's like requiring users to change passwords every 30 days: great in theory, but in practice it's a disaster. The problem is that it is simply untenable for all but the highest-profile sites. Finding good ops people, even in the bay area, is extremely hard. Most sites are only going to realize that a security update has been released when their package manager tells them it has, and updating that package is usually a 30s process. The companies I've seen have a hard enough time keeping track of security updates with package management. For a small to medium team with two, one, or even zero dedicated ops people, asking them to custom-compile (for example) a webserver, ruby implementation, and other critical libraries (openssl, glibc, etc.), subscribe to the relevant security mailing lists, and follow along with updates and security patches is tantamount to having them leave unpatched vulnerabilities on their systems for months or even years. If you ask your users to change passwords every 30 days, there are inevitably going to be a few who take it seriously and generate and remember secure passwords every single time. But the vast majority are going to use weaker passwords than they otherwise would have, and duplicate those passwords across accounts as much as they can figure out how. Likewise, if you ask already overworked ops guys to manually compile and keep track of security vulnerabilities for their webserver and dozens of libraries, a few are inevitably going to keep on top of things and release fixes minutes after vulnerabilities are announced. But the vast majority are going to simply give up after a month or two and be significantly worse off than if they just use Ubuntu's automatic security package updates.

eric970 14y ago

Welcome to the life of a software dev.

oellegaard 14y ago
*RoR software dev

jrochkind1 14y ago

> Would it ever be possible to have a self-updating framework? The problem is, with Rails, you'd never know when the self-updater would update you to a release that broke backwards compat and broke your app.

altcognito 14y ago
That's what regression and unit tests are for.
- jiggy2011 14y ago
  Assuming you have perfect tests.. Still doesn't fix the fundamental problem though. Let's say you automatically install updates on a staging server and automatically deploy to production if all tests pass. What do you do when you're faced with a choice of deploying an app with a few failed tests (for perhaps not totally clear reasons) or leaving an old version up with a vulnerability?
  - altcognito 14y ago
    I missed this earlier. I think it's a good question and point about tests. More and more companies are relying on having good tests, but the situation you propose certainly can arise. It would be a technical and business decision at that point. What is the exposure? What is the risk? What is missing? How long would it take to replace it? What kind of PR do you want to send out. If I got a message that said -- hey, we know this feature is broken, but your security is more important to us, I probably would accept that as a customer.

millennia 14y ago

Rails does this already - bundle update (if gem version is set with ~>) You could easily automate this (cap,puppet,chef) if you have a lot of installs. If you genuinely don't want to test updates, you could run it on a schedule. What it doesn't do, and can't do, is guarantee that security updates will never break your app, but they do quite a good job of isolating them, you do have to do some testing. There is possibly an argument for lts releases which receive few new features and focus on bugs, but what you're complaining about here are really the complexities of running multiple web apps/servers, not something a framework can really help with. I don't think you have to worry about this update if you have already updated tho latest anyway (which you should have done if on 3.2.x).

jiggy2011 14y ago

Because you've built a ton of custom stuff on top of it that may be relying on various quirks or be designed around bad design decisions made in earlier versions. You will still get this problem with browsers also for example. The amount of times a firefox update has resulting in half of my plugins breaking.