[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem



On Thu, Oct 30, 2014 at 11:58:30AM +0000, Ian Jackson wrote:

[...]

> I think that people who want to be on the predisclosure list should
> make matters easy for the security team.  I think it therefore is only
> fair to say that an application might be delayed if the team member
> who happens to deal with the application can't conveniently access the
> evidence that the applicant is supposed to provide.

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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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 other activities like getting a patch
applied. I don't think that this process needs to be different.

> And that an application might be rejected entirely if insufficiently
> many members of the team are able to access, and hence verify, the
> information provided.
> 
> 
> Or to put it another way: if the Xen Project community decides to
> reject an explicit statement along the lines I propose above, that
> won't mean that I will put my own security and privacy at risk when
> dealing with predisclosure list applications.
>
> So those applications might be delayed anyway, unless other members of
> the team want to take up the slack.  Of course if the community
> doesn't like my attitude, they're free to get rid of me.

I believe that others would be happy to take up the slack, but they
may not be members of the security team. I'd rather the security team
be able to focus on the matters of preparing fixes and managing
security embargoes, and not have to spend precious time on this aspect
of the policy.

--msw

[1] 
http://lists.xenproject.org/archives/html/xen-devel/2014-10/threads.html#02532

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.