All of
 help / color / mirror / Atom feed
From: Thomas Gleixner <>
To: Dave Hansen <>
Cc: Greg KH <>,
	Dave Hansen <>,,,,,,,,,,,
Subject: [PATCH] Documentation/process: Clarify disclosure rules
Date: Wed, 25 Sep 2019 10:29:49 +0200 (CEST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

The role of the contact list provided by the disclosing party and how it
affects the disclosure process and the ability to include experts into
the development process is not really well explained.

Neither is it entirely clear when the disclosing party will be informed
about the fact that a developer who is not covered by an employer NDA needs
to be brought in and disclosed.

Explain the role of the contact list and the information policy along with
an eventual conflict resolution better.

Reported-by: Dave Hansen <>
Signed-off-by: Thomas Gleixner <>
 Documentation/process/embargoed-hardware-issues.rst |   40 ++++++++++++++++----
 1 file changed, 33 insertions(+), 7 deletions(-)

--- a/Documentation/process/embargoed-hardware-issues.rst
+++ b/Documentation/process/embargoed-hardware-issues.rst
@@ -143,6 +143,20 @@ via their employer, they cannot enter in
 in their role as Linux kernel developers. They will, however, agree to
 adhere to this documented process and the Memorandum of Understanding.
+The disclosing party should provide a list of contacts for all other
+entities who have already been, or should be, informed about the issue.
+This serves several purposes:
+ - The list of disclosed entities allows communication accross the
+   industry, e.g. other OS vendors, HW vendors, etc.
+ - The disclosed entities can be contacted to name experts who should
+   participate in the mitigation development.
+ - If an expert which is required to handle an issue is employed by an
+   listed entity or member of an listed entity, then the response teams can
+   request the disclosure of that expert from that entity. This ensures
+   that the expert is also part of the entity's response team.
@@ -158,10 +172,7 @@ Mitigation development
 The initial response team sets up an encrypted mailing-list or repurposes
-an existing one if appropriate. The disclosing party should provide a list
-of contacts for all other parties who have already been, or should be,
-informed about the issue. The response team contacts these parties so they
-can name experts who should be subscribed to the mailing-list.
+an existing one if appropriate.
 Using a mailing-list is close to the normal Linux development process and
 has been successfully used in developing mitigations for various hardware
@@ -175,9 +186,24 @@ development branch against the mainline
 stable kernel versions as necessary.
 The initial response team will identify further experts from the Linux
-kernel developer community as needed and inform the disclosing party about
-their participation. Bringing in experts can happen at any time of the
-development process and often needs to be handled in a timely manner.
+kernel developer community as needed. Bringing in experts can happen at any
+time of the development process and needs to be handled in a timely manner.
+If an expert is employed by or member of an entity on the disclosure list
+provided by the disclosing party, then participation will be requested from
+the relevant entity.
+If not, then the disclosing party will be informed about the experts
+participation. The experts are covered by the Memorandum of Understanding
+and the disclosing party is requested to acknowledge the participation. In
+case that the disclosing party has a compelling reason to object, then this
+objection has to be raised within five work days and resolved with the
+incident team immediately. If the disclosing party does not react within
+five work days this is taken as silent acknowledgement.
+After acknowledgement or resolution of an objection the expert is disclosed
+by the incident team and brought into the development process.
 Coordinated release

  reply	other threads:[~2019-09-25  8:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10 17:26 [PATCH 0/4] Documentation/process: embargoed hardware issues additions Dave Hansen
2019-09-10 17:26 ` [PATCH 1/4] Documentation/process: Volunteer as the ambassador for Intel Dave Hansen
2019-09-10 17:26 ` [PATCH 2/4] Documentation/process: describe relaxing disclosing party NDAs Dave Hansen
2019-09-11 10:11   ` Sasha Levin
2019-09-11 14:11     ` Dave Hansen
2019-09-11 15:44   ` Greg KH
2019-09-11 16:09     ` Dave Hansen
2019-09-25  8:29       ` Thomas Gleixner [this message]
2019-09-25 15:53         ` [PATCH] Documentation/process: Clarify disclosure rules Dave Hansen
2019-09-29 10:42       ` [PATCH 2/4] Documentation/process: describe relaxing disclosing party NDAs Greg KH
2019-09-10 17:26 ` [PATCH 3/4] Documentation/process: soften language around conference talk dates Dave Hansen
2019-09-11 15:49   ` Greg KH
2019-09-10 17:26 ` [PATCH 4/4] Documentation/process: add transparency promise to list subscription Dave Hansen
2019-09-11 15:51   ` Greg KH
2019-09-16  8:30     ` Thomas Gleixner
2019-09-11 11:54 ` [PATCH 0/4] Documentation/process: embargoed hardware issues additions Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] Documentation/process: Clarify disclosure rules' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.