From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2206) id 8A1043858426; Tue, 5 Dec 2023 14:15:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A1043858426 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1701785741; bh=egrAbhaoJFaE44df5owiiWCzb+HqCGAqO/ELTcJa78o=; h=From:To:Subject:Date:From; b=P8erJtiqVTy1585sy/X4feEyPu7PtXoc4SJSaoED054oifk6rhJT8GAPEt4zRuSAN +qXwSWVsJiWr5zpQasJKKqsCsJYzzz4SmzRWRCKsWrWGnc5qD64oPlmVMJ2Ec9IngV nRmZeOmxkfiZtuyurjPZm35pA+Cmu1DRiPfT2K9g= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Siddhesh Poyarekar To: glibc-cvs@sourceware.org Subject: [glibc] Adapt the security policy for the security page X-Act-Checkin: glibc X-Git-Author: Siddhesh Poyarekar X-Git-Refname: refs/heads/master X-Git-Oldrev: 3f798427884fa57770e8e2291cf58d5918254bb5 X-Git-Newrev: f85722f9cdedde15c263753cbee0a705d2be67af Message-Id: <20231205141541.8A1043858426@sourceware.org> Date: Tue, 5 Dec 2023 14:15:41 +0000 (GMT) List-Id: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f85722f9cdedde15c263753cbee0a705d2be67af commit f85722f9cdedde15c263753cbee0a705d2be67af Author: Siddhesh Poyarekar Date: Tue Dec 5 09:14:06 2023 -0500 Adapt the security policy for the security page Call the document a "Security Policy" to disambiguate it from the security *process* documented in the security page. Also, point to the security page for bug reporting and CVE assignment. Signed-off-by: Siddhesh Poyarekar Diff: --- SECURITY.md | 61 ++++++++++++++----------------------------------------------- 1 file changed, 14 insertions(+), 47 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index a5f679f69b..e0f68f1ecb 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,9 +1,9 @@ -# The GNU C Library Security Process +# The GNU C Library Security Policy -This document describes the process followed by the GNU C Library maintainers +This document describes the policy followed by the GNU C Library maintainers to handle bugs that may have a security impact. This includes determining if a bug has a security impact, reporting such bugs to the community and handling -such bugs all the way to resolution. This process may evolve over time, so if +such bugs all the way to resolution. This policy may evolve over time, so if you're reading this from a release tarball, be sure to check the latest copy of the [SECURITY.md in the repository](https://sourceware.org/git/?p=glibc.git;a=blob;f=SECURITY.md), @@ -117,40 +117,13 @@ security vulnerability in itself. By their nature, these countermeasures are based on heuristics and will never offer complete protection, so the original vulnerability needs to be fixed anyway. -## Reporting private security bugs +## Reporting security bugs -**IMPORTANT: All bugs reported in Bugzilla are public.** - -As a rule of thumb, security vulnerabilities which are exposed over the network -or can be used for local privilege escalation (through existing applications, -not synthetic test cases) should be reported privately. We expect that such -critical security bugs are rare, and that most security bugs can be reported in -Bugzilla, thus making them public immediately. If in doubt, you can file a -private bug, as explained in the next paragraph. - -If you want to report a _private_ security bug that is not immediately -public, please contact _one_ of our downstream distributions with security -teams. The follow teams have volunteered to handle such bugs: - -* Debian: security@debian.org -* Red Hat: secalert@redhat.com -* SUSE: security@suse.de - -Please report the bug to _just one_ of these teams. It will be shared with -other teams as necessary. - -The team you contacted will take care of details such as vulnerability rating -and [CVE assignment](http://cve.mitre.org/about/). It is likely that the team -will ask to file a public bug because the issue is sufficiently minor and does -not warrant an embargo. An embargo is not a requirement for being credited -with the discovery of a security vulnerability. - -## Reporting public security bugs - -We expect that critical security bugs are rare, and that most security bugs can -be reported in Bugzilla, thus making them public immediately. When reporting -public security bugs the reporter should provide rationale for their choice of -public disclosure. +The process to report security bugs is documented on the glibc [security +page](https://sourceware.org/glibc/security.html). In general, most security +bugs may be reported publicly in the [glibc +bugzilla](https://sourceware.org/glibc/bugs.html), but if in doubt, please feel +free to report security issues privately first. ## Triaging security bugs @@ -196,14 +169,8 @@ the bug, the fix, or the mailing list discussions. ## CVE assignment -Security bugs flagged with `security+` should have [CVE identifiers](http://cve.mitre.org/about/). - -For bugs which are public (thus all bugs in Bugzilla), CVE assignment has to -happen through the [oss-security mailing -list](http://oss-security.openwall.org/wiki/mailing-lists/oss-security). -(Downstreams will eventually request CVE assignment through their public -Bugzilla monitoring processes.) - -For initially private security bugs, CVEs will be assigned as needed by the -downstream security teams. Once a public bug is filed, the name should be -included in Bugzilla. +Security bugs flagged with `security+` should have [CVE +identifiers](http://cve.mitre.org/about/). Please reach out to the glibc +security team using the documented [security +process](https://sourceware.org/glibc/security.html) and they work on getting a +CVE number.