The problem with wordpress auto updates is that the webserver user must have write access to the code base, which is an inherently insecure configuration and is strongly discouraged. See https://www.drupal.org/node/244924 . For example with #drupalsa05 many attacks tried to plant evil PHP files somewhere besides the Drupal core files, which is not possible if you have locked down your permissions.

https://www.drupal.org/node/2367319 is the new discussion for an auto updater, maybe with drush?

The question of webserver having access to codebase is not simple. First there is the balance of harm. For general users balance of harm favours allowing auto-updates, for professionals users, Drupal would use the WP concept of allowing this to be turned off in code (in settings.php).

I think auto updates will add a huge benefit to Drupal. Recently when Drupalgeddon came up, many people and agencies had panic as they need to update all their sites at the same time somehow. This could be avoided with update automation. Due to the workflow may Drupal shops have, I agree that updating a live site with an auto update feature is not a good idea. But what if we let our continuous integration platform like Jenkins add the updates to a feature branch of the git repository, notify the development team that there are new updates (after the automatic tests for the project have been passed), create a ticket automatically in your project's task tool and if the ticket is closed, deploy the update feature branch to live and merge it back to the dev and stage branch in the repository. With this process we have updates applied as soon as they are available and we have the quality ensurance passed.
We implemented this recently with an integration to our internal ERPAL installation and it was possible to run all updates automatically within a couple of hours after the security update was released. I am wondering if there is no other way to do this but I am sure it will help Drupal to get even more trust and reliability.

I had the exact same thought to the main title ("...no").

but thinking further, it exposes another problem - updates should not break existing sites/apps.

Just imagine you lived ina world where firefox would break itself regularly - or even chrome. Both have automatic updates, and it would be crazy to expect either to break during an automatic update (though I am sure that must happen at some point). (lets not forget automatic updates of thw whole OS, which most people require)

WIth drupal there is the engineering aspect of automatic updates which can be overcome. but then there is a cultural aspect where either updates are expected to occasionally break sites (I hae experienced contrib updates incorrectly deleting content from the database...).

The culture can be changed but probably requires more engineering than the engineering aspect.

What about the economic model? We all earn money when your clients have to update. There is little incentive to break that money maker, there are plenty of support firms that have no problem with leveraging the fact that you need to keep your site up-to-date manually (without automatic updates) as a selling point of their services.

First off, I have really enjoyed some of your podcasts. Thank you!

I've thought a lot about updates and here are some wrinkles, info:

-One thing, the WP auto-update is minor releases only. Not major releases.

-There was a lot of WP developer fear when this was announced, but it has worked out well. There are very few issues.

-I took a look at the links suggested above about auto updates, file ownership and permissions. The idea seemed to be that auto updates are bad because you have to give Apache permission to write core files. While not a guru on this issue, I popped over to the WP codex to check. The info there says that when you do auto updates the files are owned by the user and not the web server. So, maybe there is a way to be safe and add these features.

http://codex.wordpress.org/Hardening_WordPress

-Besides the 'auto' update option, in Drupal we have the ability to manually update modules and themes from within admin, but not core. Your dad, for example, might be comfortable updating from within admin, while not by using FTP or drush.

Best regards

I will start by saying I am not qualified to speak of the technical requirements to make such a thing happen. However, as a user of the AEgir hosting system and Pantheon, I see how third parties (as opposed to core) could be leveraged to tackle the issue. AEgir has full control of the platform, mostly utilizing Drush, and can upgrade sites from Git repos manually with Drush Make. Seems like it could probably be built to automatically build a new platform and migrate a site under configured circumstances. Additionally, Pantheon had a fix ready to roll right away and all I had to do was click a button to deploy the patch. Seems like a great selling point for them to build some rules that would go ahead and push through security updates that meet configured criteria. Finally, both of these systems are capable of backing up the site before deployment. It seems a backup would be a key aspect of any such system.

Reading through the current conversation on d.o. there are some interesting points on file permissions and shared hosting. Seems like an auto update solution would be best suited for these scenarios, as automatic updates would most likely conflict with more robust deployment methods. Perhaps the communities efforts would be better suited towards working with shared hosts and helping them develop tools to make such a thing happen on their end? I realize there are thousands of shared hosts, but this would definitely be a defining factor in helping people find real "Optimized for Drupal" hosts.

So, a fundamental software security maxim is that software should not rewrite itself. Only the developer should modify the software, otherwise the software is exploitable to unknown lengths.

When you develop software, say websites/apps, then you are the responsible manager of the software not the software or whatever frameworks/libraries you built on. When those thing update, then it's up to you to use newer versions.

When we talk about Chrome, then the Chrome Dev Team is the developer, your computer is one of the servers, and you are the end-user. The relationship is perhaps the inverse of what you thought, but mirrors the relationship when you publish mobile apps.

Now, getting back to WP which has developed a solution for what I'll call the ProAm market. In that market users typically have a single instance of the production site, but maybe a development copy. These users may allow the web-server to modify the source, which allows for downloading plugins, themes, and updates.

The danger here is not that they can break they're site, of course they can do that. The danger is that an attacker can break their site. Theoretically, if an attacker found a vector, like SQL injection or XSS, they could convince the site to download an "update" from their malicious site, and rewrite source. It's such a danger, that professional sites typically leave a web app's source only write able to via their deployment automation software. Locking down the individual developers, who could themselves be compromised.

--

Anyway, my point is not that Drupal shouldn't do it, it is in fact a cool feature. My point is that it's no silver bullet for Drupaggedon.

Wordpress in general would be thought of as insecure, but for the most part, Wordpress websites run just fine. The auto update feature isn't perfect, but with incremental changes over time, they will have solved the security flaws. Drupal devs should stop being so scared and just work towards a solution. It doesn't have to auto update contrib plugins, but having a way to auto update and have it work, would save money in the long run. No more having to pay someone to apply an update. Although, you would still have to pay someone to test that the update didn't break anything. But there are many sites out there that it might not matter. I would like to see progress made to allow for auto updates, or at least, a better way of updating Drupal sites from the browser. We need to stop being so scared and come up with a solution.