1

After receiving the security announce, i have been trying to apply the patch given here CIVI-SA-2016-23 but had this error message patch -p1 < 9482.diff patching file CRM/Utils/API/AbstractFieldCoder.php Hunk #1 succeeded at 123 (offset -5 lines). patching file js/Common.js Hunk #1 succeeded at 445 (offset -15 lines). Hunk #2 FAILED at 639. Hunk #3 succeeded at 690 (offset -105 lines). Hunk #4 succeeded at 716 with fuzz 2 (offset -119 lines). Hunk #5 succeeded at 753 with fuzz 2 (offset -122 lines). Hunk #6 FAILED at 898. Hunk #7 FAILED at 1041. Hunk #8 succeeded at 968 (offset -184 lines).

Can this patch also be used for version 4.6? because the reference Issue CRM-19709 says affected version is 4.7 and affected versions in security annouce are

  1. 4.7.13 and earlier
  2. 4.6.23 and earlier

Maybe I'm doing something wrong, i am using this procedure to apply the patch.

I'm on Civicrm 4.6.10.

2 Answers 2

3

Specific answer on patching CRM-19709 for 4.6.10

  • Go to the appropriate Github repo, civicrm-core
  • Select the branch you want to find a backported patch for, 4.6
  • Read the commit messages and find commit(s) you want to apply, 3a7376 and 675201
  • Append .patch to those commit URLs: 3a7376.patch, 675201.patch
  • Try a patch --dry-run dry-run to see if the patches apply, in the order they were applied to the 4.6 branch.
  • If that works (no errors), apply the patches by dropping the --dry-run option.

To perform the actual patch, I tend to use curl PATCHURL(S) | patch -p1, so the command I'd use to test if the patches will apply will be:

curl \
  https://github.com/civicrm/civicrm-core/commit/67520196442e493ea1c6ddfcd4954d0f3c7ab3fe.patch \
  https://github.com/civicrm/civicrm-core/commit/3a73760d967edab137fe8eae20fdf63967be9ecf.patch \
| patch -p1 --dry-run

Pulling patches directly from a URL saves a few steps, and means we don't end up with abcdef.patch left on disk after.

Please see also my separate answer on how to avoid getting into this situation :)

2

General advice on patch-updating old releases

The recommended solution is to upgrade to the latest release in your series. Between 4.6.10 release date in Nov 2015 and time of this question, there have been multiple CiviCRM security releases. See https://civicrm.org/advisory for the full list.

As you're finding, patch updates are labour intensive, which is why we recommend upgrading to a supported release.

As the codebase to be patched (the 4.6.10 site) and the codebase the patch was made for (4.6.24) diverge, the odds of the patch applying cleanly are reduced. This can be an uncomfortable situation.

How do people get here?

The need to backport fixes may indicate -

  • A site is reluctant to upgrade because the CiviCRM codebase has been directly modified. Instead of customising CiviCRM directly by modifying the core code, we recommend customising via extensions, overrides, and the other interfaces CiviCRM provides for customisation..
  • A site is reluctant to upgrade because the upgrade might bring unexpected changes. This may be addressed through testing (automated or manual). Currently the CiviCRM community is discussing ways to make upgrading a more predictable process for sites.
  • A site may have opted to skip upgrades due to limited budget or resources, and now wants to track "bare minimal" updates for security only. This tends to increase the cost of maintenance over time.

Those are the most common underlying reasons sites find themselves having to backport fixes. These reasons may be valid, or they also might not apply to your instance at all, but I'm adding this additional answer in the hope that it helps some sites out there avoid the situation in question.

1
  • thank you @Chris, i have been applying the security patches and plan to upgrade soonest
    – Kboy
    Commented Dec 8, 2016 at 12:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.