All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Cc: Matt Wilson <msw@linux.com>,
	Ian Jackson <ijackson@chiark.greenend.org.uk>,
	xen-devel@lists.xenproject.org
Subject: Re: Security policy ambiguities - XSA-108 process post-mortem
Date: Mon, 10 Nov 2014 12:35:20 +0000	[thread overview]
Message-ID: <1415622920.25176.8.camel@citrix.com> (raw)
In-Reply-To: <0E6C0A5F-0FE6-42A6-BD57-60ADB3D21B82@gmail.com>

On Thu, 2014-11-06 at 16:01 +0000, Lars Kurth wrote:
> On 5 Nov 2014, at 11:17, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > 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.
> 
> I don't think that having applications discussed and processed on a
> dedicated public list and objective criteria are mutually exclusive.

I didn't say otherwise. In fact I said the opposite.

My concern was about the criteria being objective and not subjective,
regardless of who is processing them.

Nobody should be doing a "risk/benefit tradeoff to the security process
and the project" when processing an application. They should be going
through a list ticking boxes to show that the applicant has(n't) met
various criteria.

Ian.

  reply	other threads:[~2014-11-10 12:35 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
2014-11-06 16:01           ` Lars Kurth
2014-11-10 12:35             ` Ian Campbell [this message]
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=1415622920.25176.8.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=ijackson@chiark.greenend.org.uk \
    --cc=lars.kurth.xen@gmail.com \
    --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.