All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"committers@xenproject.org" <committers@xenproject.org>
Subject: Re: [PATCH] Minor security policy text changes to avoid ambiguity
Date: Tue, 7 May 2019 17:35:11 +0100	[thread overview]
Message-ID: <0926419c-c299-58d5-a2d3-4a575201a4bd@citrix.com> (raw)
In-Reply-To: <23673.17960.121848.487405@mariner.uk.xensource.com>

On 3/1/19 2:48 PM, Ian Jackson wrote:
> Lars Kurth writes ("[PATCH] Minor security policy text changes to avoid ambiguity"):
>> See http://xenbits.xen.org/gitweb/?p=people/larsk/governance.git;a=summary
>> for the repository.
> 
> I don't think in fact that there was previously any ambiguity.  The
> text in the policy two paragraphs earlier explains in detail, and
> entirely explicitly and without any room for doubt, that distribution
> is prohibited.
> 
> The misunderstanding arises through reading just the section on
> `deployment' out of context and then taking a wide reading of
> `deployment'.
> 
> This is a common failure mode with any kind of document: the document
> is long or the reader is in a hurry or stressed, so they do not read
> all of it; they look for the part that seems to apply to them and
> misunderstand it, in haste.  Also people tend to read what they want
> to hear.
> 
> Adding more text far from the site of the misunderstanding does
> nothing to help this.  Rather, it makes it worse: there is an
> antipattern in documents of this kind where every misunderstanding
> results in the addition of further repetitive text.  The document then
> becomes longer, and reading the whole thing becomes harder and also
> less worthwhile.
> 
> I think adding a small amount of text can be valuable, in important
> cases, if it is done right next to the site of the potential
> misunderstanding.  In this case I think that means something more like
> the patch below.
> 
> What do people think ?
> 
> Thanks,
> Ian.
> 
> 
> commit 35ad94db90eb6d926416deeaddf8cc19b0f46ef1
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Fri Mar 1 14:40:06 2019 +0000
> 
>     Avoid misunderstanding of `deploy'
> 
> diff --git a/security-policy.pandoc b/security-policy.pandoc
> index 8e07384..af285be 100644
> --- a/security-policy.pandoc
> +++ b/security-policy.pandoc
> @@ -213,9 +213,11 @@ List members are allowed to make available to their users only the following:
> -   The assigned XSA number
> -   The planned disclosure date
> 
> List members may, if (and only if) the Security Team grants
> permission, deploy fixed versions {+on their own services+} during the
> embargo.  {+(NB: Distribution of fixes is, mostly, prohibited; see above.)+}
> Permission for deployment, and any restrictions, will be stated in the
> embargoed advisory text.
> 
> The Security Team will normally permit such deployment, even for systems where
> VMs are managed or used by non-members of the predisclosure list. The Security
> 
> 
> 
> From 35ad94db90eb6d926416deeaddf8cc19b0f46ef1 Mon Sep 17 00:00:00 2001
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Date: Fri, 1 Mar 2019 14:40:06 +0000
> Subject: [PATCH] Avoid misunderstanding of `deploy'
> 
> ---
>  security-policy.pandoc | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/security-policy.pandoc b/security-policy.pandoc
> index 8e07384..af285be 100644
> --- a/security-policy.pandoc
> +++ b/security-policy.pandoc
> @@ -213,9 +213,11 @@ List members are allowed to make available to their users only the following:
>  -   The assigned XSA number
>  -   The planned disclosure date
>  
> -List members may, if (and only if) the Security Team grants permission, deploy
> -fixed versions during the embargo. Permission for deployment, and any
> -restrictions, will be stated in the embargoed advisory text.
> +List members may, if (and only if) the Security Team grants
> +permission, deploy fixed versions on their own services during the
> +embargo.  (NB: Distribution of fixes is, mostly, prohibited; see above.)
> +Permission for deployment, and any restrictions, will be stated in the
> +embargoed advisory text.

This change looks good to me -- has it been committed yet?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

WARNING: multiple messages have this Message-ID (diff)
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"committers@xenproject.org" <committers@xenproject.org>
Subject: Re: [Xen-devel] [PATCH] Minor security policy text changes to avoid ambiguity
Date: Tue, 7 May 2019 17:35:11 +0100	[thread overview]
Message-ID: <0926419c-c299-58d5-a2d3-4a575201a4bd@citrix.com> (raw)
Message-ID: <20190507163511.KnBh62bYGUBpL0JVMmKzrhxH9s8Q-oVVFB7ZyuPG5iQ@z> (raw)
In-Reply-To: <23673.17960.121848.487405@mariner.uk.xensource.com>

On 3/1/19 2:48 PM, Ian Jackson wrote:
> Lars Kurth writes ("[PATCH] Minor security policy text changes to avoid ambiguity"):
>> See http://xenbits.xen.org/gitweb/?p=people/larsk/governance.git;a=summary
>> for the repository.
> 
> I don't think in fact that there was previously any ambiguity.  The
> text in the policy two paragraphs earlier explains in detail, and
> entirely explicitly and without any room for doubt, that distribution
> is prohibited.
> 
> The misunderstanding arises through reading just the section on
> `deployment' out of context and then taking a wide reading of
> `deployment'.
> 
> This is a common failure mode with any kind of document: the document
> is long or the reader is in a hurry or stressed, so they do not read
> all of it; they look for the part that seems to apply to them and
> misunderstand it, in haste.  Also people tend to read what they want
> to hear.
> 
> Adding more text far from the site of the misunderstanding does
> nothing to help this.  Rather, it makes it worse: there is an
> antipattern in documents of this kind where every misunderstanding
> results in the addition of further repetitive text.  The document then
> becomes longer, and reading the whole thing becomes harder and also
> less worthwhile.
> 
> I think adding a small amount of text can be valuable, in important
> cases, if it is done right next to the site of the potential
> misunderstanding.  In this case I think that means something more like
> the patch below.
> 
> What do people think ?
> 
> Thanks,
> Ian.
> 
> 
> commit 35ad94db90eb6d926416deeaddf8cc19b0f46ef1
> Author: Ian Jackson <ian.jackson@eu.citrix.com>
> Date:   Fri Mar 1 14:40:06 2019 +0000
> 
>     Avoid misunderstanding of `deploy'
> 
> diff --git a/security-policy.pandoc b/security-policy.pandoc
> index 8e07384..af285be 100644
> --- a/security-policy.pandoc
> +++ b/security-policy.pandoc
> @@ -213,9 +213,11 @@ List members are allowed to make available to their users only the following:
> -   The assigned XSA number
> -   The planned disclosure date
> 
> List members may, if (and only if) the Security Team grants
> permission, deploy fixed versions {+on their own services+} during the
> embargo.  {+(NB: Distribution of fixes is, mostly, prohibited; see above.)+}
> Permission for deployment, and any restrictions, will be stated in the
> embargoed advisory text.
> 
> The Security Team will normally permit such deployment, even for systems where
> VMs are managed or used by non-members of the predisclosure list. The Security
> 
> 
> 
> From 35ad94db90eb6d926416deeaddf8cc19b0f46ef1 Mon Sep 17 00:00:00 2001
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Date: Fri, 1 Mar 2019 14:40:06 +0000
> Subject: [PATCH] Avoid misunderstanding of `deploy'
> 
> ---
>  security-policy.pandoc | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/security-policy.pandoc b/security-policy.pandoc
> index 8e07384..af285be 100644
> --- a/security-policy.pandoc
> +++ b/security-policy.pandoc
> @@ -213,9 +213,11 @@ List members are allowed to make available to their users only the following:
>  -   The assigned XSA number
>  -   The planned disclosure date
>  
> -List members may, if (and only if) the Security Team grants permission, deploy
> -fixed versions during the embargo. Permission for deployment, and any
> -restrictions, will be stated in the embargoed advisory text.
> +List members may, if (and only if) the Security Team grants
> +permission, deploy fixed versions on their own services during the
> +embargo.  (NB: Distribution of fixes is, mostly, prohibited; see above.)
> +Permission for deployment, and any restrictions, will be stated in the
> +embargoed advisory text.

This change looks good to me -- has it been committed yet?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-05-07 16:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 13:55 [PATCH] Minor security policy text changes to avoid ambiguity Lars Kurth
2019-03-01 14:03 ` Andrew Cooper
2019-03-01 14:11 ` George Dunlap
2019-03-01 14:48 ` Ian Jackson
2019-05-07 16:35   ` George Dunlap [this message]
2019-05-07 16:35     ` [Xen-devel] " George Dunlap

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=0926419c-c299-58d5-a2d3-4a575201a4bd@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=committers@xenproject.org \
    --cc=ian.jackson@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.