All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@linux.com>
Cc: xen-devel@lists.xenproject.org,
	Ian Jackson <ijackson@chiark.greenend.org.uk>
Subject: Re: Security policy ambiguities - XSA-108 process post-mortem
Date: Wed, 5 Nov 2014 11:17:52 +0000	[thread overview]
Message-ID: <1415186272.15317.5.camel@citrix.com> (raw)
In-Reply-To: <20141031224036.GA16669@u109add4315675089e695.ant.amazon.com>

On Fri, 2014-10-31 at 15:40 -0700, Matt Wilson wrote:
> I think that we should reduce any burden on the security team by
> making this a community decision that is discussed in public, rather
> than something that is handled exclusively in a closed manner as it is
> today. This way others who are active community participants can help
> with the decision making process can do the investigation and weigh in
> on the risk/benefit tradeoff to the security process and the
> project. See Message-ID: <20141021143053.GA22864@u109add4315675089e695.ant.amazon.com>
> or [1] if you are willing to visit a URL. ;-)
> 
> There's been a bit of talk about "delay" and so on. I'd rather not set
> expectations on how long the processing a petition to be added to the
> predisclosure list should take. Building community consensus takes
> time, just as it does for

I think regardless of who is processing the applications what is more
important is to have a concrete set of *objective* criteria. Anyone who
demonstrates that they meet those criteria must be allowed to join.

It reads to me as if you are instead are proposing that the community
apply some sort of subjective standard of risk/benefit tradeoffs and
building consensus about a new membership. I think to take that approach
(whether in public or private) would be against the previous steer from
the community that the list should be fairly widely inclusive -- there
will naturally be a tendency for those already inside the system to be
more conservative about allowing others to join (since it increases
their risk) and so they will tend (not even deliberately) to
overestimate the risk of allowing new memberships.

In the light of the discussions around sharing amongst predisclosure
list members and pre-embargo deployment I think the inclusive nature of
the list is an important balancing factor in the inherent disparity
between distro style consumers and service providers.

If we do not continue take an inclusive approach to the list membership
then my opinion on the matter of sharing and predeploying will be very
different.

>  other activities like getting a patch
> applied. I don't think that this process needs to be different.

I don't think this analogy is useful. It is rare that someone who has
had a patch accepted has any incentive to prevent another essentially
unrelated patch from being applied. Also, many of the reasons for not
taking a patch are subjective (coding style, taste, disagreements about
design issues, etc).

Ian.

  parent reply	other threads:[~2014-11-05 11:17 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08 15:54 Security policy ambiguities - XSA-108 process post-mortem Xen Project Security Team
2014-10-08 23:06 ` Ian Jackson
2014-10-08 23:55   ` Lars Kurth
2014-10-09  9:37     ` Ian Jackson
2014-10-09 11:24       ` George Dunlap
2014-10-09 16:19         ` Ian Campbell
2014-10-10 14:25         ` Jan Beulich
2014-10-13 12:17           ` George Dunlap
2014-10-29 13:27             ` James Bulpin
2015-01-19 20:36               ` James McKenzie
2015-01-20  8:54                 ` Jan Beulich
2015-01-20 12:29                 ` George Dunlap
2015-02-12 10:44                 ` Lars Kurth
2014-11-10 18:01     ` Ian Jackson
2014-11-11 12:39       ` John Haxby
2014-11-12 18:09       ` George Dunlap
2014-11-13 17:36         ` Ian Jackson
2014-11-14 12:10       ` Lars Kurth
2014-11-14 12:50         ` Ian Jackson
2014-11-14 17:37           ` Lars Kurth
2015-01-16 19:23         ` Ian Jackson
2015-01-16 19:48         ` [PATCH SECURITY-POLICY 0/9] " Ian Jackson
2015-01-16 19:52           ` [PATCH SECURITY-POLICY 1/9] Grammar fix: Remove a comma splice Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 2/9] Add headings Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 3/9] Deployment with Security Team Permission Ian Jackson
2015-01-19 10:20               ` Jan Beulich
2015-01-19 11:18                 ` Lars Kurth
2015-01-19 13:38                   ` Ian Jackson
2015-01-19 14:25                     ` Ian Campbell
2015-01-19 15:55                     ` George Dunlap
2015-01-19 19:48                       ` Lars Kurth
2015-01-19 12:36                 ` Ian Campbell
2015-01-19 13:50                   ` Jan Beulich
2015-01-19 12:35               ` Ian Campbell
2015-01-19 13:08                 ` Ian Jackson
2015-01-19 13:10                   ` Ian Campbell
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications Ian Jackson
2015-01-19 12:49               ` Ian Campbell
2015-01-19 13:10                 ` Ian Jackson
2015-01-19 13:19                   ` Ian Campbell
2015-01-19 16:21                     ` Don Koch
2015-01-19 17:57                     ` Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 5/9] Tighten, and make more objective, predisclosure list application Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 6/9] Explicitly permit within-list information sharing during embargo Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 7/9] Clarify and fix prior consultation text Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 8/9] Clarify what announcements may be made by to service users Ian Jackson
2015-01-16 19:52             ` [PATCH SECURITY-POLICY 9/9] Document changes in changelog and heading Ian Jackson
2015-01-19 10:29           ` [PATCH SECURITY-POLICY 0/9] Re: Security policy ambiguities - XSA-108 process post-mortem Jan Beulich
2015-01-19 13:36             ` Ian Jackson
2015-01-19 19:45               ` Lars Kurth
2015-01-19 14:57           ` George Dunlap
2015-01-23 19:31           ` [PATCH v2 SECURITY-POLICY 0/9] " Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 1/9] Grammar fix: Remove a comma splice Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 2/9] Add headings Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 3/9] Deployment with Security Team Permission Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 4/9] Use a public mailing list for predisclosure membership applications Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 5/9] Tighten, and make more objective, predisclosure list application Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 6/9] Explicitly permit within-list information sharing during embargo Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 7/9] Clarify and fix prior consultation text Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 8/9] Clarify what announcements may be made by to service users Ian Jackson
2015-01-23 19:31             ` [PATCH v2 SECURITY-POLICY 9/9] Document changes in changelog and heading Ian Jackson
2015-02-02 17:27             ` [PATCH v2 SECURITY-POLICY 0/9] Security policy ambiguities - XSA-108 process post-mortem Ian Jackson
2015-02-03  9:49               ` Lars Kurth
2014-10-09 11:09   ` George Dunlap
2014-10-10 14:47   ` Jan Beulich
2014-10-13 11:23     ` George Dunlap
2014-10-13 12:16     ` Lars Kurth
2014-11-10 17:25       ` Ian Jackson
2014-10-29 13:27     ` James Bulpin
2014-11-10 17:21     ` Ian Jackson
2014-10-21 12:32   ` Ian Campbell
2014-10-21 14:31     ` Matt Wilson
2014-10-21 15:06       ` Jan Beulich
2014-11-10 17:29       ` Ian Jackson
2014-11-10 17:39         ` George Dunlap
2014-11-10 18:04           ` Ian Jackson
2014-10-30 11:58     ` Ian Jackson
2014-10-31 22:40       ` Matt Wilson
2014-11-03 11:37         ` George Dunlap
2014-11-03 17:23           ` Matt Wilson
2014-11-05 11:17         ` Ian Campbell [this message]
2014-11-06 16:01           ` Lars Kurth
2014-11-10 12:35             ` Ian Campbell
2014-10-22 23:23   ` Bastian Blank
2014-10-29 13:27     ` James Bulpin
2014-11-10 17:42     ` Ian Jackson
2014-10-09  8:29 ` Ian Campbell
2014-10-09  8:45   ` Processed: " xen
2014-10-29 13:27 ` James Bulpin
2014-10-30 10:51   ` Tim Deegan
  -- strict thread matches above, loose matches on Subject: below --
2014-10-21 18:20 Lars Kurth
2014-10-22  0:41 ` Matt Wilson
2014-10-22 13:05   ` Lars Kurth
2014-10-22 15:53     ` Matt Wilson
2014-11-10 17:44       ` Ian Jackson

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=1415186272.15317.5.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=ijackson@chiark.greenend.org.uk \
    --cc=msw@linux.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.