If a plone version is upgraded, should security patches be removed?
Hypothetical example:
Plone X.4.4 is running with Security Patch-XYZ from May 4th 2015
Plone is upgraded to X.4.5 which is released after Security Patch-XYZ
I assume the security patches are included in the next release. Should they be removed from our build?
Thanks.
In general, yes. There is one exception to date: the 20151006 hotfix, which is only partially included in Plone 4.3.9. See the hotfix notes for detail. The background is that this hotfix applies some very aggressive automated CSRF defenses that are not appropriate for all situations.
When in doubt, check the hotfix page or the full hotfix list.
In addition to Steve's answer: it is advised to remove the hotfixes from your buildout when the patches are included in core Plone, but when you forget this no breakage is expected. In most cases the worst that will happen is that you get a warning in the logs that a hotfix could not be cleanly applied.
Related
I've always published my .NET Core apps - both ASP.NET and Console apps - in "Self-Contained" mode. This is so I don't have to worry about installing anything on the servers. With a few dozen apps at about 70MB each, I'm re-thinking using Framework-Dependent instead.
My development machine has .NET Runtime 5.0.2, and that patch version (the third number) seems to update pretty often. If my server has .NET Runtime 5.0.0, will it always handle code built on a machine with 5.0.x? From what I've read, minor versions like 5.1 would require the server to be updated, but what about patch versions? Is there any reasonable possibility that my code wouldn't run properly if the server doesn't have the latest patch?
Or is it a "check the release notes every time" kind of deal?
Or is it a "check the release notes every time" kind of deal? This one. No one knows. The 5.0.2 resolved a denial of service on the kestrel server. It was a security fix. The 5.0.1 instead resolved various bugs in certain methods/libraries.
Clearly there is a small possibility that your code was leveraging a bug that is being fixed, and after the patch it will break (very very rarely it should happen. They are very careful about breaking changes). Or perhaps one day your code will break because something caused a rarely used piece of code that uses a buggy .NET method to run. Ah, the life of the programmer, always full of mystery and adventure 😀😁🤣
I was wondering if someone could help me sort this out.
Hotfix vs Patch vs Update.
I have look around the website but it only mentions about programs.
From what I understood,
Hotfix is to fix a certain bug and not always will be public announcement.
Patch is fixing few bugs and its public announcement.
Update is adding new content (as well as fixing bugs)
but isnt Patch used for new content as well?
I'm a bit confused with those terms
HotFix come in the form of a configuration change to workaround a problem or to fix a running application or server with minimal down time.
Patch is typically an update to existing code and delivered in binary form to fix a specific issue, bug or compatibility problems.
Updates can be used for enhancement or to bring an application up to date (and possibly contain multiple fixes rolled up).
We've recently had several hacks on our one server. We've been advised to upgrade all scripts. The problem is, the Drupal installations. Upgrading these are a massive task. I would like to know, out of fellow Drupal users, in your experience, how unsafe is it to remain on a say version 6.10 as apposed to upgrading 6.28 (the latest)? Is there a point at which you can say: this is really too old now and an upgrade is absolutely necessary?
I'm not too worried about the modules, my concern is the Core Drupal installation. Does it ever become a security risk, or can you stay on the older versions?
"Upgrading these are a massive task"
Not necessarily! I find using git a pretty safe way to deal with such upgrades.
My basic workflow is usually to:
- create a repository with the current Drupal version.
- download the latest core version
- rsync the current version with the latest core version
- update the repository
As expected, I do all of the above on my local version, after checking that everything is working fine. I update the remote repository, then update the actual live site from git.
If you're not familiar with git, basic tutorials are easy to find online. The idea here is not to explain the process in details, rather to send you in the right direction. You will find that it's a pretty flexible workflow, a great way to update modules and generally any type of code.
I've come across the following excellent blogpost on a git workflow model that works with release, develop, feature and bugfix branches: http://nvie.com/posts/a-successful-git-branching-model/
It sounds like an excellent workflow and I am really eager to try it in production but one paragraph caught my attention and leaves me wondering.
It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.
I'm wondering, how does this way of working reflect in your ticketing and bugtracking system? In JIRA and BugZilla we create "versions" that a ticket can belong to. Prior to switching to a release branch, what version does a ticket belong to when in the development branch? Do you have a version in your issuetracker for every branch?
And what about feature tickets that you know you are going to implement not in the upcoming release but in the release thereafter? Am I supposed to create a version "upcoming" and "future" for this kind of tickets?
Any insight in how this branching workflow reflects in ticket/issue management is appreciated!
Am I supposed to create a version "upcoming" and "future" for this kind of tickets
This is the basic idea. The key idea is that a current development will include some features part if the next release, and some which will ultimately be too complex and/or not ready in time and/or depending on other features which won't make it in said next release.
This is a bit like branches 'pu' and 'next' in the git repo itself.
In short, a feature ticket is rarely issued to a specific release number, while a bug fix ticket can be (2.1 for fixing release 2 for instance).
I did several websites with Drupal, and now the core is updated and I cannot come back to my customers to update previous installation. I was wondering how risky is to not update drupal core to the last version and how web developers should deal with websites management.
ps. My customers do not have any computer skills.
thanks
The openness of open source means that it is easy to know what an upgrade has fixed. It also means that a hacker could just look at the release notes and do a diff between the previous and current version to spot the vulnerabilities in the previous version.
If you have a good relationship with your clients I would explain the need for an upgrade and see if they want to pay you for it, as their sites are vulnerable to anyone determined enough to look at the release notes and do a little digging.
Here are release notes. Answer on your question lies inside.
Updating the core is very Important, it solves some security risks and brings new features.