New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[UX] Auto Updates for security/modules #414
Comments
I'm interested in this functionality also, but yes, it's going to take a lot of effort and planning to do properly. After "Drupalgeddon" with the SQL injection attack hijacking sites within 7 hours of release, it's a great example of how manual updates just don't cut it any more with large pieces of web software, any more than attacks against popular browsers or operating systems. There's a bit of relevant discussion over in #395, but only loosely. I'd love to take a look at the Wordpress auto-update model and how well that is working for them. |
I'm conflicted about this. I like the idea of auto-updates, but also worry about 1) php being able to write it's own files (isn't that a huge risk?) and 2) breaking things in contrib by updating core. 2 will be a bigger risk for us than with Drupal 7 since we may be doing things like adding modules to core. If you had link module from contrib and are running 1.0.0 and in 1.2.0 we added link module to core, and in 1.2.2 we had a major security fix, auto updating you to 1.2.2 might cause a ton of problems. Would we also need to maintain a 1.0.x with the same security fix as 1.2.2 to prevent this from happening? Possible, but more work. |
I'm conflicted as well about it, but at the same time, it is helpful for those smaller sites that may not be maintained as regularly as other large sites. Over at d.o there are different thoughts and ideas being kicked around: https://www.drupal.org/node/2367319 As far as the core bringing in modules, I could foreseeably see us saying that we support up to three minor versions pack with security patches or something similar to that. And then each site would have the ability to chose how they update like gems and bundler. You can select whether to update to major, minor, or patch version through a I think the level of security issue something like the "drupalgeddon" bug would warrant a patch to minor versions, lets say 3 minor versions back, which seems like it would be quite significant. As far as PHP writing files, I think it depends on the host you are on, doesn't the update module allow for this currently? |
@quicksketch, @jenlampton and I talked for a while about this today at Twin Cities Drupal Camp sprints. Its a problem I've been working on, on and off, since I was introduced to Backdrop's philosophy at last year's camp. Especially when coupled with security-only releases of older Backdrop versions, making the technology seemed worthwhile. My approach has been to create a mostly-standalone web application that updates other web applications, vs. simply modifying/extending similar functionality already in Backdrop that installs and updates modules. The advantages of this are that it avoids potential complications with the updater being dependent on and loading things while they're getting updated, that if a given update totally broke a given site, the updater application itself is still usable, and that it becomes simpler to make the work applicable to other php applications. The work so far can be found at https://github.com/curator-wik. I call the app Curator. To clarify, the first problem I'm trying to solve is in-browser, user attended core updates, with automatic updates being a progression from there. But, some takeaways from today's discussion that ought to get noted on here:
Nate also brought up a bit of a thought experiment about what it would look like for Curator to self-update, especially if it was shipped as part of core and thus in some releases would be responsible for updating itself. Since Curator will be distributed as a single .phar file, it should be fairly simple to rapidly and cleanly switch from an old version to a new one. However, there was consensus that there should probably be a little special handling when a core update includes a Curator update, to ensure that the updater updates itself first, before attempting to apply the update to Backdrop. We talked quite a bit about what the input to Curator should be, e.g. a full .tgz of the new release vs some paired-down format that only contains the things that changed from one Backdrop release to another. The advantage of updating from a full .tgz is that there is less new infrastructure/release generation work necessary. The advantage of a paired-down format are that applying an update can be done more quickly by each site, by executing just the file overwrites/deletes necessary to make the old release source tree match the new release source tree rather than deleting the entire old core and then installing an entirely new one. Curator supports a paired-down format. I think I was at least reasonably successful at bringing Jen and Nate around to my way of thinking that incorporating some automation to their release process that generates these paired-down packages might be worthwhile :) |
The concept of self or auto updates is obviously important and the approach sounds practical. Apart from that though I cannot comment on the plan or code: a bit high level for me. Will be happy to test when it is ready, and if it is already testable, will need instructions. |
Thank you @mbaynton for all the time and energy spent on this 👍 Basically what @docwilmot said: way beyond me, but do let me know when you need help with testing. |
For reference, Drupal is beginning to discuss a similar idea:
|
Moreover, content of such sites with low cost of ownership and maintaining also can be added automatically, or at least this server can generate(mining) some (any buzzwords can be placed here)coins. |
I wonder how this issue here fits into #2018 and its child issues. Is this also a sub-issue of the META, or should it be closed as duplicate? |
Could use feedback on UX and language: in the top right I would like to put date pickers so people can restrict the updates to a time window (like between 2AM and 5AM). current language:
|
|
I like @olafgrabienski's proposal. My suggestion based on that:
I kinda liked the "i.e." examples, but we could omit them if people find them too "technical". ...although this part of the admin UI is targeted towards technically-savvy people I guess. @serundeputy do you have a PR for this? |
@klonos PR is fortcoming. I have code but needs attention and <3. |
TODO:
|
So it leaves files that are no longer in the new version? If that's true then I guess we do need to remove core first somehow. I wonder how WP does it? I also seem to recall it has ability to roll back at some point (before db updates i imagine). |
I know lots of work has gone into this direction for doing your updates already, but this talk about deleting files and renaming files and needing to remove core have sucked me in :) You'd have to spin up a Drupal 7 site 😱 but you might want to take a gander at
Although the thing you can actually test drive today is Drupal 7, the entirety of the D7 specific code is like 150 lines; the rest lives in a .phar file that is application agnostic. It should be pretty easy to port to Backdrop. I'd do it myself but I was actually working on adding rollback capability as I saw these comments, so I'm otherwise engaged at the moment 😉 |
Oh! I also has docs and resources and goodies:
|
@mbaynton thanks; I took a brief glance at the things you have going on there, but I could not get quickly up to speed on it (a lot to digest) My current thinking is that i'm close with the api that already exists in Backdrop ... so it seems simpler to me to implement that way. I'm going to continue on that path ... others should give their opinions as well. The current PR is not ready for general testing (it doesn't quite work yet), but dropping this script here that eases some of the steps needed to get to a place that one can test: #!/usr/bin/env.bash¬
set -ex¬
git clone git@github.com:backdrop/backdrop.git 414automaticUpdates
cp 2289.patch 414automaticUpdates/
cp 2307.patch 414automaticUpdates/
cp .lando.yml 414automaticUpdates/
cd 414automaticUpdates/
git checkout 1.10.2
git apply 2289.patch
git apply 2307.patch
lando.dev start && lando.dev drush si --db-url=mysql://backdrop:backdrop@database/backdrop
lando.dev drush uli Run this in a clean directory and it will set up a testable backdrop environment that has the right patches and is ready to upgrade from When you are done with that environment (like maybe you want to test again) do a |
I have just tested upgrading 1.11.0 to 1.11.1 and it run smoothly 👍. Notes: Settings page (
|
...another question: I know that this ticket is about the backend work required to get automatic updates working, but why restrict the security updates only to core? A security update is a security update no matter what. Anyway, in the case we do want to enable automatic security updates for contrib projects too, then I think that we should:
|
@klonos Above, you mentioned the page I just noticed that the "Learn how" link points to the page "Backing up a site" on drupal.org. Indeed, I didn't find a similar page in the Backdrop documentation. Are you aware of such a page? (If not, I'd open a ticket with the suggestion to add one.) |
@olafgrabienski I could not find anything in https://backdropcms.org/user-guide, so by all means create a separate documentation issue. We will need to link to it from other pages too, like in update.php, where we say:
...in fact there are still many places in our codebase where we still link to d.org. We cannot possibly match the accumulated decades of documentation that's there. |
I added a screenshot of the proposed UI from the PR into the parent issue here. It looks like there are a bunch of assumptions there (like the ability to update to not-the-latest-version) that we haven't yet determined are possible. I also have some suggestions for language improvements, but I'm going to start on the single checkbox for "Enable core updates" and put those language changes in the PR for #3271. While working on #3271 It occurred to me that we should add a few other settings for the automatic updates (and these may qualify as feature additions on their own)
|
cross-posting from #3271 (comment) ...wondering if it would be a safer option to be renaming the old core and then extracting the update in its place. We'd then let the end user manually delete the backup of the old core. If they don't delete the old backups, worse that can happen is to run out of disk space (and given the size of core and the space offerings by hosting providers nowadays, that'd be rare). That's way safer than destructively deleting things. |
I believe it relies on the updater classes https://github.com/backdrop/backdrop/blob/1.x/core/includes/updater.inc. There is a backup function |
This PR probably needs to be updated to work with the code that was merged in #3271. We added the UI to enable manual updates, so this issue can focus just on adding the automatic part. |
Just subscribing to this nice discussion to include it under my radar. |
It still needs work and further feedback but I started reworking @serundeputy's PR from ~3 years ago here: Please help if interested 😅 |
An example of an email that Wordpress sends after an auto-update, for reference: SUBJECT:
BODY:
|
If we're doing auto-updates for sites, then I would be more comfortable if we also auto-backed up their db as well as part of the process. So I would like this email to also mention something along the lines of:
|
@laryn how do we test this? Is it for core only, or contrib projects as well? If would expect this to be a scenario to test:
What about core? How do we test that? Is this a scenario that should work?:
|
We've got a whole meta issue on things that we need before we can turn this on, including digital signatures on packages: #2018. (I think the signatures is getting close but it has stalled as well.) |
Yes, I didn't mean to imply that this was ready to go (or to take it over), just trying to keep it up to speed with core changes and hopefully keep it on the radar. @klonos I haven't changed any of the functionality from the initial PR and I think a lot of those questions are still to be answered. Right now it's in a very early form with few options or checks in place. As far as testing what is there now, here's a quick way:
I think doing this on an actual |
FTR, this is what the respective UI looks like in D9: |
To me, "Disabled" implies "Manual" so that could probably be consolidated. I would like to see 3 options personally, 4 at the most. "Automatic - Patch releases" doesn't mean anything to me so I would never use it. I can only guess a patch is a major bug fix that can't wait for the next release (a bug got through review and broke stuff for example), which I would personally lump in to run with security updates which are technically patches if I'm thinking about it right. One thought I've pondered for a while is if it's worth doing a diff on core files before an update? A long time ago, I played around with PHPBB and when updating their platform, it would scan all of the core files and tell you if any core files had manual changes performed and told you exactly which files did not match the old or new meaning they were modified by the user. It would even display the line mismatches in the GUI. There were several options to deal with those changes, but it's made me wonder if it would be worth it to have the updater (whether auto or manual) do a diff check to see if a core file has been modified by the end-user and then ask what to do about it before proceeding. This would mainly benefit those who add patches to core files but it adds another layer of break-proofing things. For what it's worth. Finally, what would it take to push updates instead of each site pinging for an update? I would think a site should still ping occasionally if it hasn't received anything from the server in a while, but if there is a major security update that rolls through (like the Drupal SQL one), sites will be notified of the update and instructed to updated instead of requesting if there is an update at pre-defined times that might open the window for exploitation. It would take some thought on the load-balancing side of things to offset how much is being pushed to prevent server load etc but I feel this would be a better solution long term. I would be OK if this route was only applied to security and "patch" updates. |
Not sure if there is an issue about this, but I think something strong that backdrop-issue could offer is auto updates for security issues etc.
Since there is semantic versioning, this could be used as a check.
There are obviously a lot of issues that are needing to be addressed here, but thought I would start the issue.
PR by @serundeputy: backdrop/backdrop#2307Revised by @laryn: backdrop/backdrop#3753
Part of META issue: #2018
The text was updated successfully, but these errors were encountered: