Answers.Body: <h2>Specific answer on patching CRM-19709 for 4.6.10</h2>
  
  <ul>
  <li>Go to the appropriate Github repo, <a href="https://github.com/civicrm/civicrm-core" rel="nofollow noreferrer">civicrm-core</a></li>
  <li>Select the branch you want to find a backported patch for, <a href="https://github.com/civicrm/civicrm-core/commits/4.6" rel="nofollow noreferrer">4.6</a></li>
  <li>Read the commit messages and find commit(s) you want to apply, <a href="https://github.com/civicrm/civicrm-core/commit/3a73760d967edab137fe8eae20fdf63967be9ecf" rel="nofollow noreferrer"><code>3a7376</code></a> and <a href="https://github.com/civicrm/civicrm-core/commit/67520196442e493ea1c6ddfcd4954d0f3c7ab3fe" rel="nofollow noreferrer"><code>675201</code></a></li>
  <li>Append <code>.patch</code> to those commit URLs: <a href="https://github.com/civicrm/civicrm-core/commit/3a73760d967edab137fe8eae20fdf63967be9ecf.patch" rel="nofollow noreferrer"><code>3a7376.patch</code></a>, <a href="https://github.com/civicrm/civicrm-core/commit/67520196442e493ea1c6ddfcd4954d0f3c7ab3fe.patch" rel="nofollow noreferrer"><code>675201.patch</code></a></li>
  <li>Try a <code>patch --dry-run</code> dry-run to see if the patches apply, in the order they were applied to the 4.6 branch.</li>
  <li>If that works (no errors), apply the patches by dropping the <code>--dry-run</code> option.</li>
  </ul>
  
  <p>To perform the actual patch, I tend to use <code>curl PATCHURL(S) | patch -p1</code>, so the command I'd use to test if the patches will apply will be:</p>
  
  <pre><code>curl \
    https://github.com/civicrm/civicrm-core/commit/67520196442e493ea1c6ddfcd4954d0f3c7ab3fe.patch \
    https://github.com/civicrm/civicrm-core/commit/3a73760d967edab137fe8eae20fdf63967be9ecf.patch \
  | patch -p1 --dry-run
  </code></pre>
  
  <p>Pulling patches directly from a URL saves a few steps, and means we don't end up with <code>abcdef.patch</code> left on disk after.</p>
  
  <p>Please see also my separate answer on how to avoid getting into this situation :)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-08T10:55:52.230Z
Answers.LastActivityDate: 2016-12-08T10:55:52.230Z
Answers.UserDisplayName: Chris Burgess
Answers.Body: <h2>General advice on patch-updating old releases</h2>
  
  <p>The recommended solution is to upgrade to the latest release in your series. Between <a href="https://civicrm.org/blog/yashodha/security-releases-4420-4610" rel="nofollow noreferrer">4.6.10 release date in Nov 2015</a> and time of this question, there have been multiple CiviCRM security releases. See <a href="https://civicrm.org/advisory" rel="nofollow noreferrer">https://civicrm.org/advisory</a> for the full list.</p>
  
  <p>As you're finding, patch updates are labour intensive, which is why we recommend upgrading to <a href="https://civicrm.org/versions" rel="nofollow noreferrer">a supported release</a>. </p>
  
  <p>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.</p>
  
  <h3>How do people get here?</h3>
  
  <p>The need to backport fixes may indicate -</p>
  
  <ul>
  <li>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..</li>
  <li>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.</li>
  <li>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. </li>
  </ul>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-08T12:50:25.627Z
Answers.Text: thank you @Chris, i have been applying the security patches and plan to upgrade soonest
Answers.UserDisplayName: Kboy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-08T10:58:34.910Z
Answers.LastActivityDate: 2016-12-08T11:09:37.297Z
Answers.LastEditDate: 2016-12-08T11:09:37.297Z
Answers.UserDisplayName: Chris Burgess
Body: <p>After receiving the security announce, i have been trying to apply the patch given here <a href="https://civicrm.org/advisory/civi-sa-2016-23-unescaped-html-in-entity-reference-fields" rel="nofollow noreferrer">CIVI-SA-2016-23</a> but had this error message <code>patch -p1 &lt; 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).
  </code></p>
  
  <p>Can <a href="https://github.com/civicrm/civicrm-core/pull/9482/files" rel="nofollow noreferrer">this patch</a> also be used for version 4.6? because the <a href="https://issues.civicrm.org/jira/browse/CRM-19709" rel="nofollow noreferrer">reference Issue CRM-19709</a> says affected version is 4.7 and affected versions in security annouce are</p>
  
  <ol>
  <li>4.7.13 and earlier</li>
  <li>4.6.23 and earlier</li>
  </ol>
  
  <p>Maybe I'm doing something wrong, i am using <a href="https://civicrm.stackexchange.com/questions/4622/how-do-i-apply-a-patch-supplied-in-the-issue-queue-via-git">this procedure</a> to apply the patch.</p>
  
  <p>I'm on Civicrm 4.6.10.</p>
  
Tags: <security-advisory>
Title: Is this the correct patch for CiviCRM version 4.6 here CIVI-SA-2016-23?
ThreadText: # Is this the correct patch for CiviCRM version 4.6 here CIVI-SA-2016-23?
  
  (Asked by: username_0 on 2016-12-08)
  
  After receiving the security announce, i have been trying to apply the patch given here [CIVI-SA-2016-23](https://civicrm.org/advisory/civi-sa-2016-23-unescaped-html-in-entity-reference-fields) 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](https://github.com/civicrm/civicrm-core/pull/9482/files) also be used for version 4.6? because the [reference Issue CRM-19709](https://issues.civicrm.org/jira/browse/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](https://civicrm.stackexchange.com/questions/4622/how-do-i-apply-a-patch-supplied-in-the-issue-queue-via-git) to apply the patch.
  
  I'm on Civicrm 4.6.10.
  
  **Tags:** security-advisory
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-12-08. Score: 3 | Accepted answer
  
  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 :)
  
  
  ---
  
  ### Answer by username_1 on 2016-12-08. Score: 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](https://civicrm.org/blog/yashodha/security-releases-4420-4610) 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](https://civicrm.org/versions).
  
  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.
  
  > **Comments:**
  > **username_0**: thank you @Chris, i have been applying the security patches and plan to upgrade soonest  
  
  ---
  
  