How to generate my own patches to update core for security when fuerstnet.de's "Drupal upgrade the easy way" page is out of date? For Drupal 7, under the current host I'm using (which doesn't provide things like drush), I've found that patching is the easiest approach to updating core. However, the commonly-referenced page which provides the .patch files for doing this ("Drupal upgrade the easy way") has not updated for 7.67, which contains a security-fix.

Rather than go back to the old way of doing things by following all the steps found within UPGRADE.txt, what process can I use to generate a patch for upgrading my own site?
Per https://www.computerminds.co.uk/articles/quickly-update-drupal-core, Github itself can create patch-files for you. You can use commandline curl or wget to download the appropriate patch easily:

curl 'https://github.com/drupal/drupal/compare/7.66..7.67.patch' &gt; "drupal-7.66-to-7.67.patch"


Alternatively, you can download the tar'd (or zipped) packages for both your current version of Drupal and the target and recursively diff them as described here, resulting in a functionally-identical patch-file.

This can then be tested out in the normal way:

patch -p1 --dry-run &lt; "drupal-7.66-to-7.67.patch"


And then applied if no hunks failed:

patch -p1 &lt; "drupal-7.66-to-7.67.patch"


Note of course that just because patching succeeded, it doesn't mean the successfully-applied patch hasn't broken your site in some way, so be sure to  back up everything (files and Drupal database) before patching, trying this first on your dev site, running tests, etc. before repeating the process for real in production.

Gotcha!

If you've upgraded using fuerstnet.de before, Drupal may falsely continue showing security-update warnings, because at least one package with $file-&gt;info['project']=='drupal' and $project['project_type']=='core' will still be considered out of date. That's because some of your .info files may contain extra lines which override standard version-numbers:

; Information added by Drupal.org packaging script on 2019-04-17
version = "7.66"
project = "drupal"
datestamp = "1555533576"


Based off of experience, generating your own patch as described above will not remove this information, since it is not present in the vanilla packages, and the files containing these extra lines won't necessarily fail to patch either, if no changes to the vanilla editions' code occurred in the last update. (Common because .info files don't change very often.)

These extra lines need to be removed (or adjusted, if you prefer) before Drupal will stop complaining that you're behind on core updates, even though you're actually up-to-date.