opendev/gerrit
Code Issues Proposed changes

Document recommendations for making security fixes

Browse Source 
Reason for cherry-pick: pairs up with change I2a71b66a3f4b50aaa73.

Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: Iaaee4ad8e717a4e9c055cda2f064a3ad6f9cf7ce
(cherry picked from commit 0118c5d148)
This commit is contained in:
Edwin Kempin
2019-09-27 11:01:26 +02:00
committed by Gert van Dijk
parent fc1e0c84d2
commit 5854e87424
1 changed files with 25 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/intro-user.txt
View File

@@ -580,7 +580,8 @@ of cases:
from one device, and fetch to another device.
Do *not* use private changes for making security fixes (see
link:#private-changes-pitfalls[pitfalls] below).
link:#private-changes-pitfalls[pitfalls] below). How to make security
fixes is explained link:#security-fixes[below].
To create a private change, you push it with the `private` option.
@@ -961,6 +962,29 @@ In this case, Gerrit will persist a change message ("Thanks, I'll fix it."),
a file comment ("Rename this file to File.java") as well as a reply to an
inline comment ("Yeah, I see why, let me try again.").
[[security-fixes]]
-- Security Fixes
If a security vulnerability is discovered you normally want to have an
embargo about it until fixed releases have been made available. This
means you want to develop and review security fixes in private.
If your repository is public or grants broad read access it is
recommended to fix security issues in a copy of your repository which
has very restricted read permissions (e.g. `myproject-security-fixes`).
You can then implement, review and submit the security fix in this
repository, make and publish a new release and only then integrate the
security fix back into the normal (public) repository.
Alternatively you can do the security fix in your normal repository in
a branch with restricted read permissions. We don't recommend this
because there is a risk of configuring the access rights wrongly and
unintentionally granting read access to the wrong people.
Using private changes for security fixes is *not* recommended due to
the link:#private-changes-pitfalls[pitfalls] discussed above.
Especially you don't want the fix to become visible after submit and
before you had a chance to make and publish a new release.
GERRIT
------