[PATCH v3 0/7] Documentation/security-bugs: overhaul

[PATCH v3 0/7] Documentation/security-bugs: overhaul

[Vegard Nossum]

Hi,

This is v3 of clarifying our documentation for reporting security
issues.

The current document is not clear enough, in particular the process of
disclosure and requesting CVEs, and what the roles of the different
lists are and how exactly to report to each of them.

Lots of people have been confused about the 7/14 days of the kernel list
vs. the 7/14 days of the distros list, the fact that these are two
separate lists, etc. Many reporters contact distros first, or submit
their report to both lists at the same time (which has the unfortunate
effect of starting off the disclosure countdown for the distros list
before s@k.o has had a chance to look at the report). I've shared the v2
document with a couple of people who submitted reports and they said
they found it a lot clearer. 

Probably the easiest way to see the end result of this series is to view the
rendered HTML which I've put here:
https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html

oss-security discussion prompting the change:
https://www.openwall.com/lists/oss-security/2022/05/15/1

v1 submission:
https://lore.kernel.org/all/20220531230309.9290-1-vegard.nossum@oracle.com/

v2 submission:
https://lore.kernel.org/all/20220606194850.26122-1-vegard.nossum@oracle.com/

Changes:

v2: address feedback from Willy Tarreau and Jonathan Corbet

v3: move from admin-guide/ to process/; address feedback from Will
Deacon (including reverting back to some of the original phrasing);
split into multiple patches


Vegard

Vegard Nossum (7):
  Documentation/security-bugs: move from admin-guide/ to process/
  Documentation/security-bugs: misc. improvements
  Documentation/security-bugs: improve security list section
  Documentation/security-bugs: add linux-distros and oss-security
    sections
  Documentation/security-bugs: add table of lists
  Documentation/security-bugs: clarify hardware vs. software
    vulnerabilities
  Documentation/security-bugs: document document design

 Documentation/admin-guide/index.rst           |   1 -
 .../admin-guide/reporting-issues.rst          |   4 +-
 Documentation/admin-guide/security-bugs.rst   |  96 ----------
 Documentation/process/howto.rst               |   2 +-
 Documentation/process/index.rst               |   9 +-
 .../process/researcher-guidelines.rst         |   2 +-
 Documentation/process/security-bugs.rst       | 181 ++++++++++++++++++
 Documentation/process/stable-kernel-rules.rst |   2 +-
 Documentation/process/submitting-patches.rst  |   2 +-
 .../it_IT/admin-guide/security-bugs.rst       |   2 +-
 .../it_IT/process/submitting-patches.rst      |   2 +-
 Documentation/translations/ja_JP/howto.rst    |   2 +-
 Documentation/translations/ko_KR/howto.rst    |   2 +-
 Documentation/translations/sp_SP/howto.rst    |   2 +-
 .../sp_SP/process/submitting-patches.rst      |   2 +-
 .../zh_CN/admin-guide/security-bugs.rst       |   2 +-
 .../translations/zh_CN/process/howto.rst      |   2 +-
 .../zh_TW/admin-guide/security-bugs.rst       |   2 +-
 .../translations/zh_TW/process/howto.rst      |   2 +-
 MAINTAINERS                                   |   4 +-
 20 files changed, 207 insertions(+), 116 deletions(-)
 delete mode 100644 Documentation/admin-guide/security-bugs.rst
 create mode 100644 Documentation/process/security-bugs.rst

-- 
2.40.0.rc1.2.gd15644fe02

[PATCH v3 1/7] Documentation/security-bugs: move from admin-guide/ to process/

[Vegard Nossum]

Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire
to move this document under process/.

Create a new section for security issues in the index and group it with
embargoed-hardware-issues.

I'm doing this at the start of the series to make all the subsequent
changes show up in 'git blame'.

Existing references were updated using:

  git grep -l security-bugs ':!Documentation/translations/' | xargs sed -i 's|admin-guide/security-bugs|process/security-bugs|g'
  git grep -l security-bugs Documentation/translations/ | xargs sed -i 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g'
  git grep -l security-bugs Documentation/translations/ | xargs sed -i '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g'

Notably, the page is not moved in the translations (due to my lack of
knowledge of these languages), but the translations have been updated
to point to the new location of the original document where these
references exist.

Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2206062326230.10851@cbobk.fhfr.pm/
Suggested-by: Jiri Kosina <jikos@kernel.org>
Cc: Alex Shi <alexs@kernel.org>
Cc: Yanteng Si <siyanteng@loongson.cn>
Cc: Hu Haowen <src.res@email.cn>
Cc: Federico Vaga <federico.vaga@vaga.pv.it>
Cc: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Jeimi Lee <jamee.lee@samsung.com>
Cc: Carlos Bilbao <carlos.bilbao@amd.com>
Cc: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 Documentation/admin-guide/index.rst                      | 1 -
 Documentation/admin-guide/reporting-issues.rst           | 4 ++--
 Documentation/process/howto.rst                          | 2 +-
 Documentation/process/index.rst                          | 9 ++++++++-
 Documentation/process/researcher-guidelines.rst          | 2 +-
 Documentation/{admin-guide => process}/security-bugs.rst | 0
 Documentation/process/stable-kernel-rules.rst            | 2 +-
 Documentation/process/submitting-patches.rst             | 2 +-
 .../translations/it_IT/admin-guide/security-bugs.rst     | 2 +-
 .../translations/it_IT/process/submitting-patches.rst    | 2 +-
 Documentation/translations/ja_JP/howto.rst               | 2 +-
 Documentation/translations/ko_KR/howto.rst               | 2 +-
 Documentation/translations/sp_SP/howto.rst               | 2 +-
 .../translations/sp_SP/process/submitting-patches.rst    | 2 +-
 .../translations/zh_CN/admin-guide/security-bugs.rst     | 2 +-
 Documentation/translations/zh_CN/process/howto.rst       | 2 +-
 .../translations/zh_TW/admin-guide/security-bugs.rst     | 2 +-
 Documentation/translations/zh_TW/process/howto.rst       | 2 +-
 MAINTAINERS                                              | 4 ++--
 19 files changed, 26 insertions(+), 20 deletions(-)
 rename Documentation/{admin-guide => process}/security-bugs.rst (100%)

diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 0ad7e7ec0d27..09a563bbe3e7 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -36,7 +36,6 @@ problems and bugs in particular.
 
    reporting-issues
    reporting-regressions
-   security-bugs
    bug-hunting
    bug-bisect
    tainted-kernels
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index ec62151fe672..2fd5a030235a 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -395,7 +395,7 @@ might want to be aware of; it for example explains how to add your issue to the
 list of tracked regressions, to ensure it won't fall through the cracks.
 
 What qualifies as security issue is left to your judgment. Consider reading
-Documentation/admin-guide/security-bugs.rst before proceeding, as it
+Documentation/process/security-bugs.rst before proceeding, as it
 provides additional details how to best handle security issues.
 
 An issue is a 'really severe problem' when something totally unacceptably bad
@@ -1269,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward
 the report's text to these addresses; but on top of it put a small note where
 you mention that you filed it with a link to the ticket.
 
-See Documentation/admin-guide/security-bugs.rst for more information.
+See Documentation/process/security-bugs.rst for more information.
 
 
 Duties after the report went out
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index cb6abcb2b6d0..deb8235e20ff 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -138,7 +138,7 @@ required reading:
     philosophy and is very important for people moving to Linux from
     development on other Operating Systems.
 
-  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
     If you feel you have found a security problem in the Linux kernel,
     please follow the steps in this document to help notify the kernel
     developers, and help solve the issue.
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index d4b6217472b0..565df595152e 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -35,6 +35,14 @@ Below are the essential guides that every developer should read.
    kernel-enforcement-statement
    kernel-driver-statement
 
+For security issues, see:
+
+.. toctree::
+   :maxdepth: 1
+
+   security-bugs
+   embargoed-hardware-issues
+
 Other guides to the community that are of interest to most developers are:
 
 .. toctree::
@@ -47,7 +55,6 @@ Other guides to the community that are of interest to most developers are:
    submit-checklist
    kernel-docs
    deprecated
-   embargoed-hardware-issues
    maintainers
    researcher-guidelines
 
diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst
index afc944e0e898..9fcfed3c350b 100644
--- a/Documentation/process/researcher-guidelines.rst
+++ b/Documentation/process/researcher-guidelines.rst
@@ -68,7 +68,7 @@ Before contributing, carefully read the appropriate documentation:
 * Documentation/process/development-process.rst
 * Documentation/process/submitting-patches.rst
 * Documentation/admin-guide/reporting-issues.rst
-* Documentation/admin-guide/security-bugs.rst
+* Documentation/process/security-bugs.rst
 
 Then send a patch (including a commit log with all the details listed
 below) and follow up on any feedback from other developers.
diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/process/security-bugs.rst
similarity index 100%
rename from Documentation/admin-guide/security-bugs.rst
rename to Documentation/process/security-bugs.rst
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 2fd8aa593a28..51df1197d5ab 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree
 
    Security patches should not be handled (solely) by the -stable review
    process but should follow the procedures in
-   :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.
+   :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
 
 For all other submissions, choose one of the following procedures
 -----------------------------------------------------------------
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index eac7167dce83..7b223f306efa 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -254,7 +254,7 @@ If you have a patch that fixes an exploitable security bug, send that patch
 to security@kernel.org.  For severe bugs, a short embargo may be considered
 to allow distributors to get the patch out to users; in such cases,
 obviously, the patch should not be sent to any public lists. See also
-Documentation/admin-guide/security-bugs.rst.
+Documentation/process/security-bugs.rst.
 
 Patches that fix a severe bug in a released kernel should be directed
 toward the stable maintainers by putting a line like this::
diff --git a/Documentation/translations/it_IT/admin-guide/security-bugs.rst b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
index 18a5822c7d9a..20994f4bfa31 100644
--- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst
+++ b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
@@ -1,6 +1,6 @@
 .. include:: ../disclaimer-ita.rst
 
-:Original: :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+:Original: :ref:`Documentation/process/security-bugs.rst <securitybugs>`
 
 .. _it_securitybugs:
 
diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
index c2cfa0948b2b..167fce813032 100644
--- a/Documentation/translations/it_IT/process/submitting-patches.rst
+++ b/Documentation/translations/it_IT/process/submitting-patches.rst
@@ -272,7 +272,7 @@ embargo potrebbe essere preso in considerazione per dare il tempo alle
 distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
 in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
 lista di discussione pubblica. Leggete anche
-Documentation/admin-guide/security-bugs.rst.
+Documentation/process/security-bugs.rst.
 
 Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
 essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga::
diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst
index 9b0b3436dfcf..8d856ebe873c 100644
--- a/Documentation/translations/ja_JP/howto.rst
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -167,7 +167,7 @@ linux-api@vger.kernel.org に送ることを勧めます。
     このドキュメントは Linux 開発の思想を理解するのに非常に重要です。
     そして、他のOSでの開発者が Linux に移る時にとても重要です。
 
-  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
     もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ
     のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を
     支援してください。
diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
index 969e91a95bb0..34f14899c155 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -157,7 +157,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.
     리눅스로 전향하는 사람들에게는 매우 중요하다.
 
 
-  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
     여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에
     나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록
     도와 달라.
diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
index f9818d687b54..f1629738b49d 100644
--- a/Documentation/translations/sp_SP/howto.rst
+++ b/Documentation/translations/sp_SP/howto.rst
@@ -135,7 +135,7 @@ de obligada lectura:
      de Linux y es muy importante para las personas que se mudan a Linux
      tras desarrollar otros sistemas operativos.
 
-  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
     Si cree que ha encontrado un problema de seguridad en el kernel de
     Linux, siga los pasos de este documento para ayudar a notificar a los
     desarrolladores del kernel y ayudar a resolver el problema.
diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst
index bf95ceb5e865..c2757d9ab216 100644
--- a/Documentation/translations/sp_SP/process/submitting-patches.rst
+++ b/Documentation/translations/sp_SP/process/submitting-patches.rst
@@ -276,7 +276,7 @@ parche a security@kernel.org. Para errores graves, se debe mantener un
 poco de discreción y permitir que los distribuidores entreguen el parche a
 los usuarios; en esos casos, obviamente, el parche no debe enviarse a
 ninguna lista pública. Revise también
-Documentation/admin-guide/security-bugs.rst.
+Documentation/process/security-bugs.rst.
 
 Los parches que corrigen un error grave en un kernel en uso deben dirigirse
 hacia los maintainers estables poniendo una línea como esta::
diff --git a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
index b8120391755d..d6b8f8a4e7f6 100644
--- a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
+++ b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
@@ -1,6 +1,6 @@
 .. include:: ../disclaimer-zh_CN.rst
 
-:Original: :doc:`../../../admin-guide/security-bugs`
+:Original: :doc:`../../../process/security-bugs`
 
 :译者:
 
diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst
index 10254751df6a..cc47be356dd3 100644
--- a/Documentation/translations/zh_CN/process/howto.rst
+++ b/Documentation/translations/zh_CN/process/howto.rst
@@ -125,7 +125,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
     这篇文档对于理解Linux的开发哲学至关重要。对于将开发平台从其他操作系
     统转移到Linux的人来说也很重要。
 
-  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
     如果你认为自己发现了Linux内核的安全性问题，请根据这篇文档中的步骤来
     提醒其他内核开发者并帮助解决这个问题。
 
diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
index eed260ef0c37..15f8e9005071 100644
--- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
+++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
@@ -2,7 +2,7 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :doc:`../../../admin-guide/security-bugs`
+:Original: :doc:`../../../process/security-bugs`
 
 :譯者:
 
diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
index 8fb8edcaee66..ea2f468d3e58 100644
--- a/Documentation/translations/zh_TW/process/howto.rst
+++ b/Documentation/translations/zh_TW/process/howto.rst
@@ -128,7 +128,7 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
     這篇文檔對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
     統轉移到Linux的人來說也很重要。
 
-  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
     如果你認爲自己發現了Linux內核的安全性問題，請根據這篇文檔中的步驟來
     提醒其他內核開發者並幫助解決這個問題。
 
diff --git a/MAINTAINERS b/MAINTAINERS
index b0db911207ba..ed84d41353a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -73,7 +73,7 @@ Tips for patch submitters
 	and ideally, should come with a patch proposal. Please do not send
 	automated reports to this list either. Such bugs will be handled
 	better and faster in the usual public places. See
-	Documentation/admin-guide/security-bugs.rst for details.
+	Documentation/process/security-bugs.rst for details.
 
 8.	Happy hacking.
 
@@ -18807,7 +18807,7 @@ F:	include/uapi/linux/sed*
 SECURITY CONTACT
 M:	Security Officers <security@kernel.org>
 S:	Supported
-F:	Documentation/admin-guide/security-bugs.rst
+F:	Documentation/process/security-bugs.rst
 
 SECURITY SUBSYSTEM
 M:	Paul Moore <paul@paul-moore.com>
-- 
2.40.0.rc1.2.gd15644fe02

Re: [PATCH v3 1/7] Documentation/security-bugs: move from admin-guide/ to process/

[Federico Vaga]

On 2023-03-05 23:00, Vegard Nossum wrote:
> Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire
> to move this document under process/.
> 
> Create a new section for security issues in the index and group it with
> embargoed-hardware-issues.
> 
> I'm doing this at the start of the series to make all the subsequent
> changes show up in 'git blame'.
> 
> Existing references were updated using:
> 
>   git grep -l security-bugs ':!Documentation/translations/' | xargs
> sed -i 's|admin-guide/security-bugs|process/security-bugs|g'
>   git grep -l security-bugs Documentation/translations/ | xargs sed -i
> 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g'
>   git grep -l security-bugs Documentation/translations/ | xargs sed -i
> '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g'
> 
> Notably, the page is not moved in the translations (due to my lack of
> knowledge of these languages), but the translations have been updated
> to point to the new location of the original document where these
> references exist.

Fine with me (Italian), I will move it later to the right place to 
reflect
the English version

Acked-by: Federico Vaga <federico.vaga@vaga.pv.it>

> diff --git
> a/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> index 18a5822c7d9a..20994f4bfa31 100644
> --- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> @@ -1,6 +1,6 @@
>  .. include:: ../disclaimer-ita.rst
> 
> -:Original: :ref:`Documentation/admin-guide/security-bugs.rst 
> <securitybugs>`
> +:Original: :ref:`Documentation/process/security-bugs.rst 
> <securitybugs>`
> 
>  .. _it_securitybugs:
> 
> diff --git
> a/Documentation/translations/it_IT/process/submitting-patches.rst
> b/Documentation/translations/it_IT/process/submitting-patches.rst
> index c2cfa0948b2b..167fce813032 100644
> --- a/Documentation/translations/it_IT/process/submitting-patches.rst
> +++ b/Documentation/translations/it_IT/process/submitting-patches.rst
> @@ -272,7 +272,7 @@ embargo potrebbe essere preso in considerazione
> per dare il tempo alle
>  distribuzioni di prendere la patch e renderla disponibile ai loro 
> utenti;
>  in questo caso, ovviamente, la patch non dovrebbe essere inviata su 
> alcuna
>  lista di discussione pubblica. Leggete anche
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
> 
>  Patch che correggono bachi importanti su un kernel già rilasciato, 
> dovrebbero
>  essere inviate ai manutentori dei kernel stabili aggiungendo la 
> seguente riga::

-- 
Federico Vaga

Re: [PATCH v3 1/7] Documentation/security-bugs: move from admin-guide/ to process/

[Carlos Bilbao]

On 3/5/23 16:00, Vegard Nossum wrote:
> Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire
> to move this document under process/.
> 
> Create a new section for security issues in the index and group it with
> embargoed-hardware-issues.
> 
> I'm doing this at the start of the series to make all the subsequent
> changes show up in 'git blame'.
> 
> Existing references were updated using:
> 
>    git grep -l security-bugs ':!Documentation/translations/' | xargs sed -i 's|admin-guide/security-bugs|process/security-bugs|g'
>    git grep -l security-bugs Documentation/translations/ | xargs sed -i 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g'
>    git grep -l security-bugs Documentation/translations/ | xargs sed -i '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g'
> 
> Notably, the page is not moved in the translations (due to my lack of
> knowledge of these languages), but the translations have been updated
> to point to the new location of the original document where these
> references exist.
> 
> Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2206062326230.10851@cbobk.fhfr.pm/
> Suggested-by: Jiri Kosina <jikos@kernel.org>
> Cc: Alex Shi <alexs@kernel.org>
> Cc: Yanteng Si <siyanteng@loongson.cn>
> Cc: Hu Haowen <src.res@email.cn>
> Cc: Federico Vaga <federico.vaga@vaga.pv.it>
> Cc: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
> Cc: Minchan Kim <minchan@kernel.org>
> Cc: Jeimi Lee <jamee.lee@samsung.com>
> Cc: Carlos Bilbao <carlos.bilbao@amd.com>
> Cc: Akira Yokosawa <akiyks@gmail.com>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>

Acked-by: Carlos Bilbao <carlos.bilbao@amd.com>

> ---
>   Documentation/admin-guide/index.rst                      | 1 -
>   Documentation/admin-guide/reporting-issues.rst           | 4 ++--
>   Documentation/process/howto.rst                          | 2 +-
>   Documentation/process/index.rst                          | 9 ++++++++-
>   Documentation/process/researcher-guidelines.rst          | 2 +-
>   Documentation/{admin-guide => process}/security-bugs.rst | 0
>   Documentation/process/stable-kernel-rules.rst            | 2 +-
>   Documentation/process/submitting-patches.rst             | 2 +-
>   .../translations/it_IT/admin-guide/security-bugs.rst     | 2 +-
>   .../translations/it_IT/process/submitting-patches.rst    | 2 +-
>   Documentation/translations/ja_JP/howto.rst               | 2 +-
>   Documentation/translations/ko_KR/howto.rst               | 2 +-
>   Documentation/translations/sp_SP/howto.rst               | 2 +-
>   .../translations/sp_SP/process/submitting-patches.rst    | 2 +-
>   .../translations/zh_CN/admin-guide/security-bugs.rst     | 2 +-
>   Documentation/translations/zh_CN/process/howto.rst       | 2 +-
>   .../translations/zh_TW/admin-guide/security-bugs.rst     | 2 +-
>   Documentation/translations/zh_TW/process/howto.rst       | 2 +-
>   MAINTAINERS                                              | 4 ++--
>   19 files changed, 26 insertions(+), 20 deletions(-)
>   rename Documentation/{admin-guide => process}/security-bugs.rst (100%)
> 
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 0ad7e7ec0d27..09a563bbe3e7 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -36,7 +36,6 @@ problems and bugs in particular.
>   
>      reporting-issues
>      reporting-regressions
> -   security-bugs
>      bug-hunting
>      bug-bisect
>      tainted-kernels
> diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
> index ec62151fe672..2fd5a030235a 100644
> --- a/Documentation/admin-guide/reporting-issues.rst
> +++ b/Documentation/admin-guide/reporting-issues.rst
> @@ -395,7 +395,7 @@ might want to be aware of; it for example explains how to add your issue to the
>   list of tracked regressions, to ensure it won't fall through the cracks.
>   
>   What qualifies as security issue is left to your judgment. Consider reading
> -Documentation/admin-guide/security-bugs.rst before proceeding, as it
> +Documentation/process/security-bugs.rst before proceeding, as it
>   provides additional details how to best handle security issues.
>   
>   An issue is a 'really severe problem' when something totally unacceptably bad
> @@ -1269,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward
>   the report's text to these addresses; but on top of it put a small note where
>   you mention that you filed it with a link to the ticket.
>   
> -See Documentation/admin-guide/security-bugs.rst for more information.
> +See Documentation/process/security-bugs.rst for more information.
>   
>   
>   Duties after the report went out
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index cb6abcb2b6d0..deb8235e20ff 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -138,7 +138,7 @@ required reading:
>       philosophy and is very important for people moving to Linux from
>       development on other Operating Systems.
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       If you feel you have found a security problem in the Linux kernel,
>       please follow the steps in this document to help notify the kernel
>       developers, and help solve the issue.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index d4b6217472b0..565df595152e 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -35,6 +35,14 @@ Below are the essential guides that every developer should read.
>      kernel-enforcement-statement
>      kernel-driver-statement
>   
> +For security issues, see:
> +
> +.. toctree::
> +   :maxdepth: 1
> +
> +   security-bugs
> +   embargoed-hardware-issues
> +
>   Other guides to the community that are of interest to most developers are:
>   
>   .. toctree::
> @@ -47,7 +55,6 @@ Other guides to the community that are of interest to most developers are:
>      submit-checklist
>      kernel-docs
>      deprecated
> -   embargoed-hardware-issues
>      maintainers
>      researcher-guidelines
>   
> diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst
> index afc944e0e898..9fcfed3c350b 100644
> --- a/Documentation/process/researcher-guidelines.rst
> +++ b/Documentation/process/researcher-guidelines.rst
> @@ -68,7 +68,7 @@ Before contributing, carefully read the appropriate documentation:
>   * Documentation/process/development-process.rst
>   * Documentation/process/submitting-patches.rst
>   * Documentation/admin-guide/reporting-issues.rst
> -* Documentation/admin-guide/security-bugs.rst
> +* Documentation/process/security-bugs.rst
>   
>   Then send a patch (including a commit log with all the details listed
>   below) and follow up on any feedback from other developers.
> diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/process/security-bugs.rst
> similarity index 100%
> rename from Documentation/admin-guide/security-bugs.rst
> rename to Documentation/process/security-bugs.rst
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index 2fd8aa593a28..51df1197d5ab 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree
>   
>      Security patches should not be handled (solely) by the -stable review
>      process but should follow the procedures in
> -   :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.
> +   :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
>   
>   For all other submissions, choose one of the following procedures
>   -----------------------------------------------------------------
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index eac7167dce83..7b223f306efa 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -254,7 +254,7 @@ If you have a patch that fixes an exploitable security bug, send that patch
>   to security@kernel.org.  For severe bugs, a short embargo may be considered
>   to allow distributors to get the patch out to users; in such cases,
>   obviously, the patch should not be sent to any public lists. See also
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>   
>   Patches that fix a severe bug in a released kernel should be directed
>   toward the stable maintainers by putting a line like this::
> diff --git a/Documentation/translations/it_IT/admin-guide/security-bugs.rst b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> index 18a5822c7d9a..20994f4bfa31 100644
> --- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> @@ -1,6 +1,6 @@
>   .. include:: ../disclaimer-ita.rst
>   
> -:Original: :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +:Original: :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>   
>   .. _it_securitybugs:
>   
> diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
> index c2cfa0948b2b..167fce813032 100644
> --- a/Documentation/translations/it_IT/process/submitting-patches.rst
> +++ b/Documentation/translations/it_IT/process/submitting-patches.rst
> @@ -272,7 +272,7 @@ embargo potrebbe essere preso in considerazione per dare il tempo alle
>   distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
>   in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
>   lista di discussione pubblica. Leggete anche
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>   
>   Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
>   essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga::
> diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst
> index 9b0b3436dfcf..8d856ebe873c 100644
> --- a/Documentation/translations/ja_JP/howto.rst
> +++ b/Documentation/translations/ja_JP/howto.rst
> @@ -167,7 +167,7 @@ linux-api@vger.kernel.org に送ることを勧めます。
>       このドキュメントは Linux 開発の思想を理解するのに非常に重要です。
>       そして、他のOSでの開発者が Linux に移る時にとても重要です。
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ
>       のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を
>       支援してください。
> diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
> index 969e91a95bb0..34f14899c155 100644
> --- a/Documentation/translations/ko_KR/howto.rst
> +++ b/Documentation/translations/ko_KR/howto.rst
> @@ -157,7 +157,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.
>       리눅스로 전향하는 사람들에게는 매우 중요하다.
>   
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에
>       나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록
>       도와 달라.
> diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
> index f9818d687b54..f1629738b49d 100644
> --- a/Documentation/translations/sp_SP/howto.rst
> +++ b/Documentation/translations/sp_SP/howto.rst
> @@ -135,7 +135,7 @@ de obligada lectura:
>        de Linux y es muy importante para las personas que se mudan a Linux
>        tras desarrollar otros sistemas operativos.
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       Si cree que ha encontrado un problema de seguridad en el kernel de
>       Linux, siga los pasos de este documento para ayudar a notificar a los
>       desarrolladores del kernel y ayudar a resolver el problema.
> diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst
> index bf95ceb5e865..c2757d9ab216 100644
> --- a/Documentation/translations/sp_SP/process/submitting-patches.rst
> +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst
> @@ -276,7 +276,7 @@ parche a security@kernel.org. Para errores graves, se debe mantener un
>   poco de discreción y permitir que los distribuidores entreguen el parche a
>   los usuarios; en esos casos, obviamente, el parche no debe enviarse a
>   ninguna lista pública. Revise también
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>   
>   Los parches que corrigen un error grave en un kernel en uso deben dirigirse
>   hacia los maintainers estables poniendo una línea como esta::
> diff --git a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> index b8120391755d..d6b8f8a4e7f6 100644
> --- a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> @@ -1,6 +1,6 @@
>   .. include:: ../disclaimer-zh_CN.rst
>   
> -:Original: :doc:`../../../admin-guide/security-bugs`
> +:Original: :doc:`../../../process/security-bugs`
>   
>   :译者:
>   
> diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst
> index 10254751df6a..cc47be356dd3 100644
> --- a/Documentation/translations/zh_CN/process/howto.rst
> +++ b/Documentation/translations/zh_CN/process/howto.rst
> @@ -125,7 +125,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
>       这篇文档对于理解Linux的开发哲学至关重要。对于将开发平台从其他操作系
>       统转移到Linux的人来说也很重要。
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       如果你认为自己发现了Linux内核的安全性问题，请根据这篇文档中的步骤来
>       提醒其他内核开发者并帮助解决这个问题。
>   
> diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> index eed260ef0c37..15f8e9005071 100644
> --- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> @@ -2,7 +2,7 @@
>   
>   .. include:: ../disclaimer-zh_TW.rst
>   
> -:Original: :doc:`../../../admin-guide/security-bugs`
> +:Original: :doc:`../../../process/security-bugs`
>   
>   :譯者:
>   
> diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
> index 8fb8edcaee66..ea2f468d3e58 100644
> --- a/Documentation/translations/zh_TW/process/howto.rst
> +++ b/Documentation/translations/zh_TW/process/howto.rst
> @@ -128,7 +128,7 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
>       這篇文檔對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
>       統轉移到Linux的人來說也很重要。
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       如果你認爲自己發現了Linux內核的安全性問題，請根據這篇文檔中的步驟來
>       提醒其他內核開發者並幫助解決這個問題。
>   
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b0db911207ba..ed84d41353a7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -73,7 +73,7 @@ Tips for patch submitters
>   	and ideally, should come with a patch proposal. Please do not send
>   	automated reports to this list either. Such bugs will be handled
>   	better and faster in the usual public places. See
> -	Documentation/admin-guide/security-bugs.rst for details.
> +	Documentation/process/security-bugs.rst for details.
>   
>   8.	Happy hacking.
>   
> @@ -18807,7 +18807,7 @@ F:	include/uapi/linux/sed*
>   SECURITY CONTACT
>   M:	Security Officers <security@kernel.org>
>   S:	Supported
> -F:	Documentation/admin-guide/security-bugs.rst
> +F:	Documentation/process/security-bugs.rst
>   
>   SECURITY SUBSYSTEM
>   M:	Paul Moore <paul@paul-moore.com>

Thanks,
Carlos

Re: [PATCH v3 1/7] Documentation/security-bugs: move from admin-guide/ to process/

[Akira Yokosawa]

On Sun,  5 Mar 2023 23:00:04 +0100, Vegard Nossum wrote:
> Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire
> to move this document under process/.
> 
> Create a new section for security issues in the index and group it with
> embargoed-hardware-issues.
> 
> I'm doing this at the start of the series to make all the subsequent
> changes show up in 'git blame'.
> 
> Existing references were updated using:
> 
>   git grep -l security-bugs ':!Documentation/translations/' | xargs sed -i 's|admin-guide/security-bugs|process/security-bugs|g'
>   git grep -l security-bugs Documentation/translations/ | xargs sed -i 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g'
>   git grep -l security-bugs Documentation/translations/ | xargs sed -i '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g'
> 
> Notably, the page is not moved in the translations (due to my lack of
> knowledge of these languages), but the translations have been updated
> to point to the new location of the original document where these
> references exist.
> 
> Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2206062326230.10851@cbobk.fhfr.pm/
> Suggested-by: Jiri Kosina <jikos@kernel.org>
> Cc: Alex Shi <alexs@kernel.org>
> Cc: Yanteng Si <siyanteng@loongson.cn>
> Cc: Hu Haowen <src.res@email.cn>
> Cc: Federico Vaga <federico.vaga@vaga.pv.it>
> Cc: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
> Cc: Minchan Kim <minchan@kernel.org>
> Cc: Jeimi Lee <jamee.lee@samsung.com>
> Cc: Carlos Bilbao <carlos.bilbao@amd.com>
> Cc: Akira Yokosawa <akiyks@gmail.com>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> ---
>  Documentation/admin-guide/index.rst                      | 1 -
>  Documentation/admin-guide/reporting-issues.rst           | 4 ++--
>  Documentation/process/howto.rst                          | 2 +-
>  Documentation/process/index.rst                          | 9 ++++++++-
>  Documentation/process/researcher-guidelines.rst          | 2 +-
>  Documentation/{admin-guide => process}/security-bugs.rst | 0
>  Documentation/process/stable-kernel-rules.rst            | 2 +-
>  Documentation/process/submitting-patches.rst             | 2 +-
>  .../translations/it_IT/admin-guide/security-bugs.rst     | 2 +-
>  .../translations/it_IT/process/submitting-patches.rst    | 2 +-
>  Documentation/translations/ja_JP/howto.rst               | 2 +-

For ja_JP part:
Reviewed-by: Akira Yokosawa <akiyks@gmail.com>

>  Documentation/translations/ko_KR/howto.rst               | 2 +-
>  Documentation/translations/sp_SP/howto.rst               | 2 +-
>  .../translations/sp_SP/process/submitting-patches.rst    | 2 +-
>  .../translations/zh_CN/admin-guide/security-bugs.rst     | 2 +-
>  Documentation/translations/zh_CN/process/howto.rst       | 2 +-
>  .../translations/zh_TW/admin-guide/security-bugs.rst     | 2 +-
>  Documentation/translations/zh_TW/process/howto.rst       | 2 +-
>  MAINTAINERS                                              | 4 ++--
>  19 files changed, 26 insertions(+), 20 deletions(-)
>  rename Documentation/{admin-guide => process}/security-bugs.rst (100%)
> 
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 0ad7e7ec0d27..09a563bbe3e7 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -36,7 +36,6 @@ problems and bugs in particular.
>  
>     reporting-issues
>     reporting-regressions
> -   security-bugs
>     bug-hunting
>     bug-bisect
>     tainted-kernels
> diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
> index ec62151fe672..2fd5a030235a 100644
> --- a/Documentation/admin-guide/reporting-issues.rst
> +++ b/Documentation/admin-guide/reporting-issues.rst
> @@ -395,7 +395,7 @@ might want to be aware of; it for example explains how to add your issue to the
>  list of tracked regressions, to ensure it won't fall through the cracks.
>  
>  What qualifies as security issue is left to your judgment. Consider reading
> -Documentation/admin-guide/security-bugs.rst before proceeding, as it
> +Documentation/process/security-bugs.rst before proceeding, as it
>  provides additional details how to best handle security issues.
>  
>  An issue is a 'really severe problem' when something totally unacceptably bad
> @@ -1269,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward
>  the report's text to these addresses; but on top of it put a small note where
>  you mention that you filed it with a link to the ticket.
>  
> -See Documentation/admin-guide/security-bugs.rst for more information.
> +See Documentation/process/security-bugs.rst for more information.
>  
>  
>  Duties after the report went out
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index cb6abcb2b6d0..deb8235e20ff 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -138,7 +138,7 @@ required reading:
>      philosophy and is very important for people moving to Linux from
>      development on other Operating Systems.
>  
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>      If you feel you have found a security problem in the Linux kernel,
>      please follow the steps in this document to help notify the kernel
>      developers, and help solve the issue.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index d4b6217472b0..565df595152e 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -35,6 +35,14 @@ Below are the essential guides that every developer should read.
>     kernel-enforcement-statement
>     kernel-driver-statement
>  
> +For security issues, see:
> +
> +.. toctree::
> +   :maxdepth: 1
> +
> +   security-bugs
> +   embargoed-hardware-issues
> +
>  Other guides to the community that are of interest to most developers are:
>  
>  .. toctree::
> @@ -47,7 +55,6 @@ Other guides to the community that are of interest to most developers are:
>     submit-checklist
>     kernel-docs
>     deprecated
> -   embargoed-hardware-issues
>     maintainers
>     researcher-guidelines
>  
> diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst
> index afc944e0e898..9fcfed3c350b 100644
> --- a/Documentation/process/researcher-guidelines.rst
> +++ b/Documentation/process/researcher-guidelines.rst
> @@ -68,7 +68,7 @@ Before contributing, carefully read the appropriate documentation:
>  * Documentation/process/development-process.rst
>  * Documentation/process/submitting-patches.rst
>  * Documentation/admin-guide/reporting-issues.rst
> -* Documentation/admin-guide/security-bugs.rst
> +* Documentation/process/security-bugs.rst
>  
>  Then send a patch (including a commit log with all the details listed
>  below) and follow up on any feedback from other developers.
> diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/process/security-bugs.rst
> similarity index 100%
> rename from Documentation/admin-guide/security-bugs.rst
> rename to Documentation/process/security-bugs.rst
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index 2fd8aa593a28..51df1197d5ab 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree
>  
>     Security patches should not be handled (solely) by the -stable review
>     process but should follow the procedures in
> -   :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.
> +   :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
>  
>  For all other submissions, choose one of the following procedures
>  -----------------------------------------------------------------
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index eac7167dce83..7b223f306efa 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -254,7 +254,7 @@ If you have a patch that fixes an exploitable security bug, send that patch
>  to security@kernel.org.  For severe bugs, a short embargo may be considered
>  to allow distributors to get the patch out to users; in such cases,
>  obviously, the patch should not be sent to any public lists. See also
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>  
>  Patches that fix a severe bug in a released kernel should be directed
>  toward the stable maintainers by putting a line like this::
> diff --git a/Documentation/translations/it_IT/admin-guide/security-bugs.rst b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> index 18a5822c7d9a..20994f4bfa31 100644
> --- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> @@ -1,6 +1,6 @@
>  .. include:: ../disclaimer-ita.rst
>  
> -:Original: :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +:Original: :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>  
>  .. _it_securitybugs:
>  
> diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
> index c2cfa0948b2b..167fce813032 100644
> --- a/Documentation/translations/it_IT/process/submitting-patches.rst
> +++ b/Documentation/translations/it_IT/process/submitting-patches.rst
> @@ -272,7 +272,7 @@ embargo potrebbe essere preso in considerazione per dare il tempo alle
>  distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
>  in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
>  lista di discussione pubblica. Leggete anche
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>  
>  Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
>  essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga::
> diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst
> index 9b0b3436dfcf..8d856ebe873c 100644
> --- a/Documentation/translations/ja_JP/howto.rst
> +++ b/Documentation/translations/ja_JP/howto.rst
> @@ -167,7 +167,7 @@ linux-api@vger.kernel.org に送ることを勧めます。
>      このドキュメントは Linux 開発の思想を理解するのに非常に重要です。
>      そして、他のOSでの開発者が Linux に移る時にとても重要です。
>  
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>      もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ
>      のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を
>      支援してください。
> diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
> index 969e91a95bb0..34f14899c155 100644
> --- a/Documentation/translations/ko_KR/howto.rst
> +++ b/Documentation/translations/ko_KR/howto.rst
> @@ -157,7 +157,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.
>      리눅스로 전향하는 사람들에게는 매우 중요하다.
>  
>  
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>      여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에
>      나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록
>      도와 달라.
> diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
> index f9818d687b54..f1629738b49d 100644
> --- a/Documentation/translations/sp_SP/howto.rst
> +++ b/Documentation/translations/sp_SP/howto.rst
> @@ -135,7 +135,7 @@ de obligada lectura:
>       de Linux y es muy importante para las personas que se mudan a Linux
>       tras desarrollar otros sistemas operativos.
>  
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>      Si cree que ha encontrado un problema de seguridad en el kernel de
>      Linux, siga los pasos de este documento para ayudar a notificar a los
>      desarrolladores del kernel y ayudar a resolver el problema.
> diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst
> index bf95ceb5e865..c2757d9ab216 100644
> --- a/Documentation/translations/sp_SP/process/submitting-patches.rst
> +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst
> @@ -276,7 +276,7 @@ parche a security@kernel.org. Para errores graves, se debe mantener un
>  poco de discreción y permitir que los distribuidores entreguen el parche a
>  los usuarios; en esos casos, obviamente, el parche no debe enviarse a
>  ninguna lista pública. Revise también
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>  
>  Los parches que corrigen un error grave en un kernel en uso deben dirigirse
>  hacia los maintainers estables poniendo una línea como esta::
> diff --git a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> index b8120391755d..d6b8f8a4e7f6 100644
> --- a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> @@ -1,6 +1,6 @@
>  .. include:: ../disclaimer-zh_CN.rst
>  
> -:Original: :doc:`../../../admin-guide/security-bugs`
> +:Original: :doc:`../../../process/security-bugs`
>  
>  :译者:
>  
> diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst
> index 10254751df6a..cc47be356dd3 100644
> --- a/Documentation/translations/zh_CN/process/howto.rst
> +++ b/Documentation/translations/zh_CN/process/howto.rst
> @@ -125,7 +125,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
>      这篇文档对于理解Linux的开发哲学至关重要。对于将开发平台从其他操作系
>      统转移到Linux的人来说也很重要。
>  
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>      如果你认为自己发现了Linux内核的安全性问题，请根据这篇文档中的步骤来
>      提醒其他内核开发者并帮助解决这个问题。
>  
> diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> index eed260ef0c37..15f8e9005071 100644
> --- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> @@ -2,7 +2,7 @@
>  
>  .. include:: ../disclaimer-zh_TW.rst
>  
> -:Original: :doc:`../../../admin-guide/security-bugs`
> +:Original: :doc:`../../../process/security-bugs`
>  
>  :譯者:
>  
> diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
> index 8fb8edcaee66..ea2f468d3e58 100644
> --- a/Documentation/translations/zh_TW/process/howto.rst
> +++ b/Documentation/translations/zh_TW/process/howto.rst
> @@ -128,7 +128,7 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
>      這篇文檔對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
>      統轉移到Linux的人來說也很重要。
>  
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>      如果你認爲自己發現了Linux內核的安全性問題，請根據這篇文檔中的步驟來
>      提醒其他內核開發者並幫助解決這個問題。
>  
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b0db911207ba..ed84d41353a7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -73,7 +73,7 @@ Tips for patch submitters
>  	and ideally, should come with a patch proposal. Please do not send
>  	automated reports to this list either. Such bugs will be handled
>  	better and faster in the usual public places. See
> -	Documentation/admin-guide/security-bugs.rst for details.
> +	Documentation/process/security-bugs.rst for details.
>  
>  8.	Happy hacking.
>  
> @@ -18807,7 +18807,7 @@ F:	include/uapi/linux/sed*
>  SECURITY CONTACT
>  M:	Security Officers <security@kernel.org>
>  S:	Supported
> -F:	Documentation/admin-guide/security-bugs.rst
> +F:	Documentation/process/security-bugs.rst
>  
>  SECURITY SUBSYSTEM
>  M:	Paul Moore <paul@paul-moore.com>

Re: [PATCH v3 1/7] Documentation/security-bugs: move from admin-guide/ to process/

[Yanteng Si]

在 3/6/23 06:00, Vegard Nossum 写道:
> Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire
> to move this document under process/.
>
> Create a new section for security issues in the index and group it with
> embargoed-hardware-issues.
>
> I'm doing this at the start of the series to make all the subsequent
> changes show up in 'git blame'.
>
> Existing references were updated using:
>
>    git grep -l security-bugs ':!Documentation/translations/' | xargs sed -i 's|admin-guide/security-bugs|process/security-bugs|g'
>    git grep -l security-bugs Documentation/translations/ | xargs sed -i 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g'
>    git grep -l security-bugs Documentation/translations/ | xargs sed -i '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g'
>
> Notably, the page is not moved in the translations (due to my lack of
> knowledge of these languages), but the translations have been updated
> to point to the new location of the original document where these
> references exist.
>
> Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2206062326230.10851@cbobk.fhfr.pm/
> Suggested-by: Jiri Kosina <jikos@kernel.org>
> Cc: Alex Shi <alexs@kernel.org>
> Cc: Yanteng Si <siyanteng@loongson.cn>
> Cc: Hu Haowen <src.res@email.cn>
> Cc: Federico Vaga <federico.vaga@vaga.pv.it>
> Cc: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
> Cc: Minchan Kim <minchan@kernel.org>
> Cc: Jeimi Lee <jamee.lee@samsung.com>
> Cc: Carlos Bilbao <carlos.bilbao@amd.com>
> Cc: Akira Yokosawa <akiyks@gmail.com>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>

Reviewed-by: Yanteng Si <siyanteng@loongson.cn>


Thanks,

Yanteng

> ---
>   Documentation/admin-guide/index.rst                      | 1 -
>   Documentation/admin-guide/reporting-issues.rst           | 4 ++--
>   Documentation/process/howto.rst                          | 2 +-
>   Documentation/process/index.rst                          | 9 ++++++++-
>   Documentation/process/researcher-guidelines.rst          | 2 +-
>   Documentation/{admin-guide => process}/security-bugs.rst | 0
>   Documentation/process/stable-kernel-rules.rst            | 2 +-
>   Documentation/process/submitting-patches.rst             | 2 +-
>   .../translations/it_IT/admin-guide/security-bugs.rst     | 2 +-
>   .../translations/it_IT/process/submitting-patches.rst    | 2 +-
>   Documentation/translations/ja_JP/howto.rst               | 2 +-
>   Documentation/translations/ko_KR/howto.rst               | 2 +-
>   Documentation/translations/sp_SP/howto.rst               | 2 +-
>   .../translations/sp_SP/process/submitting-patches.rst    | 2 +-
>   .../translations/zh_CN/admin-guide/security-bugs.rst     | 2 +-
>   Documentation/translations/zh_CN/process/howto.rst       | 2 +-
>   .../translations/zh_TW/admin-guide/security-bugs.rst     | 2 +-
>   Documentation/translations/zh_TW/process/howto.rst       | 2 +-
>   MAINTAINERS                                              | 4 ++--
>   19 files changed, 26 insertions(+), 20 deletions(-)
>   rename Documentation/{admin-guide => process}/security-bugs.rst (100%)
>
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 0ad7e7ec0d27..09a563bbe3e7 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -36,7 +36,6 @@ problems and bugs in particular.
>   
>      reporting-issues
>      reporting-regressions
> -   security-bugs
>      bug-hunting
>      bug-bisect
>      tainted-kernels
> diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
> index ec62151fe672..2fd5a030235a 100644
> --- a/Documentation/admin-guide/reporting-issues.rst
> +++ b/Documentation/admin-guide/reporting-issues.rst
> @@ -395,7 +395,7 @@ might want to be aware of; it for example explains how to add your issue to the
>   list of tracked regressions, to ensure it won't fall through the cracks.
>   
>   What qualifies as security issue is left to your judgment. Consider reading
> -Documentation/admin-guide/security-bugs.rst before proceeding, as it
> +Documentation/process/security-bugs.rst before proceeding, as it
>   provides additional details how to best handle security issues.
>   
>   An issue is a 'really severe problem' when something totally unacceptably bad
> @@ -1269,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward
>   the report's text to these addresses; but on top of it put a small note where
>   you mention that you filed it with a link to the ticket.
>   
> -See Documentation/admin-guide/security-bugs.rst for more information.
> +See Documentation/process/security-bugs.rst for more information.
>   
>   
>   Duties after the report went out
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index cb6abcb2b6d0..deb8235e20ff 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -138,7 +138,7 @@ required reading:
>       philosophy and is very important for people moving to Linux from
>       development on other Operating Systems.
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       If you feel you have found a security problem in the Linux kernel,
>       please follow the steps in this document to help notify the kernel
>       developers, and help solve the issue.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index d4b6217472b0..565df595152e 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -35,6 +35,14 @@ Below are the essential guides that every developer should read.
>      kernel-enforcement-statement
>      kernel-driver-statement
>   
> +For security issues, see:
> +
> +.. toctree::
> +   :maxdepth: 1
> +
> +   security-bugs
> +   embargoed-hardware-issues
> +
>   Other guides to the community that are of interest to most developers are:
>   
>   .. toctree::
> @@ -47,7 +55,6 @@ Other guides to the community that are of interest to most developers are:
>      submit-checklist
>      kernel-docs
>      deprecated
> -   embargoed-hardware-issues
>      maintainers
>      researcher-guidelines
>   
> diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst
> index afc944e0e898..9fcfed3c350b 100644
> --- a/Documentation/process/researcher-guidelines.rst
> +++ b/Documentation/process/researcher-guidelines.rst
> @@ -68,7 +68,7 @@ Before contributing, carefully read the appropriate documentation:
>   * Documentation/process/development-process.rst
>   * Documentation/process/submitting-patches.rst
>   * Documentation/admin-guide/reporting-issues.rst
> -* Documentation/admin-guide/security-bugs.rst
> +* Documentation/process/security-bugs.rst
>   
>   Then send a patch (including a commit log with all the details listed
>   below) and follow up on any feedback from other developers.
> diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/process/security-bugs.rst
> similarity index 100%
> rename from Documentation/admin-guide/security-bugs.rst
> rename to Documentation/process/security-bugs.rst
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index 2fd8aa593a28..51df1197d5ab 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree
>   
>      Security patches should not be handled (solely) by the -stable review
>      process but should follow the procedures in
> -   :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.
> +   :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
>   
>   For all other submissions, choose one of the following procedures
>   -----------------------------------------------------------------
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index eac7167dce83..7b223f306efa 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -254,7 +254,7 @@ If you have a patch that fixes an exploitable security bug, send that patch
>   to security@kernel.org.  For severe bugs, a short embargo may be considered
>   to allow distributors to get the patch out to users; in such cases,
>   obviously, the patch should not be sent to any public lists. See also
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>   
>   Patches that fix a severe bug in a released kernel should be directed
>   toward the stable maintainers by putting a line like this::
> diff --git a/Documentation/translations/it_IT/admin-guide/security-bugs.rst b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> index 18a5822c7d9a..20994f4bfa31 100644
> --- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/it_IT/admin-guide/security-bugs.rst
> @@ -1,6 +1,6 @@
>   .. include:: ../disclaimer-ita.rst
>   
> -:Original: :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +:Original: :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>   
>   .. _it_securitybugs:
>   
> diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
> index c2cfa0948b2b..167fce813032 100644
> --- a/Documentation/translations/it_IT/process/submitting-patches.rst
> +++ b/Documentation/translations/it_IT/process/submitting-patches.rst
> @@ -272,7 +272,7 @@ embargo potrebbe essere preso in considerazione per dare il tempo alle
>   distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
>   in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
>   lista di discussione pubblica. Leggete anche
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>   
>   Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
>   essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga::
> diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst
> index 9b0b3436dfcf..8d856ebe873c 100644
> --- a/Documentation/translations/ja_JP/howto.rst
> +++ b/Documentation/translations/ja_JP/howto.rst
> @@ -167,7 +167,7 @@ linux-api@vger.kernel.org に送ることを勧めます。
>       このドキュメントは Linux 開発の思想を理解するのに非常に重要です。
>       そして、他のOSでの開発者が Linux に移る時にとても重要です。
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ
>       のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を
>       支援してください。
> diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
> index 969e91a95bb0..34f14899c155 100644
> --- a/Documentation/translations/ko_KR/howto.rst
> +++ b/Documentation/translations/ko_KR/howto.rst
> @@ -157,7 +157,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.
>       리눅스로 전향하는 사람들에게는 매우 중요하다.
>   
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에
>       나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록
>       도와 달라.
> diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
> index f9818d687b54..f1629738b49d 100644
> --- a/Documentation/translations/sp_SP/howto.rst
> +++ b/Documentation/translations/sp_SP/howto.rst
> @@ -135,7 +135,7 @@ de obligada lectura:
>        de Linux y es muy importante para las personas que se mudan a Linux
>        tras desarrollar otros sistemas operativos.
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       Si cree que ha encontrado un problema de seguridad en el kernel de
>       Linux, siga los pasos de este documento para ayudar a notificar a los
>       desarrolladores del kernel y ayudar a resolver el problema.
> diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst
> index bf95ceb5e865..c2757d9ab216 100644
> --- a/Documentation/translations/sp_SP/process/submitting-patches.rst
> +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst
> @@ -276,7 +276,7 @@ parche a security@kernel.org. Para errores graves, se debe mantener un
>   poco de discreción y permitir que los distribuidores entreguen el parche a
>   los usuarios; en esos casos, obviamente, el parche no debe enviarse a
>   ninguna lista pública. Revise también
> -Documentation/admin-guide/security-bugs.rst.
> +Documentation/process/security-bugs.rst.
>   
>   Los parches que corrigen un error grave en un kernel en uso deben dirigirse
>   hacia los maintainers estables poniendo una línea como esta::
> diff --git a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> index b8120391755d..d6b8f8a4e7f6 100644
> --- a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst
> @@ -1,6 +1,6 @@
>   .. include:: ../disclaimer-zh_CN.rst
>   
> -:Original: :doc:`../../../admin-guide/security-bugs`
> +:Original: :doc:`../../../process/security-bugs`
>   
>   :译者:
>   
> diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst
> index 10254751df6a..cc47be356dd3 100644
> --- a/Documentation/translations/zh_CN/process/howto.rst
> +++ b/Documentation/translations/zh_CN/process/howto.rst
> @@ -125,7 +125,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
>       这篇文档对于理解Linux的开发哲学至关重要。对于将开发平台从其他操作系
>       统转移到Linux的人来说也很重要。
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       如果你认为自己发现了Linux内核的安全性问题，请根据这篇文档中的步骤来
>       提醒其他内核开发者并帮助解决这个问题。
>   
> diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> index eed260ef0c37..15f8e9005071 100644
> --- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> +++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
> @@ -2,7 +2,7 @@
>   
>   .. include:: ../disclaimer-zh_TW.rst
>   
> -:Original: :doc:`../../../admin-guide/security-bugs`
> +:Original: :doc:`../../../process/security-bugs`
>   
>   :譯者:
>   
> diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
> index 8fb8edcaee66..ea2f468d3e58 100644
> --- a/Documentation/translations/zh_TW/process/howto.rst
> +++ b/Documentation/translations/zh_TW/process/howto.rst
> @@ -128,7 +128,7 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
>       這篇文檔對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
>       統轉移到Linux的人來說也很重要。
>   
> -  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
>       如果你認爲自己發現了Linux內核的安全性問題，請根據這篇文檔中的步驟來
>       提醒其他內核開發者並幫助解決這個問題。
>   
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b0db911207ba..ed84d41353a7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -73,7 +73,7 @@ Tips for patch submitters
>   	and ideally, should come with a patch proposal. Please do not send
>   	automated reports to this list either. Such bugs will be handled
>   	better and faster in the usual public places. See
> -	Documentation/admin-guide/security-bugs.rst for details.
> +	Documentation/process/security-bugs.rst for details.
>   
>   8.	Happy hacking.
>   
> @@ -18807,7 +18807,7 @@ F:	include/uapi/linux/sed*
>   SECURITY CONTACT
>   M:	Security Officers <security@kernel.org>
>   S:	Supported
> -F:	Documentation/admin-guide/security-bugs.rst
> +F:	Documentation/process/security-bugs.rst
>   
>   SECURITY SUBSYSTEM
>   M:	Paul Moore <paul@paul-moore.com>

Re: [PATCH v3 1/7] Documentation/security-bugs: move from admin-guide/ to process/

[Greg Kroah-Hartman]

On Sun, Mar 05, 2023 at 11:00:04PM +0100, Vegard Nossum wrote:
> Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire
> to move this document under process/.
> 
> Create a new section for security issues in the index and group it with
> embargoed-hardware-issues.
> 
> I'm doing this at the start of the series to make all the subsequent
> changes show up in 'git blame'.
> 
> Existing references were updated using:
> 
>   git grep -l security-bugs ':!Documentation/translations/' | xargs sed -i 's|admin-guide/security-bugs|process/security-bugs|g'
>   git grep -l security-bugs Documentation/translations/ | xargs sed -i 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g'
>   git grep -l security-bugs Documentation/translations/ | xargs sed -i '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g'
> 
> Notably, the page is not moved in the translations (due to my lack of
> knowledge of these languages), but the translations have been updated
> to point to the new location of the original document where these
> references exist.

Thanks for this one, I've applied it to my tree as everyone agrees it is
needed.

greg k-h

[PATCH v3 2/7] Documentation/security-bugs: misc. improvements

[Vegard Nossum]

This mostly just clarifies things and moves a few things around in
preparation for the subsequent changes.

Most notably, pull the "security@kernel.org" address up into the first
paragraph as this the most vital piece of information in the whole
document.

Also fix a few markup issues.

Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 Documentation/process/security-bugs.rst | 37 ++++++++++++++-----------
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 82e29837d589..f1326d4e9718 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -1,36 +1,41 @@
 .. _securitybugs:
 
-Security bugs
-=============
+Reporting security bugs
+=======================
 
 Linux kernel developers take security very seriously.  As such, we'd
 like to know when a security bug is found so that it can be fixed and
 disclosed as quickly as possible.  Please report security bugs to the
-Linux kernel security team.
+Linux kernel security team at security@kernel.org, henceforth
+"the security list".  This is a closed list of trusted developers who
+will help verify the bug report and develop a patch in case none was
+already proposed.
 
-Contact
--------
+While the security list is closed, the security team may bring in extra
+help from the relevant maintainers to understand and fix the security
+vulnerability.
 
-The Linux kernel security team can be contacted by email at
-<security@kernel.org>.  This is a private list of security officers
-who will help verify the bug report and develop and release a fix.
-If you already have a fix, please include it with your report, as
-that can speed up the process considerably.  It is possible that the
-security team will bring in extra help from area maintainers to
-understand and fix the security vulnerability.
+Note that the main interest of the kernel security list is in getting
+bugs fixed and getting patches reviewed, tested, and merged; CVE
+assignment, disclosure to distributions, and public disclosure happen on
+different lists with different people.
+
+Contacting the security list
+----------------------------
 
 As it is with any bug, the more information provided the easier it
 will be to diagnose and fix.  Please review the procedure outlined in
-'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
+Documentation/admin-guide/reporting-issues.rst if you are unclear about what
 information is helpful.  Any exploit code is very helpful and will not
 be released without consent from the reporter unless it has already been
-made public.
+made public.  Reporters are encouraged to propose patches, participate in the
+discussions of a fix, and test patches.
 
 Please send plain text emails without attachments where possible.
 It is much harder to have a context-quoted discussion about a complex
 issue if all the details are hidden away in attachments.  Think of it like a
-:doc:`regular patch submission <../process/submitting-patches>`
-(even if you don't have a patch yet): describe the problem and impact, list
+regular patch submission (see Documentation/process/submitting-patches.rst)
+even if you don't have a patch yet; describe the problem and impact, list
 reproduction steps, and follow it with a proposed fix, all in plain text.
 
 Disclosure and embargoed information
-- 
2.40.0.rc1.2.gd15644fe02

Re: [PATCH v3 2/7] Documentation/security-bugs: misc. improvements

[Greg Kroah-Hartman]

On Sun, Mar 05, 2023 at 11:00:05PM +0100, Vegard Nossum wrote:
> This mostly just clarifies things and moves a few things around in
> preparation for the subsequent changes.
> 
> Most notably, pull the "security@kernel.org" address up into the first
> paragraph as this the most vital piece of information in the whole
> document.
> 
> Also fix a few markup issues.

When you have "also" in a patch changelog, that usually means this
should be a separate patch.  Can you just fix up the markup issues first
please?

Also, a few minor comments below:

> 
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> ---
>  Documentation/process/security-bugs.rst | 37 ++++++++++++++-----------
>  1 file changed, 21 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 82e29837d589..f1326d4e9718 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -1,36 +1,41 @@
>  .. _securitybugs:
>  
> -Security bugs
> -=============
> +Reporting security bugs
> +=======================
>  
>  Linux kernel developers take security very seriously.  As such, we'd
>  like to know when a security bug is found so that it can be fixed and
>  disclosed as quickly as possible.  Please report security bugs to the
> -Linux kernel security team.
> +Linux kernel security team at security@kernel.org, henceforth
> +"the security list".  This is a closed list of trusted developers who
> +will help verify the bug report and develop a patch in case none was
> +already proposed.
>  
> -Contact
> --------
> +While the security list is closed, the security team may bring in extra
> +help from the relevant maintainers to understand and fix the security
> +vulnerability.
>  
> -The Linux kernel security team can be contacted by email at
> -<security@kernel.org>.  This is a private list of security officers
> -who will help verify the bug report and develop and release a fix.
> -If you already have a fix, please include it with your report, as
> -that can speed up the process considerably.  It is possible that the
> -security team will bring in extra help from area maintainers to
> -understand and fix the security vulnerability.
> +Note that the main interest of the kernel security list is in getting
> +bugs fixed and getting patches reviewed, tested, and merged; CVE

It's not "main interest", it is the "only task" of it.  That's all the
list does, nothing else.

> +assignment, disclosure to distributions, and public disclosure happen on
> +different lists with different people.

How about this rephrasing:

	The only tasks of the kernel security list are to triage
	reported potential security bugs, generate and test a fix, and
	get the fix merged into Linus's and the stable kernel trees.
	The security list does not deal with CVE assignment or any sort
	of disclosure at all.

thanks,

greg k-h

[PATCH v3 3/7] Documentation/security-bugs: improve security list section

[Vegard Nossum]

Make this section about the security list easier to parse by:

1) reordering the content to make more sense,

2) adding "paragraph names" to make it visually easier to
   find exactly the information that you need for a given step (this
   will also be applied to the other sections for consistency in
   subsequent patches),

3) pulling some of the information that is relevant to contacting
   security@kernel.org specifically into the section about that list.

The remaining sections are about CVE assignment, coordinated
disclosure, etc., which are things the security list _doesn't_ deal
with. (These sections will be expanded and clarified in subsequent
patches.)

This patch is not meant to introduce any semantic changes, so in
case of a dispute the previous version will be authoritative.

Link: https://lore.kernel.org/all/20220601031254.GB26318@1wt.eu/
Link: https://lore.kernel.org/all/20220607090726.GB32282@willie-the-truck/
Cc: Willy Tarreau <w@1wt.eu>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 Documentation/process/security-bugs.rst | 76 ++++++++++++-------------
 1 file changed, 35 insertions(+), 41 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index f1326d4e9718..fb156d146c42 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -31,42 +31,42 @@ be released without consent from the reporter unless it has already been
 made public.  Reporters are encouraged to propose patches, participate in the
 discussions of a fix, and test patches.
 
-Please send plain text emails without attachments where possible.
-It is much harder to have a context-quoted discussion about a complex
-issue if all the details are hidden away in attachments.  Think of it like a
-regular patch submission (see Documentation/process/submitting-patches.rst)
-even if you don't have a patch yet; describe the problem and impact, list
-reproduction steps, and follow it with a proposed fix, all in plain text.
+**Disclosure.** Once a robust patch or patchset has been developed, the
+release process starts.  The security list strongly prefers to have these
+posted for review and testing on public mailing lists and merged into the
+appropriate public git repository as soon as possible.  However, you or an
+affected party may request that the patch be withheld for some days; as a
+rule, the maximum is 7 calendar days.  An exceptional extension to 14
+calendar days is possible if it is agreed that the criticality of the bug
+requires more time.  The only valid reason for deferring the publication
+of a fix is to accomodate the logistics of QA and large scale rollouts
+which require release coordination.
+
+Please note that although a fix is public, there may still be value in
+withholding the details of its security relevance and/or how to exploit
+it for another while; see below for when and how to properly disclose
+the security impact of your findings publicly.
+
+**List rules.** Please send plain text emails without attachments where
+possible.  It is much harder to have a context-quoted discussion about a
+complex issue if all the details are hidden away in attachments.  Think
+of it like regular patch submission (see
+Documentation/process/submitting-patches.rst) even if you don't have a
+patch yet; describe the problem and impact, list reproduction steps, and
+follow it with a proposed fix, all in plain text.
+
+**Confidentiality.** While embargoed information may be shared with
+trusted individuals in order to develop a fix, such information will not
+be published alongside the fix or on any other disclosure channel
+without the permission of the reporter.  This includes but is not
+limited to the original bug report and followup discussions (if any),
+exploits, CVE information or the identity of the reporter.  All such
+other information submitted to the security list and any follow-up
+discussions of the report are treated confidentially even after the
+embargo has been lifted, in perpetuity.
 
-Disclosure and embargoed information
-------------------------------------
-
-The security list is not a disclosure channel.  For that, see Coordination
-below.
-
-Once a robust fix has been developed, the release process starts.  Fixes
-for publicly known bugs are released immediately.
-
-Although our preference is to release fixes for publicly undisclosed bugs
-as soon as they become available, this may be postponed at the request of
-the reporter or an affected party for up to 7 calendar days from the start
-of the release process, with an exceptional extension to 14 calendar days
-if it is agreed that the criticality of the bug requires more time.  The
-only valid reason for deferring the publication of a fix is to accommodate
-the logistics of QA and large scale rollouts which require release
-coordination.
-
-While embargoed information may be shared with trusted individuals in
-order to develop a fix, such information will not be published alongside
-the fix or on any other disclosure channel without the permission of the
-reporter.  This includes but is not limited to the original bug report
-and followup discussions (if any), exploits, CVE information or the
-identity of the reporter.
-
-In other words our only interest is in getting bugs fixed.  All other
-information submitted to the security list and any followup discussions
-of the report are treated confidentially even after the embargo has been
-lifted, in perpetuity.
+The Linux kernel security team is not a formal body and therefore unable
+to enter any non-disclosure agreements.
 
 Coordination
 ------------
@@ -93,9 +93,3 @@ assigned ahead of public disclosure, they will need to contact the private
 linux-distros list, described above. When such a CVE identifier is known
 before a patch is provided, it is desirable to mention it in the commit
 message if the reporter agrees.
-
-Non-disclosure agreements
--------------------------
-
-The Linux kernel security team is not a formal body and therefore unable
-to enter any non-disclosure agreements.
-- 
2.40.0.rc1.2.gd15644fe02

[PATCH v3 4/7] Documentation/security-bugs: add linux-distros and oss-security sections

[Vegard Nossum]

The existing information about CVE assignment requests and coordinated
disclosure fits much better in these new sections, since that's what these
lists are for.

Keep just a reminder in the security list section.

Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 Documentation/process/security-bugs.rst | 92 ++++++++++++++++++-------
 1 file changed, 67 insertions(+), 25 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index fb156d146c42..2dd6569a7abb 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -31,6 +31,10 @@ be released without consent from the reporter unless it has already been
 made public.  Reporters are encouraged to propose patches, participate in the
 discussions of a fix, and test patches.
 
+The security team does not assign CVEs, nor does it require them for reports
+or fixes.  CVEs may be requested when the issue is reported to the
+linux-distros list.
+
 **Disclosure.** Once a robust patch or patchset has been developed, the
 release process starts.  The security list strongly prefers to have these
 posted for review and testing on public mailing lists and merged into the
@@ -68,28 +72,66 @@ embargo has been lifted, in perpetuity.
 The Linux kernel security team is not a formal body and therefore unable
 to enter any non-disclosure agreements.
 
-Coordination
-------------
-
-Fixes for sensitive bugs, such as those that might lead to privilege
-escalations, may need to be coordinated with the private
-<linux-distros@vs.openwall.org> mailing list so that distribution vendors
-are well prepared to issue a fixed kernel upon public disclosure of the
-upstream fix. Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start. In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
-
-CVE assignment
---------------
-
-The security team does not normally assign CVEs, nor do we require them
-for reports or fixes, as this can needlessly complicate the process and
-may delay the bug handling. If a reporter wishes to have a CVE identifier
-assigned ahead of public disclosure, they will need to contact the private
-linux-distros list, described above. When such a CVE identifier is known
-before a patch is provided, it is desirable to mention it in the commit
-message if the reporter agrees.
+Once a patch has been developed, you are encouraged to contact the
+linux-distros list.
+
+Contacting the linux-distros list
+---------------------------------
+
+Fixes for particularly sensitive bugs (such as those that might lead to
+privilege escalations) may need to be coordinated with the private
+linux-distros mailing list (linux-distros@vs.openwall.org) so that
+distribution vendors are well prepared to release a fixed kernel as soon as
+possible after the public disclosure of the upstream fix.  This includes
+verifying the reported issue, testing proposed fixes, developing a fix (if
+none is known yet), and backporting to older kernels and other versions.
+
+The linux-distros list can also help with assigning a CVE for your issue.
+
+**Disclosure.** The linux-distros list has a strict policy of requiring
+reporters to post about the security issue on oss-security within 14
+calendar days of the list being contacted regardless of whether a patch is
+available or not.  It is therefore preferable that you don't send your
+initial bug report to the linux-distros list unless you already have a patch
+for the issue.
+
+**List rules.** The main rules to be aware of when contacting the
+linux-distros list are:
+
+* Don't post about issues that are already public. If your issue has a
+  public patch, but the security impact is not generally known, then you may
+  still post about it.
+
+* The submitter can suggest an embargo end-date, but as a rule, embargoes
+  should not be longer than 7 calendar days, or at most 14 calendar days in
+  exceptional cases. Keep in mind that vendors may prefer to release new
+  kernel packages and/or updates Tuesday through Thursday.
+
+* When the embargo ends, the issue must be disclosed immediately on the
+  oss-security list (see below).
+
+* Prefix your subject with the string "[vs]" to avoid getting rejected by
+  the spam filter.
+
+For the full list of rules, see:
+https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters
+
+**Confidentiality.** Please note that, as opposed to the security list, any
+and all material submitted to the list must be made public once the security
+issue is publicly disclosed, so please do not post information to the
+linux-distros list that cannot be made public.
+
+Contacting the oss-security list
+--------------------------------
+
+When your security issue is public, or you wish to make your issue public,
+you can write to the oss-security list (oss-security@lists.openwall.com).
+This is a public list (anybody can subscribe and view the list archives) and
+it is not restricted to Linux kernel issues.
+
+The oss-security list typically does not assign CVEs or accept requests for
+CVE assignments.
+
+**List rules.** Please do not cross-post to other lists when writing to this
+list. Make sure to read the other list rules before posting:
+https://oss-security.openwall.org/wiki/mailing-lists/oss-security.
-- 
2.40.0.rc1.2.gd15644fe02

Re: [PATCH v3 4/7] Documentation/security-bugs: add linux-distros and oss-security sections

[Greg Kroah-Hartman]

On Sun, Mar 05, 2023 at 11:00:07PM +0100, Vegard Nossum wrote:
> The existing information about CVE assignment requests and coordinated
> disclosure fits much better in these new sections, since that's what these
> lists are for.
> 
> Keep just a reminder in the security list section.
> 
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> ---
>  Documentation/process/security-bugs.rst | 92 ++++++++++++++++++-------
>  1 file changed, 67 insertions(+), 25 deletions(-)
> 
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index fb156d146c42..2dd6569a7abb 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -31,6 +31,10 @@ be released without consent from the reporter unless it has already been
>  made public.  Reporters are encouraged to propose patches, participate in the
>  discussions of a fix, and test patches.
>  
> +The security team does not assign CVEs, nor does it require them for reports
> +or fixes.  CVEs may be requested when the issue is reported to the
> +linux-distros list.

Note, this kind of implies that the security team would be the one whom
you request a CVE from.  We can't do that, nor do we ever even want to
deal with that for obvious reasons.  Also, who is to say that CVEs are
even anything anyone should be messing with in the first place given how
much they are abused and irrelevant most of the time?

So I would just keep a big "The kernel developer community does not deal
with CVEs at all.  If you want one for your résumé/CV, please contact
MITRE directly at your own risk." type of warning in the document and
leave it at that.

thanks,

greg k-h

[PATCH v3 5/7] Documentation/security-bugs: add table of lists

[Vegard Nossum]

Give an overview of the full process the start of the document.
This makes it clear 1) in what order the lists should be contacted,
and 2) the purpose of each list.

Thanks to Jonathan Corbet and Mauro Carvalho Chehab for providing
the readable markup for the table.

Link: https://lore.kernel.org/all/20220604014317.79eb23db@sal.lan/
Suggested-by: Jonathan Corbet <corbet@lwn.net>
Suggested-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 Documentation/process/security-bugs.rst | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 2dd6569a7abb..61742dcfea50 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -18,7 +18,26 @@ vulnerability.
 Note that the main interest of the kernel security list is in getting
 bugs fixed and getting patches reviewed, tested, and merged; CVE
 assignment, disclosure to distributions, and public disclosure happen on
-different lists with different people.
+different lists with different people, as described below.
+
+Here is a quick overview of the various lists:
+
+ =============================== ===== =================== ===============
+ List address                    Open? Purpose             Members
+ =============================== ===== =================== ===============
+ security@kernel.org                no | Reporting         Trusted kernel
+                                       | Patch development developers
+ ------------------------------- ----- ------------------- ---------------
+ linux-distros@vs.openwall.org      no | Coordination      Distribution
+                                       | CVE assignment    representatives
+                                       | Backporting
+                                       | Testing
+ ------------------------------- ----- ------------------- ---------------
+ oss-security@lists.openwall.com   yes | Disclosure        General public
+ =============================== ===== =================== ===============
+
+The following sections give a step-by-step guide to reporting and
+disclosure.
 
 Contacting the security list
 ----------------------------
-- 
2.40.0.rc1.2.gd15644fe02

[PATCH v3 6/7] Documentation/security-bugs: clarify hardware vs. software vulnerabilities

[Vegard Nossum]

We should emphasize the fact that we have a separate document for
reporting hardware vulnerabilities.

Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2206062326230.10851@cbobk.fhfr.pm/
Suggested-by: Jiri Kosina <jikos@kernel.org>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 Documentation/process/security-bugs.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 61742dcfea50..7bd59587332a 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -15,6 +15,10 @@ While the security list is closed, the security team may bring in extra
 help from the relevant maintainers to understand and fix the security
 vulnerability.
 
+The security list is mainly for software vulnerabilities.  For hardware
+security vulnerabilities, see
+Documentation/process/embargoed-hardware-issues.rst instead.
+
 Note that the main interest of the kernel security list is in getting
 bugs fixed and getting patches reviewed, tested, and merged; CVE
 assignment, disclosure to distributions, and public disclosure happen on
-- 
2.40.0.rc1.2.gd15644fe02

[PATCH v3 7/7] Documentation/security-bugs: document document design

[Vegard Nossum]

I think there is value in expressing the high-level design of this
document so that it will not get lost with future revisions.

This section is an rST comment and will not be part of rendered
documentation (e.g. the html version).

Link: https://lore.kernel.org/all/87ilpk5wsi.fsf@meer.lwn.net/
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
 Documentation/process/security-bugs.rst | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 7bd59587332a..8d9adc02cd49 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -158,3 +158,24 @@ CVE assignments.
 **List rules.** Please do not cross-post to other lists when writing to this
 list. Make sure to read the other list rules before posting:
 https://oss-security.openwall.org/wiki/mailing-lists/oss-security.
+
+..
+    If you modify this document, please consider the following:
+    
+    1) The most important information should be at the top (preferably in
+    the opening paragraph). This means contacting <security@kernel.org>;
+    if somebody doesn't read any further than that, at least the security
+    team will have the report.
+    
+    2) Make the differences between the lists extremely clear. The old
+    version did make an attempt at this, but the lines were not drawn
+    clearly enough.
+    
+    3) Emphasize some of the posting rules which can be confusing to new
+    people (e.g. the fact that posting to linux-distros means you must
+    propose an embargo date and that this cannot under any circumstances
+    be more than 14 days).
+    
+    4) The document should be a "step-by-step process" as much as possible,
+    so that you can use it as a guide while reporting an issue instead of
+    having to search back and forth for the thing you're looking for.
-- 
2.40.0.rc1.2.gd15644fe02

Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

[Greg Kroah-Hartman]

On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
> Hi,
> 
> This is v3 of clarifying our documentation for reporting security
> issues.
> 
> The current document is not clear enough, in particular the process of
> disclosure and requesting CVEs, and what the roles of the different
> lists are and how exactly to report to each of them.
> 
> Lots of people have been confused about the 7/14 days of the kernel list
> vs. the 7/14 days of the distros list, the fact that these are two
> separate lists, etc. Many reporters contact distros first, or submit
> their report to both lists at the same time (which has the unfortunate
> effect of starting off the disclosure countdown for the distros list
> before s@k.o has had a chance to look at the report). I've shared the v2
> document with a couple of people who submitted reports and they said
> they found it a lot clearer. 
> 
> Probably the easiest way to see the end result of this series is to view the
> rendered HTML which I've put here:
> https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html

Thanks for doing this, it looks much better, but I do have some
objections with it.

First off, you didn't cc: the security@k.o group to see if they agree
with this, any specific reason why?  :)

Secondly, and the bigger one, I think we should just drop all of the
references to linux-distros and oss-security entirely, as those are
groups that are outside of our control and interaction and have
different rules that we might not agree with.  They also just a tiny
subset of Linux users and companies and as such do not really reflect
the majority of where Linux is used anymore.

But overall I like the slimmer size, so perhaps the end result just
being the first two major sections would be best.  Let me take those
changes first and we can see how the result looks for now to see if that
will resolve some of the major issues the security@k.o group have right
now with reports (i.e. CVE requests, other group's disclosure rules and
dates).

thanks,

greg k-h

Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

[Willy Tarreau]

On Mon, Mar 06, 2023 at 07:02:14AM +0100, Greg Kroah-Hartman wrote:
> Secondly, and the bigger one, I think we should just drop all of the
> references to linux-distros and oss-security entirely, as those are
> groups that are outside of our control and interaction and have
> different rules that we might not agree with.  They also just a tiny
> subset of Linux users and companies and as such do not really reflect
> the majority of where Linux is used anymore.

I'm wondering if instead they shouldn't just be mentioned as a warning
about the risk of leak or forced disclosure. We know that reporters may
find the address from various places, including various sites that may
enumerate the long list of potential contacts, and not just this doc.
It can be useful to have just a paragraph warning about the fact that
oss-sec is public and that linux-distros has this strict disclosure
policy without consideration for the availability of a fix, in order
to warn them to only contact such lists once the fix is available and
tested if they want to, but never before. Anything we can do to help
serious reporters (i.e. those who are really embarrassed with a bug,
not those who seek a Curiculum Vitae Enhancer) should be done. It's
always a stressful moment to report a security issue on a project,
you always fear that you might be doing an irreversible mistake, so
whatever info we can pass about the risks (or lack of) should be
welcome I guess.

Willy

Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

[Greg Kroah-Hartman]

On Mon, Mar 06, 2023 at 07:35:34AM +0100, Willy Tarreau wrote:
> On Mon, Mar 06, 2023 at 07:02:14AM +0100, Greg Kroah-Hartman wrote:
> > Secondly, and the bigger one, I think we should just drop all of the
> > references to linux-distros and oss-security entirely, as those are
> > groups that are outside of our control and interaction and have
> > different rules that we might not agree with.  They also just a tiny
> > subset of Linux users and companies and as such do not really reflect
> > the majority of where Linux is used anymore.
> 
> I'm wondering if instead they shouldn't just be mentioned as a warning
> about the risk of leak or forced disclosure. We know that reporters may
> find the address from various places, including various sites that may
> enumerate the long list of potential contacts, and not just this doc.
> It can be useful to have just a paragraph warning about the fact that
> oss-sec is public and that linux-distros has this strict disclosure
> policy without consideration for the availability of a fix, in order
> to warn them to only contact such lists once the fix is available and
> tested if they want to, but never before. Anything we can do to help
> serious reporters (i.e. those who are really embarrassed with a bug,
> not those who seek a Curiculum Vitae Enhancer) should be done. It's
> always a stressful moment to report a security issue on a project,
> you always fear that you might be doing an irreversible mistake, so
> whatever info we can pass about the risks (or lack of) should be
> welcome I guess.

That's a good idea, if it can be worded in a way that reflects that is
is not any sort of requirement or that it is normal part of our
development process.

thanks,

greg k-h

Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

[Vegard Nossum]

On 3/6/23 07:02, Greg Kroah-Hartman wrote:
> On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
>> Lots of people have been confused about the 7/14 days of the kernel list
>> vs. the 7/14 days of the distros list, the fact that these are two
>> separate lists, etc. Many reporters contact distros first, or submit
>> their report to both lists at the same time (which has the unfortunate
>> effect of starting off the disclosure countdown for the distros list
>> before s@k.o has had a chance to look at the report). I've shared the v2
>> document with a couple of people who submitted reports and they said
>> they found it a lot clearer.
>>
>> Probably the easiest way to see the end result of this series is to view the
>> rendered HTML which I've put here:
>> https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html
> 
> Thanks for doing this, it looks much better, but I do have some
> objections with it.
> 
> First off, you didn't cc: the security@k.o group to see if they agree
> with this, any specific reason why?  :)

I did consider it, but thought it was better not to since this is not
a security issue -- but I see it's actually listed in MAINTAINERS (in an
entry I'm changing, no less... *facepalm*)

Added to Cc, beginning of the thread is here:
https://lore.kernel.org/all/20230305220010.20895-1-vegard.nossum@oracle.com/

> Secondly, and the bigger one, I think we should just drop all of the
> references to linux-distros and oss-security entirely, as those are
> groups that are outside of our control and interaction and have
> different rules that we might not agree with.

I find this a strange sentiment. All the major Linux distros have a
presence on the distros list and it remains a valuable resource for
coordination.

I think most of the friction of the past should have been resolved by
the distros list actually updating its rules last year (if not 100%
according to your wishes, at least a good step in that direction), any
remaining problems should hopefully be resolved by improving the
documentation so that issues are not sent to the distros list prematurely.

> They also just a tiny subset of Linux users and companies and as such
> do not really reflect the majority of where Linux is used anymore.
Is the elephant in the room that Android vendors are not rolling out
kernel updates in the 7-14 days given by distros to publicly disclose
the reported issues? If so, then I think this is the real issue here,
and it should be stated outright.

> But overall I like the slimmer size, so perhaps the end result just
> being the first two major sections would be best.  Let me take those
> changes first and we can see how the result looks for now to see if that
> will resolve some of the major issues the security@k.o group have right
> now with reports (i.e. CVE requests, other group's disclosure rules and
> dates).

I personally think it would be a mistake not to include the info about
the other lists, both because I think they have real value (and I do
think they represent Linux kernel users, if not kernel developers) but
also because, as Willy said, people will find the wrong information
elsewhere and submit issues anyway, people are still going to want to
request CVEs (regardless of what you or I think about them), etc.

Anyway, I don't represent s@k.o so I don't decide, I really just want
security for end users and as responsible disclosure as we can hope for.
The patches are out there so feel free to use whatever you want from them.

Thanks for looking it over.


Vegard

Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

[Willy Tarreau]

Hi Vegard,

first, thanks for doing this work.

On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
> Probably the easiest way to see the end result of this series is to view the
> rendered HTML which I've put here:
> https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html

I'm seeing a few points that could be improved but I don't have much to
propose right now, I'll just enumerate issues we've faced in the past or
that continue to pop up from time to time and that require extra effort
from the team:

  - I'm not seeing anywhere that the security list is *exclusively*
    for kernel issues. That might explain why about once a week or so
    we receive messages like "there's a bug in that userland tool" or
    "we've found an XSS issue on your website". It's written that kernel
    bugs should be reported to the security list but I think we should
    strengthen that by adding "This list is exclusively used for Linux
    kernel security reports, please do not report issues affecting any
    other component there".

  - we always need to be able to describe the nature of a bug in the
    commit message so that if the patch is found to cause a regression,
    its purpose can at least be understood and argumented. It happened
    at least once that we were requested not to explain the details
    because a paper was about to be issued, and that's not acceptable
    at all because it means that it becomes very complicated to have
    public discussions about possible forthcoming issues. I think that
    after the paragraph suggesting that the details of an issue or its
    exploit code might not always be published, it could be useful to
    mention something along the fact that the reporter shall not
    request the security team to withhold technical details about the
    issue as long as it doesn't represent an imminent danger.

  - it's quite frequent that reporters post from dummy addresses,
    looking like randomly generated ones (we even had one looking
    like a smiley). It doesn't help to communicate with them at all.
    I can understand how some working as consultants for a customer
    would want to avoid disclosing a particular relation between their
    finding and their customer, but at least they should indicate how
    they should be called. I.e. "call me Margarett" is not difficult
    and simplifies exchanges when the address is "69236836@example.com".
    And often we see at the end that they're willing to provide a real
    name to be credited for the finding, so most likely starting with
    this real name could be easier.

  - it's more a discussion for the list itself, but the wording continues
    to make one think that the reporter should expect the list members to
    develop a patch, while in practise the first thing that's asked is
    "since you've studied the problem well, do you happen to have a patch?".
    And it happened a few times that in response we got "oops sorry, I
    analysed it wrong, there's no issue there". I think the text should
    emphasize more on encouraging submitters to complete their work with
    a patch proposal (that's also helpful to confirm an analysis). And
    conversely I think that reports for non-immediately exploitable issues
    that are found by code analyzers (and almost always come without a
    patch) should not be sent to this list and should be discussed and
    addressed publicly instead. It's more efficient and allows more
    knowledgeable participants to have their say on the root cause of
    the problem and its possible solutions. That's of course not always
    the case, but common sense should prevail here.

Thanks,
Willy

Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

On Mon, Mar 06, 2023 at 08:11:38AM +0100, Willy Tarreau wrote:
>   - I'm not seeing anywhere that the security list is *exclusively*
>     for kernel issues. That might explain why about once a week or so
>     we receive messages like "there's a bug in that userland tool" or
>     "we've found an XSS issue on your website". It's written that kernel
>     bugs should be reported to the security list but I think we should
>     strengthen that by adding "This list is exclusively used for Linux
>     kernel security reports, please do not report issues affecting any
>     other component there".

I think the wording would be "Please report security bugs against Linux
kernel to security@kernel.org list. Security bugs against userspace
applications should be reported to appropriate channels for affected
applications instead."

>   - it's quite frequent that reporters post from dummy addresses,
>     looking like randomly generated ones (we even had one looking
>     like a smiley). It doesn't help to communicate with them at all.
>     I can understand how some working as consultants for a customer
>     would want to avoid disclosing a particular relation between their
>     finding and their customer, but at least they should indicate how
>     they should be called. I.e. "call me Margarett" is not difficult
>     and simplifies exchanges when the address is "69236836@example.com".
>     And often we see at the end that they're willing to provide a real
>     name to be credited for the finding, so most likely starting with
>     this real name could be easier.
> 

Something like temporary addresses (à la maildrop or mail.gw)?

>   - it's more a discussion for the list itself, but the wording continues
>     to make one think that the reporter should expect the list members to
>     develop a patch, while in practise the first thing that's asked is
>     "since you've studied the problem well, do you happen to have a patch?".
>     And it happened a few times that in response we got "oops sorry, I
>     analysed it wrong, there's no issue there". I think the text should
>     emphasize more on encouraging submitters to complete their work with
>     a patch proposal (that's also helpful to confirm an analysis). And
>     conversely I think that reports for non-immediately exploitable issues
>     that are found by code analyzers (and almost always come without a
>     patch) should not be sent to this list and should be discussed and
>     addressed publicly instead. It's more efficient and allows more
>     knowledgeable participants to have their say on the root cause of
>     the problem and its possible solutions. That's of course not always
>     the case, but common sense should prevail here.

I think the wording would be "It is preferrable to have a proposed patch
for the bug you report. See
Documentation/process/submitting-patches.rst for details on how to
submit patches."

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Sun, Mar 05, 2023 at 11:00:03PM +0100, Vegard Nossum wrote:
> Hi,
> 
> This is v3 of clarifying our documentation for reporting security
> issues.
> 
> The current document is not clear enough, in particular the process of
> disclosure and requesting CVEs, and what the roles of the different
> lists are and how exactly to report to each of them.
> 
> Lots of people have been confused about the 7/14 days of the kernel list
> vs. the 7/14 days of the distros list, the fact that these are two
> separate lists, etc. Many reporters contact distros first, or submit
> their report to both lists at the same time (which has the unfortunate
> effect of starting off the disclosure countdown for the distros list
> before s@k.o has had a chance to look at the report). I've shared the v2
> document with a couple of people who submitted reports and they said
> they found it a lot clearer. 
> 

The docs LGTM, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]