Security policy ambiguities - XSA-108 process post-mortem

[Xen Project Security Team]

create !
thanks

XSA-108 had a lot of media coverage and generated a lot of interest of
various kinds. This ended up stress-testing some of our policy and
processes. During the embargo period the Xen Project Security Team
were faced with some difficult questions of policy interpretation.

Additionally, during the embargo period we had to hastily formalise
our internal tracking arrangements for predisclosure list membership
applications. We intend to further streamline that system.


A summary of the policy questions, and the answers we gave, is below.
We hope that the community will work towards improving the policy. As
the Security Team, our role is to implement the policy, not to set it,
so in this message we don't take a position on how the policy should
be clarified.

The Security Team expects that members of the Xen Project community
will respond to this thread (or other threads on this subject) with
everything from discussion of matters of principle to specific wording
proposals.

We welcome any feedback on our decisions and we look forward to
clearer directions from the community.

Thanks,
Xen Project Security Team.


Sharing amongst predisclosure list members
==========================================

The policy says:

Specifically, prior to the embargo date, pre-disclosure list members
should not make available, even to their own customers and partners:
...
* patched software (even in binary form) without prior
consultation with ***@xenproject and/or the discoverer.

It is (still!) ambiguous whether predisclosure list members may share
fixes and other information with other predisclosure list members. We
intended to fix this ambiguity following the XSA-7 discussion but
the policy was never updated.

During the XSA-108 embargo the Security Team were asked whether this
permitted; we concluded that since we had said `yes' last time, and
documented this in the XSA-7 postmortem, and the community had failed
to change the policy, we should probably say `yes' again.

The community should formally correct this ambiguity.


Deployment on public systems of fixed versions during embargo
=============================================================

It is ambiguous whether the wording above prohibits deployment by a
service provider of patched hosting software running customer VMs.
Some predisclosure list members thought that this was prohibited;
others thought that it was permitted and accordingly deployed the
XSA-108 fix during the embargo.

This question should be resolved, clearly, one way or the other.


Service announcements to non-list-member users during embargo
=============================================================

The policy says:

List members are allowed to make available to their users only the
following:

* The existance of an issue
* The assigned XSA number
* The planned disclosure date

During the XSA-108 embargo, some service providers wished to make
announcements to their users, for example to notify their users that
their VMs will be rebooted. The Security Team received enquiries
asking whether that was permitted; observing that some other providers
had read the policy as permitting this and already made such
announcements, we replied saying that we did not object.

The situation should be clarified.


Predisclosure list memembership
===============================

The Xen Project's policy wording on predisclosure list membership was
ambiguous and difficult for the team to work with. In general when
the rules were ambiguous we tended towards approving applications
which appeared to be from genuine entities, seemed to be applying in
good faith, and who seemed to meet what we saw as the general
principles behind the rules.


Questions which arose include:

Applicants who do not have a public security policy. The Xen Project
security policy asks for `A link to a web page with your security
policy statement' but doesn't explain what a `security policy
statement' is. We received a number of applications accompanied by
links to a wide variety of kinds of web pages, including privacy
policies and other documents which do not easily fit into what one
would think of as a `security policy statement'. Under the
circumstances we ended up mostly waiving this requirement because it
was difficult to pin down the meaning.

Applicants who do not provide a public security reporting address.
This makes it difficult for the Xen Project Security Team to verify
that the people emailing us are properly authorised. It also invites
entities to benefit from the Xen Project's mature security response
process even when they themselves are so irresponsible as to provide
no way for members of the public to responsibly report security
problems.

Applicants where it is not clear whether they actually use Xen; or, if
Xen is mentioned, where it is unclear how they use it. The Security
Team spent some time hunting through some applicants' websites and/or
doing websearches to verify whether each applicant actually qualified.
This is not a workable process (especially in crises).

Applicants where the delivery scope of the provided email alias is or
appears to be wider than the policy contemplates. The Security Team
sometimes made enquiries with applicants about the distribution of
these aliases. The responses received are of course not verifiable
by the Team.

Verifying the status and eligiblity of applicants was therefore a
difficult and tedious process. Partly because applicants didn't
always supply the information in the most convenient format; partly
because the information wasn't always on applicants' websites; and
partly simply because some applicants websites were frustratingly
difficult to navigate.


There were three categories of applicant where we felt the policy
required us to reject the application:

Applicants who mentioned proof of concept, experimental or research
Xen setups in support of their application, and did not appear to have
(or be distributing) any Xen deployed in production.

Providers of ancillary software (eg, installers, control panels) who
did not themselves provide modified versions of Xen, but rely on
distro or vendor Xen packages.

Consultants or contractors who may help users configure and manage
systems - although we did tell these that their users might qualify in
their own right.


We hope that the community will set a clearer policy which allows for
straightforward decisionmaking on predisclosure list applications.


--

[Ian Jackson]

Post by Xen Project Security Team
We welcome any feedback on our decisions and we look forward to
clearer directions from the community.

Here is my own, purely personal, response with answers to the
questions asked. NB that this is not the opinion of Citrix nor of
the Xen Project Security Team. But I thought I would at least write
down something concrete for people to argue about.

Post by Xen Project Security Team
Sharing amongst predisclosure list members

I think that the answer should be `yes', in principle. There seems
little point forbidding this.

Allowing greater sharing would perhaps allow problems with patches to
be discovered (and the revised patches developed) more easily. We
should provide a clear channel for collaboration between predisclosure
list members.

Therefore, the policy should be extended by adding, before
`Organisations who meet the criteria', the new section:

List members are allowed to share fixes to embargoed issues,
analysis, etc., with the security teams of other list members.
Technical measures must be taken to prevents non-list-member
organisations, or unauthorised staff in list-member organisations,
from obtaining the embargoed materials.

The Xen Project provides the mailing list
xen-security-issues-***@lists.xenproject.org
for this purpose. List members are encouraged to use it but
may share with other list members' security teams via other
channels.

The -discuss list's distribution is identical to that of the primary
predisclosure list xen-security-issues. Recipient organisations who
do not wish to receive all of the traffic on -discuss should use
recipient-side email filtering based on the provided `List-Id'.

The -discuss list is moderated by the Xen Project Security Team.
Announcements of private availability of fixed versions, and
technical messages about embargoed advisories, will be approved.
Messages dealing with policy matters will be rejected with a
reference to the Security Team contact address and/or public Xen
mailing lists.

(That list obviously doesn't exist yet, but if the policy is approved
we will create it.)

One reason for permitting this is that we want fairness between
service providers who use their own versions of Xen, and ones who use
a version from a software provider. Both kinds of service provider
should be able to test the fix during the embargo.

Post by Xen Project Security Team
Deployment on public systems of fixed versions during embargo

These different understandings have led to some bad feelings - some
people feel that others have breached the embargo, while they felt
prevented from acting similarly. This is very regrettable and I
apologise for my contribution to the unclarity in the policy.

I want to say clearly that I think everyone has acted in good faith.

My view is that the policy should be clarified to permit deployment
during embargo. I see no practical reason for preventing it. I would
add, following that list of bullet points:

List members who are service providers may deploy fixed versions
during the embargo, PROVIDED THAT any action taken by the service
provider gives no indication (to their users or anyone else) as to
the nature of the vulnerability.

This question is IMO partly linked to the previous one.


The Security Team should not be invited to give permission
specifically for the release of patched software. I think the rider
was mistakenly merged into the final the bullet point in the list. It
should be separated out. Also, the predisclosure list members should
not be invited to consult the discoverer.

The note about CVE numbers should be moved into the list of
forbidden-disclosures, as a new bullet point. So overall I would
delete that whole paragraph about CVEs (we don't need the historical
information) and adjust the end of the forbidden disclosures to read:

...
* patched software (even in binary form)
* CVE number(s)

Post by Xen Project Security Team
Service announcements to non-list-member users during embargo

We should add just below the list of bullet points of things which may
be disclosed:

Where the list member is a service provider who intends to take
disruptive action such as rebooting as part of deploying a fix (see
above): the list member's communications to its users about the
service disruption may mention that the disruption is to correct a
security issue, and relate it to the public information about the
issue (as listed above).

Post by Xen Project Security Team
Predisclosure list memembership

The policy should be amended to require applicants to provide the
information required, in the form of public URLs. The team should not
be required to judge email aliases or enquire about their recipients
except to ensure that they don't look like personal aliases.

Applicants should be required to:

- Provide information on their public web pages which makes
it clear that and why they are eligible;

- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);

- Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.

The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.


Specifically, I propose that the section on list membership
applications be entirely replaced with this:

Organisations who meet the criteria should contact
***@xenproject if they wish to receive pre-disclosure of
advisories. You must include in the e-mail:

* The name of your organization.

* Domain name(s) which you use to provide Xen software/services.

* A brief description of why you fit the criteria.

* If not all of your products/services use Xen, a list of (some
of) your products/services (or categories thereof) which do.

* Link(s) to current public web pages, belonging to your
organisation, for each of following pieces of information:

o Evidence of your status as a service/software provider:
+ If you are a public hosting provider, your public rates
or how to get a quote
+ If you are a software provider, how your
software can be downloaded or purchased
+ If you are an open-source project, a mailing list
archive and/or version control repository, with
active development

o Evidence of your status as a user of Xen:
+ Statements about, or descriptions of, your eligible
production services or released software, from which it is
immediately evident that they use Xen.

o Information about your handling of security problems:
+ Your invitation to members of the public, who discover
security problems with your products/services, to report
them in confidence to you;
+ Specifically, the contact information (email addresses or
other contact instructions) which such a member of the
public should use.

Blog postings, conference presentations, social media pages,
Flash presentations, videos, sites which require registration,
anything password-protected, etc., are not acceptable. PDFs of
reasonable size are acceptable so long as the URL you provide is
of a ordinary HTML page providing a link to the PDF.

If the pages are long and/or PDFs are involved, your email
should say which part of the pages and documents are relevant.

* A statement to the effect that you have read this policy and
agree to abide by the terms for inclusion in the list,
specifically the requirements regarding confidentiality during
an embargo period.

* The single (non-personal) email alias you wish added to the
predisclosure list.

The Security Team has no discretion to accept applications which do
not provide all of the information required above.

Please provide URLs which are accessible and legible on mobile phone
browsers, which do not require cookies enabled to load, and which
are useable with text mode browsers, browsers which do not execute
Javascript, and with screen readers and other accessibility
software. If the member of the Xen Project Security Team who
processes your application finds that their usual web browser does
not display the required information, when presented with the URLs
in your email, your application might be delayed or even rejected.


Ian.

[Lars Kurth]

Post by Ian Jackson

Post by Xen Project Security Team
We welcome any feedback on our decisions and we look forward to
clearer directions from the community.

Here is my own, purely personal, response with answers to the
questions asked. NB that this is not the opinion of Citrix nor of
the Xen Project Security Team. But I thought I would at least write
down something concrete for people to argue about.

Post by Xen Project Security Team
Sharing amongst predisclosure list members

I think that the answer should be `yes', in principle. There seems
little point forbidding this.
Allowing greater sharing would perhaps allow problems with patches to
be discovered (and the revised patches developed) more easily. We
should provide a clear channel for collaboration between predisclosure
list members.
Therefore, the policy should be extended by adding, before
List members are allowed to share fixes to embargoed issues,
analysis, etc., with the security teams of other list members.
Technical measures must be taken to prevents non-list-member
organisations, or unauthorised staff in list-member organisations,
from obtaining the embargoed materials.
The Xen Project provides the mailing list
for this purpose. List members are encouraged to use it but
may share with other list members' security teams via other
channels.
The -discuss list's distribution is identical to that of the primary
predisclosure list xen-security-issues. Recipient organisations who
do not wish to receive all of the traffic on -discuss should use
recipient-side email filtering based on the provided `List-Id'.
The -discuss list is moderated by the Xen Project Security Team.
Announcements of private availability of fixed versions, and
technical messages about embargoed advisories, will be approved.
Messages dealing with policy matters will be rejected with a
reference to the Security Team contact address and/or public Xen
mailing lists.
(That list obviously doesn't exist yet, but if the policy is approved
we will create it.)

Ian, this is a very good suggestion.

Post by Ian Jackson
One reason for permitting this is that we want fairness between
service providers who use their own versions of Xen, and ones who use
a version from a software provider. Both kinds of service provider
should be able to test the fix during the embargo.

Post by Xen Project Security Team
Deployment on public systems of fixed versions during embargo

These different understandings have led to some bad feelings - some
people feel that others have breached the embargo, while they felt
prevented from acting similarly. This is very regrettable and I
apologise for my contribution to the unclarity in the policy.
I want to say clearly that I think everyone has acted in good faith.
My view is that the policy should be clarified to permit deployment
during embargo. I see no practical reason for preventing it.

I agree. If we didn’t allow deployment during an embargo a lot more users would be at risk.

However, in this context we do need to look at a number of questions:
a) Risk of someone reverse engineering the vulnerability during deployment.
b) GPL (or license) compliance - this may be a non-issue, but I would like to get some advice on it.

In the case of XSA 108 both were not an issue, because the hypervisor is not accessible by a user of a cloud provider.
However, if the vulnerability had been in another component this may be different.

Post by Ian Jackson
I would
List members who are service providers may deploy fixed versions
during the embargo, PROVIDED THAT any action taken by the service
provider gives no indication (to their users or anyone else) as to
the nature of the vulnerability.

I think this does text does not address a) and b)

Post by Ian Jackson
This question is IMO partly linked to the previous one.
The Security Team should not be invited to give permission
specifically for the release of patched software. I think the rider
was mistakenly merged into the final the bullet point in the list. It
should be separated out. Also, the predisclosure list members should
not be invited to consult the discoverer.
The note about CVE numbers should be moved into the list of
forbidden-disclosures, as a new bullet point. So overall I would
delete that whole paragraph about CVEs (we don't need the historical
...
* patched software (even in binary form)
* CVE number(s)

Post by Xen Project Security Team
Service announcements to non-list-member users during embargo

We should add just below the list of bullet points of things which may
Where the list member is a service provider who intends to take
disruptive action such as rebooting as part of deploying a fix (see
above): the list member's communications to its users about the
service disruption may mention that the disruption is to correct a
security issue, and relate it to the public information about the
issue (as listed above).

Post by Xen Project Security Team
Predisclosure list memembership

The policy should be amended to require applicants to provide the
information required, in the form of public URLs. The team should not
be required to judge email aliases or enquire about their recipients
except to ensure that they don't look like personal aliases.
- Provide information on their public web pages which makes
it clear that and why they are eligible;
- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);
- Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.
The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.
Specifically, I propose that the section on list membership
Organisations who meet the criteria should contact
* The name of your organization.
* Domain name(s) which you use to provide Xen software/services.
* A brief description of why you fit the criteria.
* If not all of your products/services use Xen, a list of (some
of) your products/services (or categories thereof) which do.
* Link(s) to current public web pages, belonging to your
+ If you are a public hosting provider, your public rates
or how to get a quote
+ If you are a software provider, how your
software can be downloaded or purchased
+ If you are an open-source project, a mailing list
archive and/or version control repository, with
active development
+ Statements about, or descriptions of, your eligible
production services or released software, from which it is
immediately evident that they use Xen.
+ Your invitation to members of the public, who discover
security problems with your products/services, to report
them in confidence to you;
+ Specifically, the contact information (email addresses or
other contact instructions) which such a member of the
public should use.
Blog postings, conference presentations, social media pages,
Flash presentations, videos, sites which require registration,
anything password-protected, etc., are not acceptable. PDFs of
reasonable size are acceptable so long as the URL you provide is
of a ordinary HTML page providing a link to the PDF.
If the pages are long and/or PDFs are involved, your email
should say which part of the pages and documents are relevant.
* A statement to the effect that you have read this policy and
agree to abide by the terms for inclusion in the list,
specifically the requirements regarding confidentiality during
an embargo period.
* The single (non-personal) email alias you wish added to the
predisclosure list.
The Security Team has no discretion to accept applications which do
not provide all of the information required above.

This is a good list.
I do think we should test this though to make sure it actually works. I think there are a few areas which may be ambiguous or not clear enough.

I also think we do need to address websites in non-english languages would be handled. Of course we do not want to discriminate.

Post by Ian Jackson
Please provide URLs which are accessible and legible on mobile phone
browsers, which do not require cookies enabled to load, and which
are useable with text mode browsers, browsers which do not execute
Javascript, and with screen readers and other accessibility
software. If the member of the Xen Project Security Team who
processes your application finds that their usual web browser does
not display the required information, when presented with the URLs
in your email, your application might be delayed or even rejected.
Ian.
_______________________________________________
Xen-devel mailing list
http://lists.xen.org/xen-devel

[Ian Jackson]

Post by Lars Kurth

Post by Ian Jackson
My view is that the policy should be clarified to permit deployment
during embargo. I see no practical reason for preventing it.

I agree. If we didn’t allow deployment during an embargo a lot more
users would be at risk.
a) Risk of someone reverse engineering the vulnerability during deployment.

This is what my caveat is intended to address.

Post by Lars Kurth
b) GPL (or license) compliance - this may be a non-issue, but I
would like to get some advice on it.

Feel free to get advice but I can assure you that this is a
non-issue.

Post by Lars Kurth
In the case of XSA 108 both were not an issue, because the hypervisor is not accessible by a user of a cloud provider.
However, if the vulnerability had been in another component this may be different.

If the vulnerability were in a component that were distributed to the
users then 1. the GPL would be engaged 2. my caveat would be violated.

Post by Lars Kurth

Post by Ian Jackson
List members who are service providers may deploy fixed versions
during the embargo, PROVIDED THAT any action taken by the service
provider gives no indication (to their users or anyone else) as to
the nature of the vulnerability.

I think this does text does not address a) and b)

It may be that this wording should be improved since obviously it
isn't clear enough.

Post by Lars Kurth

Post by Ian Jackson
The Security Team has no discretion to accept applications which do
not provide all of the information required above.

This is a good list.
I do think we should test this though to make sure it actually works. I think there are a few areas which may be ambiguous or not clear enough.

It might be worth looking at constructing some some hypothetical or
historical applications and judging them against these criteria.

Post by Lars Kurth
I also think we do need to address websites in non-english languages
would be handled. Of course we do not want to discriminate.

So far, what the security team have done is use online machine
translation services. That seems to have been sufficient so far.

Ian.

[George Dunlap]

On Thu, Oct 9, 2014 at 10:37 AM, Ian Jackson

Post by Ian Jackson

Post by Lars Kurth

Post by Ian Jackson
My view is that the policy should be clarified to permit deployment
during embargo. I see no practical reason for preventing it.

I agree. If we didn’t allow deployment during an embargo a lot more
users would be at risk.
a) Risk of someone reverse engineering the vulnerability during deployment.

This is what my caveat is intended to address.

That's not how I understood your caveat (assuming you mean
"...PROVIDED THAT any action taken by the service provider gives no
indication (to their users or anyone else) as to the nature of the
vulnerability.")

Just to be clear what I'm talking about (and what I think Lars is
talking about): Say that there was a fix that was expected to have
noticeable effects on existing functionality -- for example, breaking
certain (obscure but occasionally used) configurations, or having a
measurable performance impact on certain not-uncommon workloads. This
might clue the attacker in to what code to audit to try to find the
vulnerability.

For one, your caveat is pretty ambiguous: many people took Amazon's
rebooting to mean that it was a really serious vulnerability (i.e.,
privilege escalation). In this case that turned out to be wrong, but
what it if *had* been for a bug like XSA-7? Would that constitute
"giving indication as to the nature of the vulnerability"?

For two, I would have interpreted this about other actions surrounding
the deployment, not actually the deployment itself.

I think that the security team should attempt to determine whether
pre-disclosure deployment might give away too much information, and
specifically say in each advisory whether early deployment is allowed
or not, potentially with specifications about what kind of deployments
will be allowed (if necessary). Most of the time this will just be,
"Rebooting servers to deploy this fix is allowed", but it leaves the
option open to change it if necessary.

-George

[Ian Campbell]

Post by George Dunlap
On Thu, Oct 9, 2014 at 10:37 AM, Ian Jackson

Post by Ian Jackson

Post by Lars Kurth

Post by Ian Jackson
My view is that the policy should be clarified to permit deployment
during embargo. I see no practical reason for preventing it.

I agree. If we didn’t allow deployment during an embargo a lot more
users would be at risk.
a) Risk of someone reverse engineering the vulnerability during deployment.

This is what my caveat is intended to address.

That's not how I understood your caveat (assuming you mean
"...PROVIDED THAT any action taken by the service provider gives no
indication (to their users or anyone else) as to the nature of the
vulnerability.")
Just to be clear what I'm talking about (and what I think Lars is
talking about): Say that there was a fix that was expected to have
noticeable effects on existing functionality -- for example, breaking
certain (obscure but occasionally used) configurations, or having a
measurable performance impact on certain not-uncommon workloads. This
might clue the attacker in to what code to audit to try to find the
vulnerability.

I was wondering about this sort of thing too.

We don't want to leave this up to individual list members, otherwise we
are back in the situation where two members reach different conclusions
and one of them ends up feeling aggrieved. Plus I don't think we can
expect all list members to have the technical understanding to make that
call in the first place.

Ian.

Post by George Dunlap
For one, your caveat is pretty ambiguous: many people took Amazon's
rebooting to mean that it was a really serious vulnerability (i.e.,
privilege escalation). In this case that turned out to be wrong, but
what it if *had* been for a bug like XSA-7? Would that constitute
"giving indication as to the nature of the vulnerability"?
For two, I would have interpreted this about other actions surrounding
the deployment, not actually the deployment itself.
I think that the security team should attempt to determine whether
pre-disclosure deployment might give away too much information, and
specifically say in each advisory whether early deployment is allowed
or not, potentially with specifications about what kind of deployments
will be allowed (if necessary). Most of the time this will just be,
"Rebooting servers to deploy this fix is allowed", but it leaves the
option open to change it if necessary.
-George
_______________________________________________
Xen-devel mailing list
http://lists.xen.org/xen-devel

[Jan Beulich]

Post by George Dunlap
I think that the security team should attempt to determine whether
pre-disclosure deployment might give away too much information, and
specifically say in each advisory whether early deployment is allowed
or not, potentially with specifications about what kind of deployments
will be allowed (if necessary). Most of the time this will just be,
"Rebooting servers to deploy this fix is allowed", but it leaves the
option open to change it if necessary.

We're sometimes already struggling determining the set of
consequences a certain issue may have (see statements like
"... cannot be excluded"). I think anticipating what sufficiently
"qualified" people may be able to guess from early deployment
would end up being rather difficult.

Jan

[George Dunlap]

Post by Jan Beulich

Post by George Dunlap
I think that the security team should attempt to determine whether
pre-disclosure deployment might give away too much information, and
specifically say in each advisory whether early deployment is allowed
or not, potentially with specifications about what kind of deployments
will be allowed (if necessary). Most of the time this will just be,
"Rebooting servers to deploy this fix is allowed", but it leaves the
option open to change it if necessary.

We're sometimes already struggling determining the set of
consequences a certain issue may have (see statements like
"... cannot be excluded"). I think anticipating what sufficiently
"qualified" people may be able to guess from early deployment
would end up being rather difficult.

Perhaps -- but it seems to me to be the least risky of all the alternatives.

As far as I can tell we basically have the following options:

1. Never allow people to deploy during the embargo period.

This eliminates the possibility that someone will be helped to gain
information about the vulnerability by comparing a patched system to an
unpatched one. However, it means that cloud operators may spend a short
amount of time "publicly vulnerable" while they reboot their systems. I
assume it would significantly increase the difficulty of coordinating
such a deployment, as you would have to reboot *all* your servers in the
smallest time window possible, instead of being able to stage it over
several days.

It also increases the temptation for operators to "cheat" by starting
the process a little bit early. This I think could lead to more
significant problems community-wise: with incentive to break the rules,
enforcement becomes an issue -- and I'm sure none of the team want to
have to deal with that.

2. Always allow people to deploy during the embargo period.

This is simple on the security team, and minimizes the "publicly
vulnerable time". It makes deployments easier to coordinate, and avoids
adding an incentive for "bending" the rules.

However, it does in theory allow an attacker the ability to gain
information about the vulnerability by comparing patched systems to
unpatched systems. In practice, the vast majority of the time the
measurable difference in functionality will be like finding a needle in
a haystack; and if the attacker had ever even thought to try the
functionality (e.g., XSA-7), she would have already known about the
bug. But that may not always be the case.

3. Have the security team attempt to evaluate the risk.

This adds work to the security team. But it at least allows the
possibility that, in cases where it's pretty clear that early deployment
*would* give clear hints to an attacker, they could decide to include
deployment in the embargo.

4. Have individual cloud operators evaluate the risk.

This seems like a recipe for disaster.

I think #1 is too risky, particularly from a community perspective. But
maybe I'm being a bit pessimistic.

In my mind, #3 is basically exactly the same as #2, except that in cases
where there would clearly be a problem, the team has an option of
embargoing deployment as well.

I just spent about 10 minutes skimming through the 80 or so XSAs on
http://xenbits.xen.org/xsa/. In most of the cases, it was pretty clear
that the only behavior that changed would be behavior which would
already have clued an attacker into the existence of a potential
vulnerability. For example, in XSA-108, beforehand some reads from the
reserved x2apic range would have returned values whereas now they would
#GP. But if the attacker knew that they returned values, it already
would have occurred to her to see if they returned anything of interest.

I didn't notice a single exception to this, though admittedly I didn't
spend much time looking at it.

This suggests to me that #2 is probably not that dangerous the majority
of the time. It also suggests that there may be a simple criteria that
can be applied for #3 that can eliminate most of the guesswork: Is
anything in the original behavior being changed likely to lead an
attacker to think that there may be a vulnerability there? In the case
of basically all of them, I think the answer there would be "yes".

So at the moment I would favor #3, then #2; I'm not in favor of #1 but I
wouldn't strenuously argue against it. But the main thing is that we
have a clear policy.

-George

[James Bulpin]

[snip]
1. Never allow people to deploy during the embargo period.
This eliminates the possibility that someone will be helped to gain
information about the vulnerability by comparing a patched system to an
unpatched one. However, it means that cloud operators may spend a short
amount of time "publicly vulnerable" while they reboot their systems. I
assume it would significantly increase the difficulty of coordinating
such a deployment, as you would have to reboot *all* your servers in the
smallest time window possible, instead of being able to stage it over
several days.
It also increases the temptation for operators to "cheat" by starting
the process a little bit early. This I think could lead to more
significant problems community-wise: with incentive to break the rules,
enforcement becomes an issue -- and I'm sure none of the team want to
have to deal with that.
2. Always allow people to deploy during the embargo period.
This is simple on the security team, and minimizes the "publicly
vulnerable time". It makes deployments easier to coordinate, and avoids
adding an incentive for "bending" the rules.
However, it does in theory allow an attacker the ability to gain
information about the vulnerability by comparing patched systems to
unpatched systems. In practice, the vast majority of the time the
measurable difference in functionality will be like finding a needle in
a haystack; and if the attacker had ever even thought to try the
functionality (e.g., XSA-7), she would have already known about the
bug. But that may not always be the case.
3. Have the security team attempt to evaluate the risk.
This adds work to the security team. But it at least allows the
possibility that, in cases where it's pretty clear that early deployment
*would* give clear hints to an attacker, they could decide to include
deployment in the embargo.
4. Have individual cloud operators evaluate the risk.
This seems like a recipe for disaster.
I think #1 is too risky, particularly from a community perspective. But
maybe I'm being a bit pessimistic.
In my mind, #3 is basically exactly the same as #2, except that in cases
where there would clearly be a problem, the team has an option of
embargoing deployment as well.
I just spent about 10 minutes skimming through the 80 or so XSAs on
http://xenbits.xen.org/xsa/. In most of the cases, it was pretty clear
that the only behavior that changed would be behavior which would
already have clued an attacker into the existence of a potential
vulnerability. For example, in XSA-108, beforehand some reads from the
reserved x2apic range would have returned values whereas now they would
#GP. But if the attacker knew that they returned values, it already
would have occurred to her to see if they returned anything of interest.
I didn't notice a single exception to this, though admittedly I didn't
spend much time looking at it.
This suggests to me that #2 is probably not that dangerous the majority
of the time. It also suggests that there may be a simple criteria that
can be applied for #3 that can eliminate most of the guesswork: Is
anything in the original behavior being changed likely to lead an
attacker to think that there may be a vulnerability there? In the case
of basically all of them, I think the answer there would be "yes".
So at the moment I would favor #3, then #2; I'm not in favor of #1 but I
wouldn't strenuously argue against it. But the main thing is that we
have a clear policy.
In my mind, #3 is basically exactly the same as #2, except that in cases
where there would clearly be a problem, the team has an option of
embargoing deployment as well.

i.e. embargoing deployment is an exceptional case.

Cheers,
James

[James McKenzie]

[snip]
1. Never allow people to deploy during the embargo period.
2. Always allow people to deploy during the embargo period.
3. Have the security team attempt to evaluate the risk.
4. Have individual cloud operators evaluate the risk.
This seems like a recipe for disaster.

1 and 3 seem like a recipe for disaster as organizations and individual people
who have become aware of issues may have legal and other obligations to their
users, it would also add a fairly strong incentive for a large operator not
to share any issues that they, or a contractor, had found until they had
completed a mitigation.

Perhaps:

5) Have the security team discuss with the discoverer if fixes should be
permitted during the embargo period before the discovery is announced to
the list.

J.

[Jan Beulich]

Post by James McKenzie

George Dunlap writes ("Security policy ambiguities - XSA-108 process

[snip]
1. Never allow people to deploy during the embargo period.
2. Always allow people to deploy during the embargo period.
3. Have the security team attempt to evaluate the risk.
4. Have individual cloud operators evaluate the risk.
This seems like a recipe for disaster.

1 and 3 seem like a recipe for disaster as organizations and individual people
who have become aware of issues may have legal and other obligations to their
users, it would also add a fairly strong incentive for a large operator not
to share any issues that they, or a contractor, had found until they had
completed a mitigation.
5) Have the security team discuss with the discoverer if fixes should be
permitted during the embargo period before the discovery is announced to
the list.

Even if this looks like a good idea from an abstract pov, I'm not sure
it's practical: In particular in the case where the security team
determines that by deployment learning about details of the
vulnerability might be possible, but the discoverer insists on allowing
deployment, we'd end up with a rather undesirable situation.

Jan

[George Dunlap]

On Mon, Jan 19, 2015 at 8:36 PM, James McKenzie

Post by James McKenzie

[snip]
1. Never allow people to deploy during the embargo period.
2. Always allow people to deploy during the embargo period.
3. Have the security team attempt to evaluate the risk.
4. Have individual cloud operators evaluate the risk.
This seems like a recipe for disaster.

1 and 3 seem like a recipe for disaster as organizations and individual people
who have become aware of issues may have legal and other obligations to their
users, it would also add a fairly strong incentive for a large operator not
to share any issues that they, or a contractor, had found until they had
completed a mitigation.
5) Have the security team discuss with the discoverer if fixes should be
permitted during the embargo period before the discovery is announced to
the list.

Right -- I think that the general approach is almost always "defer to
the discoverer", specifically to encourage early reporting. Perhaps
it's worth making more explicit somewhere.

-George

[Lars Kurth]

Hi all,
I am assuming this question is in effect resolved. The proposed (and agreed) text basically states that security advisories state whether people will be allowed to deploy. The underlying assumption is that usually this is the case, unless there is a very good reason not to. How the security team handles these does not really need to be codified and could be based on whether the deployment would allow reverse engineering the issue (this would be very rare) and thus put everyone at risk, the discoverer stating that he/she not wanting a deployment, or any other reasons.
Regards
Lars

Post by James McKenzie

[snip]
1. Never allow people to deploy during the embargo period.
2. Always allow people to deploy during the embargo period.
3. Have the security team attempt to evaluate the risk.
4. Have individual cloud operators evaluate the risk.
This seems like a recipe for disaster.

1 and 3 seem like a recipe for disaster as organizations and individual people
who have become aware of issues may have legal and other obligations to their
users, it would also add a fairly strong incentive for a large operator not
to share any issues that they, or a contractor, had found until they had
completed a mitigation.
5) Have the security team discuss with the discoverer if fixes should be
permitted during the embargo period before the discovery is announced to
the list.
J.
_______________________________________________
Xen-devel mailing list
http://lists.xen.org/xen-devel

[Ian Jackson]

Having gone through the thread, I've prepared a three-part new
proposal email.

I. Deployment with Security Team Permission
II. Predisclosure list memembership
III. Information sharing
IV. Fixes which seem to have rough consensus as they were

Perhaps I should be checking the current web page out as a git tree
and preparing a patch series ?

Thanks,
Ian.


I. Deployment with Security Team Permission
===========================================

Permitting deployment during embargo seemed to have rough consensus on
the principle. We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches. So I suggest something like this:

List members may deploy fixed versions during the embargo, only with
permission from the Security Team. The Security Team will normally
permit such deployment, even for systems where VMs are managed or
used by non-members of the predisclosure risk. Permission for
deployment, and any restrictions, will be stated in the embargoed
advisory text.

The Security Team will impose deployment restrictions only insofar
as it is necessary to prevent the exposure of technicalities (for
example, differences in behaviour) which present a significant risk
of rediscovery of the vulnerability. Such situations are expected
to be rare.



II. Predisclosure list memembership
===================================

The idea of objective criteria seemed to find favour, and the general
scheme I proposed.

Lars suggested we should "test" this. I think therefore that we
should invite a participants in this thread to write up and post
applications which we can then test against the proposed policy. But
we should probably wait until we have rough consensus on the new
policy shape.

I have dropped the section about bad websites. I don't think its lack
will make much difference to the way applications are processed in
practice, and I still think documenting the issue would be useful, but
it's clear that I'm not going to get consensus for it.

Changes that I have made are:
- Applications to be made, and decisions sent, to a public mailing list
- Explicitly say that the Security Team decide and that they have no
discretion
- Explicitly say that there is appeal to the project governance process
(Lars: perhaps this should say something different or more specific?)


So as I said before, applicants should be required to:

- Provide information on their public web pages which makes
it clear that and why they are eligible;

- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);

- Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.

The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.

Specifically, I propose that the section on list membership
applications be entirely replaced with this:

Organisations who meet the criteria should contact
predisclosure-***@xenproject if they wish to receive
pre-disclosure of advisories. That is a public mailing list.

You must include in the e-mail:

* The name of your organization.

* Domain name(s) which you use to provide Xen software/services.

* A brief description of why you fit the criteria.

* If not all of your products/services use Xen, a list of (some
of) your products/services (or categories thereof) which do.

* Link(s) to current public web pages, belonging to your
organisation, for each of following pieces of information:

o Evidence of your status as a service/software provider:
+ If you are a public hosting provider, your public rates
or how to get a quote
+ If you are a software provider, how your
software can be downloaded or purchased
+ If you are an open-source project, a mailing list
archive and/or version control repository, with
active development

o Evidence of your status as a user of Xen:
+ Statements about, or descriptions of, your eligible
production services or released software, from which it is
immediately evident that they use Xen.

o Information about your handling of security problems:
+ Your invitation to members of the public, who discover
security problems with your products/services, to report
them in confidence to you;
+ Specifically, the contact information (email addresses or
other contact instructions) which such a member of the
public should use.

Blog postings, conference presentations, social media pages,
Flash presentations, videos, sites which require registration,
anything password-protected, etc., are not acceptable. PDFs of
reasonable size are acceptable so long as the URL you provide is
of a ordinary HTML page providing a link to the PDF.

If the pages are long and/or PDFs are involved, your email
should say which part of the pages and documents are relevant.

* A statement to the effect that you have read this policy and
agree to abide by the terms for inclusion in the list,
specifically the requirements regarding confidentiality during
an embargo period.

* The single (non-personal) email alias you wish added to the
predisclosure list.

Your application will be determined by the Xen Project Security
Team, and their decision posted to the list. The Security Team has
no discretion to accept applications which do not provide all of the
information required above.

If you are dissatisfied with the Security Team's decision you may
appeal it via the Xen Project's governance processes.



III. Information-sharing
========================

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have rough consensus in principle. There was some
discussion about the details. I remain convinced that my previous
proposal is correct and I think we should be able to get consensus for
it.

So I reproduce it (unchanged from my previous proposed wording):

List members are allowed to share fixes to embargoed issues,
analysis, etc., with the security teams of other list members.
Technical measures must be taken to prevents non-list-member
organisations, or unauthorised staff in list-member organisations,
from obtaining the embargoed materials.

The Xen Project provides the mailing list
xen-security-issues-***@lists.xenproject.org
for this purpose. List members are encouraged to use it but
may share with other list members' security teams via other
channels.

The -discuss list's distribution is identical to that of the primary
predisclosure list xen-security-issues. Recipient organisations who
do not wish to receive all of the traffic on -discuss should use
recipient-side email filtering based on the provided `List-Id'.

The -discuss list is moderated by the Xen Project Security Team.
Announcements of private availability of fixed versions, and
technical messages about embargoed advisories, will be approved.
Messages dealing with policy matters will be rejected with a
reference to the Security Team contact address and/or public Xen
mailing lists.


IV. Fixes which seem to have rough consensus as they were
=========================================================

(Reproduced unchanged from my previous proposed wording:)

The Security Team should not be invited to give permission
specifically for the release of patched software. I think the rider
was mistakenly merged into the final the bullet point in the list. It
should be separated out. Also, the predisclosure list members should
not be invited to consult the discoverer.

The note about CVE numbers should be moved into the list of
forbidden-disclosures, as a new bullet point. So overall I would
delete that whole paragraph about CVEs (we don't need the historical
information) and adjust the end of the forbidden disclosures to read:

...
* patched software (even in binary form)
* CVE number(s)

Post by Xen Project Security Team
Service announcements to non-list-member users during embargo

We should add just below the list of bullet points of things which may
be disclosed:

Where the list member is a service provider who intends to take
disruptive action such as rebooting as part of deploying a fix (see
above): the list member's communications to its users about the
service disruption may mention that the disruption is to correct a
security issue, and relate it to the public information about the
issue (as listed above).


--

[John Haxby]

Post by Ian Jackson
* Domain name(s) which you use to provide Xen software/services.

This makes sense for a services provider but I'm not sure what it means
for a distro. Is this intended to mean a download location for an
installation image and updates? If it's a download location wouldn't
a URL make more sense?

jch

[George Dunlap]

On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson

Post by Ian Jackson
Having gone through the thread, I've prepared a three-part new
proposal email.
I. Deployment with Security Team Permission
II. Predisclosure list memembership
III. Information sharing
IV. Fixes which seem to have rough consensus as they were
Perhaps I should be checking the current web page out as a git tree
and preparing a patch series ?
Thanks,
Ian.
I. Deployment with Security Team Permission
===========================================
Permitting deployment during embargo seemed to have rough consensus on
the principle. We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
List members may deploy fixed versions during the embargo, only with
permission from the Security Team. The Security Team will normally
permit such deployment, even for systems where VMs are managed or
used by non-members of the predisclosure risk. Permission for
deployment, and any restrictions, will be stated in the embargoed
advisory text.
The Security Team will impose deployment restrictions only insofar
as it is necessary to prevent the exposure of technicalities (for
example, differences in behaviour) which present a significant risk
of rediscovery of the vulnerability. Such situations are expected
to be rare.

+1

Post by Ian Jackson
II. Predisclosure list memembership
===================================
The idea of objective criteria seemed to find favour, and the general
scheme I proposed.
Lars suggested we should "test" this. I think therefore that we
should invite a participants in this thread to write up and post
applications which we can then test against the proposed policy. But
we should probably wait until we have rough consensus on the new
policy shape.
I have dropped the section about bad websites. I don't think its lack
will make much difference to the way applications are processed in
practice, and I still think documenting the issue would be useful, but
it's clear that I'm not going to get consensus for it.
- Applications to be made, and decisions sent, to a public mailing list
- Explicitly say that the Security Team decide and that they have no
discretion
- Explicitly say that there is appeal to the project governance process
(Lars: perhaps this should say something different or more specific?)
- Provide information on their public web pages which makes
it clear that and why they are eligible;
- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);
- Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.
The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.
Specifically, I propose that the section on list membership
Organisations who meet the criteria should contact
pre-disclosure of advisories. That is a public mailing list.
* The name of your organization.
* Domain name(s) which you use to provide Xen software/services.
* A brief description of why you fit the criteria.
* If not all of your products/services use Xen, a list of (some
of) your products/services (or categories thereof) which do.
* Link(s) to current public web pages, belonging to your
+ If you are a public hosting provider, your public rates
or how to get a quote
+ If you are a software provider, how your
software can be downloaded or purchased
+ If you are an open-source project, a mailing list
archive and/or version control repository, with
active development
+ Statements about, or descriptions of, your eligible
production services or released software, from which it is
immediately evident that they use Xen.
+ Your invitation to members of the public, who discover
security problems with your products/services, to report
them in confidence to you;
+ Specifically, the contact information (email addresses or
other contact instructions) which such a member of the
public should use.
Blog postings, conference presentations, social media pages,
Flash presentations, videos, sites which require registration,
anything password-protected, etc., are not acceptable. PDFs of
reasonable size are acceptable so long as the URL you provide is
of a ordinary HTML page providing a link to the PDF.
If the pages are long and/or PDFs are involved, your email
should say which part of the pages and documents are relevant.
* A statement to the effect that you have read this policy and
agree to abide by the terms for inclusion in the list,
specifically the requirements regarding confidentiality during
an embargo period.
* The single (non-personal) email alias you wish added to the
predisclosure list.
Your application will be determined by the Xen Project Security
Team, and their decision posted to the list. The Security Team has
no discretion to accept applications which do not provide all of the
information required above.
If you are dissatisfied with the Security Team's decision you may
appeal it via the Xen Project's governance processes.

+1

Post by Ian Jackson
III. Information-sharing
========================
Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have rough consensus in principle. There was some
discussion about the details. I remain convinced that my previous
proposal is correct and I think we should be able to get consensus for
it.
List members are allowed to share fixes to embargoed issues,
analysis, etc., with the security teams of other list members.
Technical measures must be taken to prevents non-list-member

"to prevents" => either "which prevents" or "to prevent"

I take it in general the technical measures you envision is pgp / gpg?

Post by Ian Jackson
organisations, or unauthorised staff in list-member organisations,
from obtaining the embargoed materials.
The Xen Project provides the mailing list
for this purpose. List members are encouraged to use it but
may share with other list members' security teams via other
channels.
The -discuss list's distribution is identical to that of the primary
predisclosure list xen-security-issues. Recipient organisations who
do not wish to receive all of the traffic on -discuss should use
recipient-side email filtering based on the provided `List-Id'.
The -discuss list is moderated by the Xen Project Security Team.
Announcements of private availability of fixed versions, and
technical messages about embargoed advisories, will be approved.
Messages dealing with policy matters will be rejected with a
reference to the Security Team contact address and/or public Xen
mailing lists.
IV. Fixes which seem to have rough consensus as they were
=========================================================
(Reproduced unchanged from my previous proposed wording:)
The Security Team should not be invited to give permission
specifically for the release of patched software. I think the rider
was mistakenly merged into the final the bullet point in the list. It
should be separated out. Also, the predisclosure list members should
not be invited to consult the discoverer.
The note about CVE numbers should be moved into the list of
forbidden-disclosures, as a new bullet point. So overall I would
delete that whole paragraph about CVEs (we don't need the historical
...
* patched software (even in binary form)
* CVE number(s)

+1

Post by Ian Jackson

Post by Xen Project Security Team
Service announcements to non-list-member users during embargo

We should add just below the list of bullet points of things which may
Where the list member is a service provider who intends to take
disruptive action such as rebooting as part of deploying a fix (see
above): the list member's communications to its users about the
service disruption may mention that the disruption is to correct a
security issue, and relate it to the public information about the
issue (as listed above).

+1

-George

[Ian Jackson]

Post by George Dunlap
On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson

Post by Ian Jackson
III. Information-sharing
========================

...

Post by George Dunlap

Post by Ian Jackson
List members are allowed to share fixes to embargoed issues,
analysis, etc., with the security teams of other list members.
Technical measures must be taken to prevents non-list-member

"to prevents" => either "which prevents" or "to prevent"

Thanks.

Post by George Dunlap
I take it in general the technical measures you envision is pgp / gpg?

No, I don't (honestly) expect anything that sophisticated. I meant
that eg website downloads ought to be password protected. We should
give that as an example.

Ian.

[Lars Kurth]

Post by Ian Jackson
Having gone through the thread, I've prepared a three-part new
proposal email.
I. Deployment with Security Team Permission
II. Predisclosure list memembership
III. Information sharing
IV. Fixes which seem to have rough consensus as they were
Perhaps I should be checking the current web page out as a git tree
and preparing a patch series ?

I would say, give it a week for further feedback and then prepare a patch.

I do have one question. What led us to publish an XSA number on
http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell,
CVE numbers are not published normally and we don't publish them
until after the embargo due to CVE rules. The reason why I am asking
is that one of the main reasons for the heightened media attention we
got during XSA 108, is because the media were able to correlate
statements related to an undisclosed security fix being responsible
for the AWS reboot, with the information on http://xenbits.xen.org/xsa/

If this kind of correlation was not possible, this might remove media
speculation in future and reduce pressure on Xen users.

I am wondering what community members view on publish XSA
numbers post embargo only? Of course this would impact what
can be disclosed pre-embargo.

Post by Ian Jackson
Thanks,
Ian.
I. Deployment with Security Team Permission
===========================================
Permitting deployment during embargo seemed to have rough consensus on
the principle. We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
List members may deploy fixed versions during the embargo, only with
permission from the Security Team. The Security Team will normally
permit such deployment, even for systems where VMs are managed or
used by non-members of the predisclosure risk. Permission for
deployment, and any restrictions, will be stated in the embargoed
advisory text.
The Security Team will impose deployment restrictions only insofar
as it is necessary to prevent the exposure of technicalities (for
example, differences in behaviour) which present a significant risk
of rediscovery of the vulnerability. Such situations are expected
to be rare.

+1

However, I find the text somewhat confusing. "may deploy fixed
versions during the embargo, only with permission from the
Security Team" contradicts the other statements, that deploying
fixes is OK, unless stated in the advisory text.

Or did I misinterpret?

In any case, it is not quite clear what the protocol to get permission
is. Or whether, the protocol is "deployment is OK" unless stated
otherwise.

So I think, in the final policy text this should be written from the
viewpoint of a pre-disclosure member, not the viewpoint of the
Security Team.

Or is the intention that permission is sought via

Post by Ian Jackson
II. Predisclosure list memembership
===================================
The idea of objective criteria seemed to find favour, and the general
scheme I proposed.
Lars suggested we should "test" this. I think therefore that we
should invite a participants in this thread to write up and post
applications which we can then test against the proposed policy. But
we should probably wait until we have rough consensus on the new
policy shape.

It's either that, or we periodically review applications and see whether
they need to be improved. Given that the list is public, over time
there will be a list of templates that have been accepted which can
serve as examples.

Post by Ian Jackson
I have dropped the section about bad websites. I don't think its lack
will make much difference to the way applications are processed in
practice, and I still think documenting the issue would be useful, but
it's clear that I'm not going to get consensus for it.
- Applications to be made, and decisions sent, to a public mailing list
- Explicitly say that the Security Team decide and that they have no
discretion
- Explicitly say that there is appeal to the project governance process
(Lars: perhaps this should say something different or more specific?)
- Provide information on their public web pages which makes
it clear that and why they are eligible;
- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);
- Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.
The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.
Specifically, I propose that the section on list membership
Organisations who meet the criteria should contact
pre-disclosure of advisories. That is a public mailing list.

Do you anticipate that the list be moderated?

Post by Ian Jackson
* The name of your organization.
* Domain name(s) which you use to provide Xen software/services.
* A brief description of why you fit the criteria.
* If not all of your products/services use Xen, a list of (some
of) your products/services (or categories thereof) which do.
* Link(s) to current public web pages, belonging to your
+ If you are a public hosting provider, your public rates
or how to get a quote
+ If you are a software provider, how your
software can be downloaded or purchased
+ If you are an open-source project, a mailing list
archive and/or version control repository, with
active development
+ Statements about, or descriptions of, your eligible
production services or released software, from which it is
immediately evident that they use Xen.
+ Your invitation to members of the public, who discover
security problems with your products/services, to report
them in confidence to you;
+ Specifically, the contact information (email addresses or
other contact instructions) which such a member of the
public should use.
Blog postings, conference presentations, social media pages,
Flash presentations, videos, sites which require registration,
anything password-protected, etc., are not acceptable. PDFs of
reasonable size are acceptable so long as the URL you provide is
of a ordinary HTML page providing a link to the PDF.
If the pages are long and/or PDFs are involved, your email
should say which part of the pages and documents are relevant.
* A statement to the effect that you have read this policy and
agree to abide by the terms for inclusion in the list,
specifically the requirements regarding confidentiality during
an embargo period.
* The single (non-personal) email alias you wish added to the
predisclosure list.
Your application will be determined by the Xen Project Security
Team, and their decision posted to the list. The Security Team has
no discretion to accept applications which do not provide all of the
information required above.

As it is a public list, I am assuming that others on the list may be
allowed to post concerns on the list.

Post by Ian Jackson
If you are dissatisfied with the Security Team's decision you may
appeal it via the Xen Project's governance processes.

It is not quite clear how this would work in practice. Are you
suggesting that the referee process would be used in this case?
That would be that fundamentally, maintainers, project leads, ...
would need to look at appeals.

I suppose that would be OK and in reality, we will hardly ever
get appeals.

Post by Ian Jackson
III. Information-sharing
========================
Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have rough consensus in principle. There was some
discussion about the details. I remain convinced that my previous
proposal is correct and I think we should be able to get consensus for
it.

+1

Post by Ian Jackson
IV. Fixes which seem to have rough consensus as they were
=========================================================
(Reproduced unchanged from my previous proposed wording:)

+1

[Ian Jackson]

Post by Lars Kurth
I do have one question. What led us to publish an XSA number on
http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell,
CVE numbers are not published normally and we don't publish them
until after the embargo due to CVE rules.

We used to publish CVEs in advance but MITRE asked us to stop doing
so.

We publish the XSA numbers because the purpose of the secrecy is to
prevent vulnerabilities being exploited. The purpose of the secrecy
is not the convenience of the Security Team. Everything that does not
need to be secret for that real purpose should be public.

Keeping secret the existence of an XSA number, and its embargo date,
would not improve the security of systems running Xen. So we should
not do that.

Making the embargo end date public is very useful for people who are
_not_ on the predisclosure list, because it means that they can plan
their response. (And it wouldn't make much sense to publish embargo
end date(s) without XSA numbers.)

Post by Lars Kurth
I am wondering what community members view on publish XSA
numbers post embargo only? Of course this would impact what
can be disclosed pre-embargo.

Another impact of keeping things totally secret in the way you suggest
is that service providers would no longer be able to give honest
reasons for maintenance activity.

Ian.

[Lars Kurth]

Post by Ian Jackson

Post by Lars Kurth
I do have one question. What led us to publish an XSA number on
http://xenbits.xen.org/xsa/ in the way we do now? As far as I can tell,
CVE numbers are not published normally and we don't publish them
until after the embargo due to CVE rules.

We used to publish CVEs in advance but MITRE asked us to stop doing
so.
We publish the XSA numbers because the purpose of the secrecy is to
prevent vulnerabilities being exploited. The purpose of the secrecy
is not the convenience of the Security Team. Everything that does not
need to be secret for that real purpose should be public.
Keeping secret the existence of an XSA number, and its embargo date,
would not improve the security of systems running Xen. So we should
not do that.
Making the embargo end date public is very useful for people who are
_not_ on the predisclosure list, because it means that they can plan
their response. (And it wouldn't make much sense to publish embargo
end date(s) without XSA numbers.)

That is a good explanation and I can live with it.
I was mainly asking, because MITRE asked us to remove CVE numbers and there seemed to be some inconsistency

Post by Ian Jackson

Post by Lars Kurth
I am wondering what community members view on publish XSA
numbers post embargo only? Of course this would impact what
can be disclosed pre-embargo.

Another impact of keeping things totally secret in the way you suggest
is that service providers would no longer be able to give honest
reasons for maintenance activity.

That is also true

Regards
Lars

[Ian Jackson]

...

Post by Lars Kurth

Post by Ian Jackson
The Security Team will impose deployment restrictions only insofar
as it is necessary to prevent the exposure of technicalities (for
example, differences in behaviour) which present a significant risk
of rediscovery of the vulnerability. Such situations are expected
to be rare.

+1
However, I find the text somewhat confusing. "may deploy fixed
versions during the embargo, only with permission from the
Security Team" contradicts the other statements, that deploying
fixes is OK, unless stated in the advisory text.

I will clarify my proposed wording on this point.

Post by Lars Kurth
In any case, it is not quite clear what the protocol to get permission
is. Or whether, the protocol is "deployment is OK" unless stated
otherwise.
So I think, in the final policy text this should be written from the
viewpoint of a pre-disclosure member, not the viewpoint of the
Security Team.
Or is the intention that permission is sought via

No, the permission will be stated in the advisory. I have reworded
this in my copy of my draft text to make this clearer.

Thanks,
Ian.

[Ian Jackson]

Post by Lars Kurth
I would say, give it a week for further feedback and then prepare a patch.

It's been rather longer than a week - sorry.

I would like to propose the following series of changes to the Xen
Project Security Policy. For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.

You can find the git tree I am using here:
http://xenbits.xen.org/gitweb/?p=people/iwj/security-process.git;a=shortlog;h=refs/heads/rebasing
The relevant changes are in master..rebasing.

I have put a copy of the bare HTML here:
http://xenbits.xen.org/people/iwj/draft/security_vulnerability_process.html

The substance of each change is discussed in the corresponding commit
message.

Ian.

[Ian Jackson]

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have appropriate consensus.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 41b5fe0..d1d40ca 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -224,6 +224,27 @@ situations are expected to be rare.</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>
+<h3>Information-sharing amongst predisclosure list members</h3>
+<p>Predisclosure list members are allowed to share fixes to embargoed issues,
+analysis, etc., with the security teams of other list members.
+Technical measures must be taken to prevents non-list-member
+organisations, or unauthorised staff in list-member organisations,
+from obtaining the embargoed materials.</p>
+<p>The Xen Project provides the mailing list
+<code>xen-security-issues-***@lists.xenproject.org</code>
+for this purpose. List members are encouraged to use it but
+may share with other list members' security teams via other
+channels.</p>
+<p>The <code>-discuss</code> list's distribution is identical to that of the primary
+predisclosure list <code>xen-security-issues</code>. Recipient organisations who
+do not wish to receive all of the traffic on -discuss should use
+recipient-side email filtering based on the provided <code>List-Id</code>.</p>
+<p>The <code>-discuss</code> list is moderated by the Xen Project Security Team.
+Announcements of private availability of fixed versions, and
+technical messages about embargoed advisories, will be approved.
+Messages dealing with policy matters will be rejected with a
+reference to the Security Team contact address and/or public Xen
+mailing lists.</p>
<h3>Predisclosure list membership application process</h3>
<p>Organisations who meet the criteria should contact
predisclosure-***@xenproject if they wish to receive

[Ian Jackson]

Service provider list members should not be prevented from being
reasonably honest with their users.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 2d7c43e..d6e0df5 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -222,6 +222,14 @@ restrictions only insofar as it is necessary to prevent the exposure
of technicalities (for example, differences in behaviour) which
present a significant risk of rediscovery of the vulnerability. Such
situations are expected to be rare.</p>
+<p>Where the list member is a service provider who intends to take
+disruptive action such as rebooting as part of deploying a fix: the
+list member's communications to its users about the service disruption
+may mention that the disruption is to correct a security issue, and
+relate it to the public information about the issue (as listed above).
+This applies whether the deployment occurs during the embargo (with
+permission - see above) or is planned for after the end of the
+embargo.</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>

[Ian Jackson]

Applicants should be required to:

- Provide information on their public web pages which makes
it clear that and why they are eligible;

- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);

- Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.

The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.

Also remove the "case-by-case-basis" membership exception. This is
not consistent with the new objective membership application process.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 79 ++++++++++++++++++++++++-----------
1 file changed, 54 insertions(+), 25 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 4fd02e9..41b5fe0 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -176,9 +176,7 @@ development, is very likely to be accepted; whereas a project with a
single developer who spends a few hours a month will most likey be
rejected.</p>
<p>For organizational users, a rule of thumb is that "large scale"
-means an installed base of 300,000 or more Xen guests. Other
-well-established organisations with a mature security response process
-will be considered on a case-by-case basis.</p>
+means an installed base of 300,000 or more Xen guests.</p>
<p>The list of entities on the pre-disclosure list is public. (Just
the list of projects and organisations, not the actual email
addresses.)</p>
@@ -230,35 +228,66 @@ longer permitted in accordance with MITRE policy.</p>
<p>Organisations who meet the criteria should contact
predisclosure-***@xenproject if they wish to receive
pre-disclosure of advisories. That is a public mailing list.
-<p>Please include in the e-mail:</p>
+<p>You must include in the e-mail:</p>
<ul>
<li>The name of your organization</li>
- <li>A brief description of why you fit the criteria, along with
- evidence to support the claim</li>
- <li>A security alias e-mail address (no personal addresses -- see
- below)</li>
- <li>A link to a web page with your security policy statement</li>
+ <li>Domain name(s) which you use to provide Xen software/services</li>
+ <li>A brief description of why you fit the criteria</li>
+ <li>If not all of your products/services use Xen, a list of (some
+ of) your products/services (or categories thereof) which do.</li>
+ <li>Link(s) to current public web pages, belonging to your
+ organisation, for each of following pieces of information:
+ <ul>
+ <li>Evidence of your status as a service/software provider:
+ <ul>
+ <li>If you are a public hosting provider, your public rates
+ or how to get a quote</li>
+ <li>If you are a software provider, how your
+ software can be downloaded or purchased</li>
+ <li>If you are an open-source project, a mailing list
+ archive and/or version control repository, with
+ active development</li>
+ </ul>
+ </li>
+ <li>Evidence of your status as a user/distributor of Xen:
+ <ul>
+ <li>Statements about, or descriptions of, your eligible
+ production services or released software, from which it is
+ immediately evident that they use Xen.
+ </ul>
+ </li>
+ <li>Information about your handling of security problems:
+ <ul>
+ <li>Your invitation to members of the public, who discover
+ security problems with your products/services, to report
+ them in confidence to you;
+ <li>Specifically, the contact information (email addresses or
+ other contact instructions) which such a member of the
+ public should use.
+ </ul>
+ </li>
+ </ul>
+ <p>Blog postings, conference presentations, social media pages,
+ Flash presentations, videos, sites which require registration,
+ anything password-protected, etc., are not acceptable. PDFs of
+ reasonable size are acceptable so long as the URL you provide is
+ of a ordinary HTML page providing a link to the PDF.</p>
+ <p>If the pages are long and/or PDFs are involved, your email
+ should say which part of the pages and documents are relevant.</p>
+ </li>
<li>A statement to the effect that you have read this policy and
agree to abide by the terms for inclusion in the list, specifically
the requirements to regarding confidentiality during an embargo
period</li>
- <li>Evidence that will be considered may include the following:
- <ul>
- <li>If you are a public hosting provider, a link to a web page
- with your public rates</li>
- <li>If you are a software provider, a link to a web page where
- your software can be downloaded or purchased</li>
- <li>If you are an open-source project, a link to a mailing list
- archive and/or a version control repository demonstrating active
- development</li>
- <li>A public key signed with a key which is in the PGP "strong
- set"</li>
- </ul>
- </li>
+ <li>The single (non-personal) email alias you wish added to the
+ predisclosure list.</li>
</ul>
-<p>Organizations already on the list who do not have a security alias
-or have not sent a statement that they have read this policy and will
-abide by, it will be asked to do so. </p>
+<p>Your application will be determined by the Xen Project Security
+Team, and their decision posted to the list. The Security Team has
+no discretion to accept applications which do not provide all of the
+information required above.</p>
+<p>If you are dissatisfied with the Security Team's decision you may
+appeal it via the Xen Project's governance processes.</p>
<p>Organisations should not request subscription via the mailing list
web interface. Any such subscription requests will be rejected and
ignored.</p>

[Ian Jackson]

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index d6e0df5..df52221 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -1,6 +1,6 @@
<p>This document has come in effect in December 2011 and will be
reviewed periodically (see revision sections). The last modification
-has been made in October 2014.</p>
+has been made in (approval date tbd).</p>
<h2>Introduction</h2>
<p>Computer systems have bugs. Currently recognised best practice for
bugs with security implications is to notify significant downstream
@@ -384,6 +384,8 @@ email addresses or internal business groups).</p>
<h2>Change History</h2>
<div class="box-note">
<ul>
+ <li><strong>v3.0 (approval date TBD):</strong> New predisclosure list application
+ process and information-sharing and -handling rules; and, minor clarifications.</li>
<li><strong>v2.7 Oct 21st 2014:</strong> Added the following
vendors to the pre-disclosure list: OnePoundWebHosting Ltd, File
Sanctuary, iWeb Technologies Inc., Memset</li>

[Ian Jackson]

The prior consultation clause should applies to all disclosure
exceptions. The list end appears to have been moved by mistake. So
put it back.

Also, no longer suggest that predisclosure list members should consult
with the discoverer, since the discoverer is not generally known to
predisclosure list members.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index d1d40ca..2d7c43e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -200,9 +200,10 @@ partners:</p>
<li>the impact, scope, set of vulnerable systems or the nature of
the vulnerability</li>
<li>revision control commits which are a fix for the problem</li>
- <li>patched software (even in binary form) without prior
- consultation with ***@xenproject and/or the discoverer.</li>
+ <li>patched software (even in binary form)</li>
</ul>
+without prior
+consultation with ***@xenproject.
<p>List members are allowed to make available to their users only the
following:</p>
<ul>

[Ian Jackson]

Permitting deployment during embargo seemed to have rough consensus on
the principle. We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 010cf76..de5e83e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
<li>The assigned XSA number</li>
<li>The planned disclosure date</li>
</ul>
+<p>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.</p>
+<p>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 Team will impose deployment
+restrictions only insofar as it is necessary to prevent the exposure
+of technicalities (for example, differences in behaviour) which
+present a significant risk of rediscovery of the vulnerability. Such
+situations are expected to be rare.</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>

[Jan Beulich]

Post by Ian Jackson
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
<li>The assigned XSA number</li>
<li>The planned disclosure date</li>
</ul>
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo. Permission for

..., may deploy ... ?

Jan

Post by Ian Jackson
+deployment, and any restrictions, will be stated in the embargoed
+advisory text.</p>
+<p>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 Team will impose deployment
+restrictions only insofar as it is necessary to prevent the exposure
+of technicalities (for example, differences in behaviour) which
+present a significant risk of rediscovery of the vulnerability. Such
+situations are expected to be rare.</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>

[Lars Kurth]

Post by Ian Jackson
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo. Permission for

Better: List members may deploy fixed versions during the embargo, if (...)
Lars

[Ian Jackson]

Post by Lars Kurth

Post by Ian Jackson
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo. Permission for

Better: List members may deploy fixed versions during the embargo, if (...)

The reason I didn't write it like that is that someone who reads only
the first part of the sentence might not see the caveat.

Is my wording unclear ?

Ian.

[Ian Campbell]

Post by Ian Jackson

Post by Lars Kurth

Post by Ian Jackson
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo. Permission for

Better: List members may deploy fixed versions during the embargo, if (...)

The reason I didn't write it like that is that someone who reads only
the first part of the sentence might not see the caveat.

Yes, I think having that very important restriction front and centre is
a good thing.

Post by Ian Jackson
Is my wording unclear ?

Not to me, fwiw.

Ian.

[George Dunlap]

On Mon, Jan 19, 2015 at 1:38 PM, Ian Jackson

Post by Ian Jackson

Post by Lars Kurth

Post by Ian Jackson
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo. Permission for

Better: List members may deploy fixed versions during the embargo, if (...)

The reason I didn't write it like that is that someone who reads only
the first part of the sentence might not see the caveat.
Is my wording unclear ?

I think it's just a less common grammatical construct (splitting "may
do X" into "may, if Y, do X"), and so perhaps a bit more difficult for
non-native speakers to parse? But I think that probably in this case,
while it might take a bit more effort to read for some, the risk of
someone actually misunderstanding your wording is low; while the risk
of someone missing the caveat in the other wording is much more
dangerous. So I'd leave it the way it is.

-George

[Lars Kurth]

Agree with George

Post by George Dunlap
On Mon, Jan 19, 2015 at 1:38 PM, Ian Jackson

Post by Ian Jackson

Post by Lars Kurth

Post by Ian Jackson
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo. Permission for

Better: List members may deploy fixed versions during the embargo, if (...)

The reason I didn't write it like that is that someone who reads only
the first part of the sentence might not see the caveat.
Is my wording unclear ?

I think it's just a less common grammatical construct (splitting "may
do X" into "may, if Y, do X"), and so perhaps a bit more difficult for
non-native speakers to parse? But I think that probably in this case,
while it might take a bit more effort to read for some, the risk of
someone actually misunderstanding your wording is low; while the risk
of someone missing the caveat in the other wording is much more
dangerous. So I'd leave it the way it is.
-George

[Ian Campbell]

Post by Jan Beulich

Post by Ian Jackson
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
<li>The assigned XSA number</li>
<li>The planned disclosure date</li>
</ul>
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo. Permission for

..., may deploy ... ?

The may is before the first comma, which is where it should be I think.
(Lars' suggestion to reword entirely notwithstanding)

Ian.

[Jan Beulich]

Post by Ian Campbell

Post by Jan Beulich

Post by Ian Jackson
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
<li>The assigned XSA number</li>
<li>The planned disclosure date</li>
</ul>
+<p>List members may, if (and only if) the Security Team grants
+permission, deploy fixed versions during the embargo. Permission for

..., may deploy ... ?

The may is before the first comma, which is where it should be I think.
(Lars' suggestion to reword entirely notwithstanding)

Indeed, but I noticed this only when seeing Lars' reply. Sorry
for the noise.

Jan

[Ian Campbell]

Post by Ian Jackson
Permitting deployment during embargo seemed to have rough consensus on
the principle. We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.
---
security_vulnerability_process.html | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 010cf76..de5e83e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
<li>The assigned XSA number</li>
<li>The planned disclosure date</li>
</ul>
+<p>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.</p>

Do you have a corresponding patch to our advisory template to add a
section with an XXX for this?

Post by Ian Jackson
+<p>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 Team will impose deployment
+restrictions only insofar as it is necessary to prevent the exposure
+of technicalities (for example, differences in behaviour) which
+present a significant risk of rediscovery of the vulnerability. Such
+situations are expected to be rare.</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>

[Ian Jackson]

Post by Ian Campbell

Post by Ian Jackson
+<p>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.</p>

Do you have a corresponding patch to our advisory template to add a
section with an XXX for this?

No, but it's trivial. I think, though, that perhaps I should go
through this series and add an `implementation tasks' note to each
commit message.

Ian.

[Ian Campbell]

Post by Ian Jackson

Post by Ian Campbell

Post by Ian Jackson
+<p>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.</p>

Do you have a corresponding patch to our advisory template to add a
section with an XXX for this?

No, but it's trivial. I think, though, that perhaps I should go
through this series and add an `implementation tasks' note to each
commit message.

Good idea.

Ian.

[Ian Jackson]

- For Predisclosure list application process
- For Handling of embargoed information"

No semantic change.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 2 ++
1 file changed, 2 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 4ed0042..010cf76 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -186,6 +186,7 @@ addresses.)</p>
of the advisory and patches, with a clearly marked embargo date, as
soon as they are available. The pre-disclosure list will also receive
copies of public advisories when they are first issued or updated</p>
+<h3>Handling of embargoed information</h3>
<p>Organizations on the pre-disclosure list are expected to maintain
the confidentiality of the vulnerability up to the embargo date which
***@xenproject have agreed with the discoverer, and are
@@ -214,6 +215,7 @@ following:</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>
+<h3>Predisclosure list membership application process</h3>
<p>Organisations who meet the criteria should contact
***@xenproject if they wish to receive pre-disclosure of
advisories. Please include in the e-mail:</p>

[Ian Jackson]

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index de5e83e..4fd02e9 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -228,8 +228,9 @@ permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>
<h3>Predisclosure list membership application process</h3>
<p>Organisations who meet the criteria should contact
-***@xenproject if they wish to receive pre-disclosure of
-advisories. Please include in the e-mail:</p>
+predisclosure-***@xenproject if they wish to receive
+pre-disclosure of advisories. That is a public mailing list.
+<p>Please include in the e-mail:</p>
<ul>
<li>The name of your organization</li>
<li>A brief description of why you fit the criteria, along with

[Ian Campbell]

Post by Ian Jackson
---
security_vulnerability_process.html | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index de5e83e..4fd02e9 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -228,8 +228,9 @@ permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>
<h3>Predisclosure list membership application process</h3>
<p>Organisations who meet the criteria should contact
-advisories. Please include in the e-mail:</p>

^.org

Post by Ian Jackson
+pre-disclosure of advisories. That is a public mailing list.

s/That/This/? Not sure.

Post by Ian Jackson
+<p>Please include in the e-mail:</p>
<ul>
<li>The name of your organization</li>
<li>A brief description of why you fit the criteria, along with

[Ian Jackson]

Post by Ian Campbell

Post by Ian Jackson
-advisories. Please include in the e-mail:</p>

^.org

Deliberately omitted to try to help avoid spam. I could leave it in
but bear in mind that that list needs to be open for posting to all
(even non-subscribers).

Post by Ian Campbell

Post by Ian Jackson
+pre-disclosure of advisories. That is a public mailing list.

s/That/This/? Not sure.

I thought `that' because the message itself (and the policy) isn't on
a mailing list.

Ian.

[Ian Campbell]

Post by Ian Jackson

Post by Ian Campbell

Post by Ian Jackson
-advisories. Please include in the e-mail:</p>

^.org

Deliberately omitted to try to help avoid spam. I could leave it in
but bear in mind that that list needs to be open for posting to all
(even non-subscribers).

Perhaps if it were "<a href=mailto:"'d up it would help?

I don't think it will be all that clear to non-involved people reading
this (especially if they are in a panic) what suffix they need to add.

Or include "<dot> org", since that seems to be a pretty common syntax.

Post by Ian Jackson

Post by Ian Campbell

Post by Ian Jackson
+pre-disclosure of advisories. That is a public mailing list.

s/That/This/? Not sure.

I thought `that' because the message itself (and the policy) isn't on
a mailing list.

It sounds weird to me (not to say it's wrong of course...).

Perhaps:

***@xenproject, which is a public mailing list, if they wish ...

or, "Note that this is a public mailing list"?

Ian.

[Don Koch]

On Mon, 19 Jan 2015 13:19:03 +0000

Post by Ian Campbell

Post by Ian Jackson

Post by Ian Jackson
-advisories. Please include in the e-mail:</p>

^.org

Deliberately omitted to try to help avoid spam. I could leave it in
but bear in mind that that list needs to be open for posting to all
(even non-subscribers).

Perhaps if it were "<a href=mailto:"'d up it would help?

Sounds like a bigger sign post for spammers to me.

Post by Ian Campbell
I don't think it will be all that clear to non-involved people reading
this (especially if they are in a panic) what suffix they need to add.
Or include "<dot> org", since that seems to be a pretty common syntax.

I'd go with this or something similar.

-d

[Ian Jackson]

Post by Ian Campbell
or, "Note that this is a public mailing list"?

I went with the former of those (using parens rather than commas).

Ian.

[Jan Beulich]

Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108

Post by Lars Kurth
I would say, give it a week for further feedback and then prepare a patch.

It's been rather longer than a week - sorry.
I would like to propose the following series of changes to the Xen
Project Security Policy. For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.

LGTM, but I think there's no point in ack-ing the series as the
changes need to be voted on anyway.

One thing I'm missing though is some statement regarding the
handling of existing list members when the policy changes (while
the agreement given by them during the application process was
only for an earlier version).

Jan

[Ian Jackson]

Post by Jan Beulich
LGTM, but I think there's no point in ack-ing the series as the
changes need to be voted on anyway.

Indeed.

I will post a v2 with the minor fixes from this thread incorporated.

Post by Jan Beulich
One thing I'm missing though is some statement regarding the
handling of existing list members when the policy changes (while
the agreement given by them during the application process was
only for an earlier version).

I don't think this is necessary in this case. The questions which are
explicitly addressed in the policy now are almost all (a)
clarifications of things which were unclear before and which in the
past the Security Team have had to answer, and (b) resolved in a
permissive way.

The exception is the possibility that deployment of a particular fix
would be forbidden. But if that were to arise, it would be stated
clearly in the advisory text. I don't think we need to explicitly
invite predisclosure list members to agree to such a statement, given
the vagueness of the existing policy.

I have deliberately not included a requalification process in this
series of changes. I would like to leave that to a later update.

Ian.

[Lars Kurth]

Post by Ian Jackson

Post by Jan Beulich
LGTM, but I think there's no point in ack-ing the series as the
changes need to be voted on anyway.

Indeed.
I will post a v2 with the minor fixes from this thread incorporated.

Agreed

Lars

[George Dunlap]

On Fri, Jan 16, 2015 at 7:48 PM, Ian Jackson

Post by Ian Jackson

Post by Lars Kurth
I would say, give it a week for further feedback and then prepare a patch.

It's been rather longer than a week - sorry.
I would like to propose the following series of changes to the Xen
Project Security Policy. For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.
http://xenbits.xen.org/gitweb/?p=people/iwj/security-process.git;a=shortlog;h=refs/heads/rebasing
The relevant changes are in master..rebasing.

FWIW I've talken a look at it and it all seems good.

-George

[Ian Jackson]

I would like to propose the following series of changes to the Xen
Project Security Policy. For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.

The substance of each change is discussed in the corresponding commit
message.

I am going to wait a week to see if anyone has any further comments.
If not, I will ask the Xen Project Community Manager to conduct the
formal approval process.


You can find the git tree I am using here:
http://xenbits.xen.org/gitweb/?p=people/iwj/security-process.git;a=shortlog;h\
=refs/heads/rebasing
The relevant changes are in master..rebasing.

I have put a copy of the bare HTML here:
http://xenbits.xen.org/people/iwj/draft/security_vulnerability_process.html


This is v2 of the series of changes. The only comments were minor and
technical, and have (I think) been addressed. The changes in v2 of the
series compared to my previous patch-series proposal:
* Add IMPLEMENTATION TASKS section to various of the commit messages
* Minor wording changes (no semantic change compared to v1)
* Better presentation of email addresses (no semantic change)

Thanks,
Ian.

[Ian Jackson]

IMPLEMENTATION TASKS:
* Create the mailing list (and check that it works from outside)

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>

---
v2: Provide whole email address for predisclosure-applications@,
but obfuscate it with <dot> and a <span>.
Reword sentence about public mailing list as suggested by
Ian Campbell.
---
security_vulnerability_process.html | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index de5e83e..8870f8d 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -228,8 +228,10 @@ permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>
<h3>Predisclosure list membership application process</h3>
<p>Organisations who meet the criteria should contact
-***@xenproject if they wish to receive pre-disclosure of
-advisories. Please include in the e-mail:</p>
+predisclosure-***@xenproject&lt;d<span>ot</span>&gt;org
+(which is a public mailing list) if they wish to receive
+pre-disclosure of advisories.
+<p>Please include in the e-mail:</p>
<ul>
<li>The name of your organization</li>
<li>A brief description of why you fit the criteria, along with

[Ian Jackson]

Permitting deployment during embargo seemed to have rough consensus on
the principle. We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.

IMPLEMENTATION TASKS:
* Add new section to Security Team's advisory template.
* Add new section to any existing outstanding embargoed advisories.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 010cf76..de5e83e 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -212,6 +212,17 @@ following:</p>
<li>The assigned XSA number</li>
<li>The planned disclosure date</li>
</ul>
+<p>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.</p>
+<p>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 Team will impose deployment
+restrictions only insofar as it is necessary to prevent the exposure
+of technicalities (for example, differences in behaviour) which
+present a significant risk of rediscovery of the vulnerability. Such
+situations are expected to be rare.</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>

[Ian Jackson]

Service provider list members should not be prevented from being
reasonably honest with their users.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 7412652..3b9c1ba 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -222,6 +222,14 @@ restrictions only insofar as it is necessary to prevent the exposure
of technicalities (for example, differences in behaviour) which
present a significant risk of rediscovery of the vulnerability. Such
situations are expected to be rare.</p>
+<p>Where the list member is a service provider who intends to take
+disruptive action such as rebooting as part of deploying a fix: the
+list member's communications to its users about the service disruption
+may mention that the disruption is to correct a security issue, and
+relate it to the public information about the issue (as listed above).
+This applies whether the deployment occurs during the embargo (with
+permission - see above) or is planned for after the end of the
+embargo.</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>

[Ian Jackson]

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have appropriate consensus.

IMPLEMENTATION TASKS:
* Send a notification to the existing predisclosure list members
informing them that they have been subscribed to the new list.
Notice should point them to the policy section on filtering
by List-Id, and offer to unsubscribe them from both lists if
they prefer.
* Create the new mailing list, and
- check that it can be emailed from outside
- that messages are held for moderation and can be approved

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>

---
v2: Obfuscate -discuss@ list's full email address with <dot>
and <span>.
---
security_vulnerability_process.html | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index de8fd44..2d32e51 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -224,6 +224,27 @@ situations are expected to be rare.</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>
+<h3>Information-sharing amongst predisclosure list members</h3>
+<p>Predisclosure list members are allowed to share fixes to embargoed issues,
+analysis, etc., with the security teams of other list members.
+Technical measures must be taken to prevents non-list-member
+organisations, or unauthorised staff in list-member organisations,
+from obtaining the embargoed materials.</p>
+<p>The Xen Project provides the mailing list
+<code>xen-security-issues-***@lists.xenproject&lt;do<span>t&gt;</span>org</code>
+for this purpose. List members are encouraged to use it but
+may share with other list members' security teams via other
+channels.</p>
+<p>The <code>-discuss</code> list's distribution is identical to that of the primary
+predisclosure list <code>xen-security-issues</code>. Recipient organisations who
+do not wish to receive all of the traffic on -discuss should use
+recipient-side email filtering based on the provided <code>List-Id</code>.</p>
+<p>The <code>-discuss</code> list is moderated by the Xen Project Security Team.
+Announcements of private availability of fixed versions, and
+technical messages about embargoed advisories, will be approved.
+Messages dealing with policy matters will be rejected with a
+reference to the Security Team contact address and/or public Xen
+mailing lists.</p>
<h3>Predisclosure list membership application process</h3>
<p>Organisations who meet the criteria should contact
predisclosure-***@xenproject&lt;d<span>ot</span>&gt;org

[Ian Jackson]

IMPLEMENTATION TASKS:
* Assign last change date to be approval date
* Reformat html to web page CMS format
* Update web page

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 3b9c1ba..9ca7622 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -1,6 +1,6 @@
<p>This document has come in effect in December 2011 and will be
reviewed periodically (see revision sections). The last modification
-has been made in October 2014.</p>
+has been made in (approval date tbd).</p>
<h2>Introduction</h2>
<p>Computer systems have bugs. Currently recognised best practice for
bugs with security implications is to notify significant downstream
@@ -385,6 +385,8 @@ email addresses or internal business groups).</p>
<h2>Change History</h2>
<div class="box-note">
<ul>
+ <li><strong>v3.0 (approval date TBD):</strong> New predisclosure list application
+ process and information-sharing and -handling rules; and, minor clarifications.</li>
<li><strong>v2.7 Oct 21st 2014:</strong> Added the following
vendors to the pre-disclosure list: OnePoundWebHosting Ltd, File
Sanctuary, iWeb Technologies Inc., Memset</li>

[Ian Jackson]

The prior consultation clause should applies to all disclosure
exceptions. The list end appears to have been moved by mistake. So
put it back.

Also, no longer suggest that predisclosure list members should consult
with the discoverer, since the discoverer is not generally known to
predisclosure list members.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 2d32e51..7412652 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -200,9 +200,10 @@ partners:</p>
<li>the impact, scope, set of vulnerable systems or the nature of
the vulnerability</li>
<li>revision control commits which are a fix for the problem</li>
- <li>patched software (even in binary form) without prior
- consultation with ***@xenproject and/or the discoverer.</li>
+ <li>patched software (even in binary form)</li>
</ul>
+without prior
+consultation with ***@xenproject.
<p>List members are allowed to make available to their users only the
following:</p>
<ul>

[Ian Jackson]

No semantic change.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 7069646..4ed0042 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -246,7 +246,7 @@ advisories. Please include in the e-mail:</p>
or have not sent a statement that they have read this policy and will
abide by, it will be asked to do so. </p>
<p>Organisations should not request subscription via the mailing list
-web interface, any such subscription requests will be rejected and
+web interface. Any such subscription requests will be rejected and
ignored.</p>
<p>A role address (such
as <a href="mailto:***@example.com">***@example.com</a>)

[Ian Jackson]

- For Predisclosure list application process
- For Handling of embargoed information"

No semantic change.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 2 ++
1 file changed, 2 insertions(+)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 4ed0042..010cf76 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -186,6 +186,7 @@ addresses.)</p>
of the advisory and patches, with a clearly marked embargo date, as
soon as they are available. The pre-disclosure list will also receive
copies of public advisories when they are first issued or updated</p>
+<h3>Handling of embargoed information</h3>
<p>Organizations on the pre-disclosure list are expected to maintain
the confidentiality of the vulnerability up to the embargo date which
***@xenproject have agreed with the discoverer, and are
@@ -214,6 +215,7 @@ following:</p>
<p><em>NOTE:</em> Prior v2.2 of this policy (25 June 2014) it was
permitted to also make available the allocated CVE number. This is no
longer permitted in accordance with MITRE policy.</p>
+<h3>Predisclosure list membership application process</h3>
<p>Organisations who meet the criteria should contact
***@xenproject if they wish to receive pre-disclosure of
advisories. Please include in the e-mail:</p>

[Ian Jackson]

Applicants should be required to:

- Provide information on their public web pages which makes
it clear that and why they are eligible;

- Specifically, publicly state that and how they are using Xen
(so that the Security Team can verify eligibility);

- Provide a way for members of the public to responsibly report
security problems to the applicant, just as the Xen Project does.

The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.

Also remove the "case-by-case-basis" membership exception. This is
not consistent with the new objective membership application process.

Signed-off-by: Ian Jackson <***@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <***@eu.citrix.com>
---
security_vulnerability_process.html | 79 ++++++++++++++++++++++++-----------
1 file changed, 54 insertions(+), 25 deletions(-)

diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html
index 8870f8d..de8fd44 100644
--- a/security_vulnerability_process.html
+++ b/security_vulnerability_process.html
@@ -176,9 +176,7 @@ development, is very likely to be accepted; whereas a project with a
single developer who spends a few hours a month will most likey be
rejected.</p>
<p>For organizational users, a rule of thumb is that "large scale"
-means an installed base of 300,000 or more Xen guests. Other
-well-established organisations with a mature security response process
-will be considered on a case-by-case basis.</p>
+means an installed base of 300,000 or more Xen guests.</p>
<p>The list of entities on the pre-disclosure list is public. (Just
the list of projects and organisations, not the actual email
addresses.)</p>
@@ -231,35 +229,66 @@ longer permitted in accordance with MITRE policy.</p>
predisclosure-***@xenproject&lt;d<span>ot</span>&gt;org
(which is a public mailing list) if they wish to receive
pre-disclosure of advisories.
-<p>Please include in the e-mail:</p>
+<p>You must include in the e-mail:</p>
<ul>
<li>The name of your organization</li>
- <li>A brief description of why you fit the criteria, along with
- evidence to support the claim</li>
- <li>A security alias e-mail address (no personal addresses -- see
- below)</li>
- <li>A link to a web page with your security policy statement</li>
+ <li>Domain name(s) which you use to provide Xen software/services</li>
+ <li>A brief description of why you fit the criteria</li>
+ <li>If not all of your products/services use Xen, a list of (some
+ of) your products/services (or categories thereof) which do.</li>
+ <li>Link(s) to current public web pages, belonging to your
+ organisation, for each of following pieces of information:
+ <ul>
+ <li>Evidence of your status as a service/software provider:
+ <ul>
+ <li>If you are a public hosting provider, your public rates
+ or how to get a quote</li>
+ <li>If you are a software provider, how your
+ software can be downloaded or purchased</li>
+ <li>If you are an open-source project, a mailing list
+ archive and/or version control repository, with
+ active development</li>
+ </ul>
+ </li>
+ <li>Evidence of your status as a user/distributor of Xen:
+ <ul>
+ <li>Statements about, or descriptions of, your eligible
+ production services or released software, from which it is
+ immediately evident that they use Xen.
+ </ul>
+ </li>
+ <li>Information about your handling of security problems:
+ <ul>
+ <li>Your invitation to members of the public, who discover
+ security problems with your products/services, to report
+ them in confidence to you;
+ <li>Specifically, the contact information (email addresses or
+ other contact instructions) which such a member of the
+ public should use.
+ </ul>
+ </li>
+ </ul>
+ <p>Blog postings, conference presentations, social media pages,
+ Flash presentations, videos, sites which require registration,
+ anything password-protected, etc., are not acceptable. PDFs of
+ reasonable size are acceptable so long as the URL you provide is
+ of a ordinary HTML page providing a link to the PDF.</p>
+ <p>If the pages are long and/or PDFs are involved, your email
+ should say which part of the pages and documents are relevant.</p>
+ </li>
<li>A statement to the effect that you have read this policy and
agree to abide by the terms for inclusion in the list, specifically
the requirements to regarding confidentiality during an embargo
period</li>
- <li>Evidence that will be considered may include the following:
- <ul>
- <li>If you are a public hosting provider, a link to a web page
- with your public rates</li>
- <li>If you are a software provider, a link to a web page where
- your software can be downloaded or purchased</li>
- <li>If you are an open-source project, a link to a mailing list
- archive and/or a version control repository demonstrating active
- development</li>
- <li>A public key signed with a key which is in the PGP "strong
- set"</li>
- </ul>
- </li>
+ <li>The single (non-personal) email alias you wish added to the
+ predisclosure list.</li>
</ul>
-<p>Organizations already on the list who do not have a security alias
-or have not sent a statement that they have read this policy and will
-abide by, it will be asked to do so. </p>
+<p>Your application will be determined by the Xen Project Security
+Team, and their decision posted to the list. The Security Team has
+no discretion to accept applications which do not provide all of the
+information required above.</p>
+<p>If you are dissatisfied with the Security Team's decision you may
+appeal it via the Xen Project's governance processes.</p>
<p>Organisations should not request subscription via the mailing list
web interface. Any such subscription requests will be rejected and
ignored.</p>

[Ian Jackson]

Post by Ian Jackson
I would like to propose the following series of changes to the Xen
Project Security Policy. For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.

...

Post by Ian Jackson
I am going to wait a week to see if anyone has any further comments.
If not, I will ask the Xen Project Community Manager to conduct the
formal approval process.

Lars, can you please conduct the formal approval process for this set
of changes.

Regards,
Ian.

[Lars Kurth]

Sure,
when I get into the office
Lars

Post by Ian Jackson

Post by Ian Jackson
I would like to propose the following series of changes to the Xen
Project Security Policy. For readability I have presented them as
diffs to a reasonably-plausibly-formatted HTML.

...

Post by Ian Jackson
I am going to wait a week to see if anyone has any further comments.
If not, I will ask the Xen Project Community Manager to conduct the
formal approval process.

Lars, can you please conduct the formal approval process for this set
of changes.
Regards,
Ian.

[George Dunlap]

On Thu, Oct 9, 2014 at 12:06 AM, Ian Jackson

Post by Ian Jackson

Post by Xen Project Security Team
We welcome any feedback on our decisions and we look forward to
clearer directions from the community.

Here is my own, purely personal, response with answers to the
questions asked. NB that this is not the opinion of Citrix nor of
the Xen Project Security Team. But I thought I would at least write
down something concrete for people to argue about.

Post by Xen Project Security Team
Sharing amongst predisclosure list members

I think that the answer should be `yes', in principle. There seems
little point forbidding this.
Allowing greater sharing would perhaps allow problems with patches to
be discovered (and the revised patches developed) more easily. We
should provide a clear channel for collaboration between predisclosure
list members.
Therefore, the policy should be extended by adding, before
List members are allowed to share fixes to embargoed issues,
analysis, etc., with the security teams of other list members.
Technical measures must be taken to prevents non-list-member
organisations, or unauthorised staff in list-member organisations,
from obtaining the embargoed materials.
The Xen Project provides the mailing list
for this purpose. List members are encouraged to use it but
may share with other list members' security teams via other
channels.
The -discuss list's distribution is identical to that of the primary
predisclosure list xen-security-issues. Recipient organisations who
do not wish to receive all of the traffic on -discuss should use
recipient-side email filtering based on the provided `List-Id'.
The -discuss list is moderated by the Xen Project Security Team.
Announcements of private availability of fixed versions, and
technical messages about embargoed advisories, will be approved.
Messages dealing with policy matters will be rejected with a
reference to the Security Team contact address and/or public Xen
mailing lists.
(That list obviously doesn't exist yet, but if the policy is approved
we will create it.)
One reason for permitting this is that we want fairness between
service providers who use their own versions of Xen, and ones who use
a version from a software provider. Both kinds of service provider
should be able to test the fix during the embargo.

+1.

[Jan Beulich]

Post by Ian Jackson

Post by Xen Project Security Team
Sharing amongst predisclosure list members

I think that the answer should be `yes', in principle. There seems
little point forbidding this.
Allowing greater sharing would perhaps allow problems with patches to
be discovered (and the revised patches developed) more easily. We
should provide a clear channel for collaboration between predisclosure
list members.

I can see the benefits of allowing sharing, but I can also see
downsides: Along with the set of pre-disclosure list members
growing, allowing an increased amount of interchange
(including binaries) increases the risk of a leak. And since
us monitoring what is being exchanged would not be workable
in my opinion, it is also clear that it would be purely incidental
for us (or anyone else) to notice such a leak.

Post by Ian Jackson
One reason for permitting this is that we want fairness between
service providers who use their own versions of Xen, and ones who use
a version from a software provider. Both kinds of service provider
should be able to test the fix during the embargo.

I'm not sure about this fairness aspect. Yes, distro consumers can
apply to become a list member on their own (which I personally
dislike, but that's what the community wanted last time round).
But they're then still at the mercy of that distro provider, i.e. by
the time fixed packages get produced and internally tested, the
embargo may be over. In particular this would seem to increase
fairness only between equal size distro providers; smaller ones
may get further disadvantage from that due to their more limited
bandwidth of producing/testing/distributing fixes.

Therefore I would favor only first party consumers to be eligible
to join the list, and no early deployments being permitted at all.

Post by Ian Jackson

Post by Xen Project Security Team
Service announcements to non-list-member users during embargo

We should add just below the list of bullet points of things which may
Where the list member is a service provider who intends to take
disruptive action such as rebooting as part of deploying a fix (see
above): the list member's communications to its users about the
service disruption may mention that the disruption is to correct a
security issue, and relate it to the public information about the
issue (as listed above).

The noise such occasionally (as in the case that triggered this
discussion) may create certainly doesn't help the processing of
an issue "behind the scenes" (i.e. embargoed). Yes, we do
ourselves publish the embargo expiry, but maybe we should
instead reconsider doing so rather than allowing everyone to
widely announce issues (even if indirectly), resulting in all kinds
of speculation?

Post by Ian Jackson

Post by Xen Project Security Team
Predisclosure list memembership

This whole final section I completely agree with.

There's one more thing I thought of btw: When we change the
policy following whatever community input we gathered (not just
now, but also in the future), people currently on the pre-disclosure
list may (at least theoretically) end up no longer qualifying for
being on the list. Shouldn't we
- add some kind of statement to the effect of implicit agreement
to changed terms,
- provide means for list members to be removed other than by
them asking for it?

Jan

[George Dunlap]

Post by Jan Beulich

Post by Ian Jackson

Post by Xen Project Security Team
Sharing amongst predisclosure list members

I think that the answer should be `yes', in principle. There seems
little point forbidding this.
Allowing greater sharing would perhaps allow problems with patches to
be discovered (and the revised patches developed) more easily. We
should provide a clear channel for collaboration between predisclosure
list members.

I can see the benefits of allowing sharing, but I can also see
downsides: Along with the set of pre-disclosure list members
growing, allowing an increased amount of interchange
(including binaries) increases the risk of a leak. And since
us monitoring what is being exchanged would not be workable
in my opinion, it is also clear that it would be purely incidental
for us (or anyone else) to notice such a leak.

Post by Ian Jackson
One reason for permitting this is that we want fairness between
service providers who use their own versions of Xen, and ones who use
a version from a software provider. Both kinds of service provider
should be able to test the fix during the embargo.

I'm not sure about this fairness aspect. Yes, distro consumers can
apply to become a list member on their own (which I personally
dislike, but that's what the community wanted last time round).
But they're then still at the mercy of that distro provider, i.e. by
the time fixed packages get produced and internally tested, the
embargo may be over. In particular this would seem to increase
fairness only between equal size distro providers; smaller ones
may get further disadvantage from that due to their more limited
bandwidth of producing/testing/distributing fixes.

On the other hand, small distros can enlist the help of other people
on the list to help produce / test fixes. XenServer has a massive
testing framework that can be used to make sure there aren't any
accidental regressions before they publish a patch; I assume SuSE and
Oracle have something similar. But how much testing bandwidth does
Debian have for security fixes? At the moment CentOS doesn't have an
automated framework: all testing for the XSA-108 update had to happen
by hand. Being able to bring in people on the list using the
xen4centos packages would have been helpful.

-George

[Lars Kurth]

Post by Jan Beulich

Post by Xen Project Security Team
Predisclosure list memembership

This whole final section I completely agree with.
There's one more thing I thought of btw: When we change the
policy following whatever community input we gathered (not just
now, but also in the future), people currently on the pre-disclosure
list may (at least theoretically) end up no longer qualifying for
being on the list. Shouldn't we
- add some kind of statement to the effect of implicit agreement
to changed terms,
- provide means for list members to be removed other than by
them asking for it?
Jan

I also was wondering whether it would make sense to put a time-limit on applications. For example, we could say that processing an application will take 2 weeks. By doing so, we avoid having to handle applications as a response to media speculation. If we get an application wrong, and allow somebody wrong on the list who then discloses information related to an embargo, we would create risks for others already on the list. This would be the worst possible outcome for the project. Just a thought

Regards
Lars

[Ian Jackson]

Post by Lars Kurth
I also was wondering whether it would make sense to put a time-limit
on applications. For example, we could say that processing an
application will take 2 weeks. By doing so, we avoid having to
handle applications as a response to media speculation. If we get an
application wrong, and allow somebody wrong on the list who then
discloses information related to an embargo, we would create risks
for others already on the list. This would be the worst possible
outcome for the project. Just a thought

I can see that this is attractive, but on the other hand I think it
was very useful to the Xen community as a whole, that members were
able to join /during/ the last furore. I think having an artificial
delay would generate ill-feeling.

Since IMO there should be clear objective criteria, these applications
should be routine, and we shouldn't have too much trouble with them.

Ian.

[James Bulpin]

[snip]
I can see the benefits of allowing sharing, but I can also see
downsides: Along with the set of pre-disclosure list members
growing, allowing an increased amount of interchange
(including binaries) increases the risk of a leak. And since
us monitoring what is being exchanged would not be workable
in my opinion, it is also clear that it would be purely incidental
for us (or anyone else) to notice such a leak.

It's a risk but I think the benefit of having far fewer vulnerable
systems in production by the time the vulnerability is publically
disclosed outweighs the risk. Today we have a 100% probability that
there will be large numbers of vulnerable systems the day the
embargo is lifted.

Post by Ian Jackson
One reason for permitting this is that we want fairness between
service providers who use their own versions of Xen, and ones who use
a version from a software provider. Both kinds of service provider
should be able to test the fix during the embargo.

I'm not sure about this fairness aspect. Yes, distro consumers can
apply to become a list member on their own (which I personally
dislike, but that's what the community wanted last time round).
But they're then still at the mercy of that distro provider, i.e. by
the time fixed packages get produced and internally tested, the
embargo may be over. In particular this would seem to increase
fairness only between equal size distro providers; smaller ones
may get further disadvantage from that due to their more limited
bandwidth of producing/testing/distributing fixes.
Therefore I would favor only first party consumers to be eligible
to join the list, and no early deployments being permitted at all.

I view fairness here as providing a level playing field for all
concerned. If we do allow sharing then it doesn't mandate that
distros will provide fixes ahead of the embargo being lifted but
allows them to do so if they wish. Each distro can chose its own
policy without artificial constraint.

Cheers,
James

[Ian Jackson]

Post by Jan Beulich
There's one more thing I thought of btw: When we change the
policy following whatever community input we gathered (not just
now, but also in the future), people currently on the pre-disclosure
list may (at least theoretically) end up no longer qualifying for
being on the list. Shouldn't we
- add some kind of statement to the effect of implicit agreement
to changed terms,
- provide means for list members to be removed other than by
them asking for it?

Perhaps the right approach is to have a requalification process, where
each member's predisclosure list membership is reviewed periodically.

Ian.

[Ian Campbell]

Post by Ian Jackson
Please provide URLs which are accessible and legible on mobile phone
browsers, which do not require cookies enabled to load, and which
are useable with text mode browsers, browsers which do not execute
Javascript, and with screen readers and other accessibility
software. If the member of the Xen Project Security Team who
processes your application finds that their usual web browser does
not display the required information, when presented with the URLs
in your email, your application might be delayed or even rejected.

While I appreciate where you are coming from I don't think it is the
place of this policy to rail against the crapitude of the modern web and
try and enforce our own standards on things (much as I would like too).

I don't think it is unreasonable to expect that members of the security
team who typically run a browser with this crud disabled (which includes
myself) would load up their special sandboxed/throwaway browser with a
default config when faced with this sort of thing.

That said, the bits about accessibility seem less unreasonable, on the
basis that its not beyond the realms of possibility that someone
processing an application might not have the option of turning off a
screenreader etc.

Ian.

[Matt Wilson]

Post by Ian Campbell

Post by Ian Jackson
Please provide URLs which are accessible and legible on mobile phone
browsers, which do not require cookies enabled to load, and which
are useable with text mode browsers, browsers which do not execute
Javascript, and with screen readers and other accessibility
software. If the member of the Xen Project Security Team who
processes your application finds that their usual web browser does
not display the required information, when presented with the URLs
in your email, your application might be delayed or even rejected.

While I appreciate where you are coming from I don't think it is the
place of this policy to rail against the crapitude of the modern web and
try and enforce our own standards on things (much as I would like too).
I don't think it is unreasonable to expect that members of the security
team who typically run a browser with this crud disabled (which includes
myself) would load up their special sandboxed/throwaway browser with a
default config when faced with this sort of thing.
That said, the bits about accessibility seem less unreasonable, on the
basis that its not beyond the realms of possibility that someone
processing an application might not have the option of turning off a
screenreader etc.

Due to travel last week for LinuxCon EU and Linux Plumbers Conference
I've not been able to put together a reply to all the points raised a
the start of this thread.

On this point in particular, back in 2012 [1] I suggested that all
membership requests should be discussed in public on a community email
list like xen-devel, or another email list to avoid noise. The Xen
Project Security Team shouldn't have to evaluate petitions for
membership while managing an embargoed issue. I brought this up again
in 2013 [2] regarding the Coverity process.

This process works quite well for the distros email list, where
requests for membership requests are discussion on oss-security (a
public list). Protecting embargoed details should be our primary
concern here, and every time we increase the distribution of this
information we are increasing the risk it will leak. This deserves a
rigorous public debate, not a decision made under fire or undue
pressure.

--msw

[1] http://lists.xenproject.org/archives/html/xen-devel/2012-07/msg00122.html
[2] http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg03085.html

[Jan Beulich]

Post by Matt Wilson
On this point in particular, back in 2012 [1] I suggested that all
membership requests should be discussed in public on a community email
list like xen-devel, or another email list to avoid noise. The Xen
Project Security Team shouldn't have to evaluate petitions for
membership while managing an embargoed issue. I brought this up again
in 2013 [2] regarding the Coverity process.

And indeed I had intended to bring this point up too, but then forgot.
So - thanks for raising this!

Jan

[Ian Jackson]

Post by Matt Wilson
On this point in particular, back in 2012 [1] I suggested that all
membership requests should be discussed in public on a community email
list like xen-devel, or another email list to avoid noise. The Xen
Project Security Team shouldn't have to evaluate petitions for
membership while managing an embargoed issue. I brought this up again
in 2013 [2] regarding the Coverity process.

I agree that publishing applications, and the team's responses, would
be a jolly good idea. I am 100% opposed, though, to any kind of
non-objective `community consensus' process.

Such a system would (a) be unworkable in practice, because no-one
really cares about this kind of tedious makework, and (b) at serious
risk of favouritism (or its opposite).

Post by Matt Wilson
This process works quite well for the distros email list, where
requests for membership requests are discussion on oss-security (a
public list). [...]

I don't want to criticise another community's process, but I strongly
feel that our arrangements should have broad eligibility based on
objective criteria.

Ian.

[Ian Jackson]

On Mon, Nov 10, 2014 at 5:29 PM, Ian Jackson

Post by Ian Jackson
Such a system would (a) be unworkable in practice, because no-one
really cares about this kind of tedious makework, and (b) at serious
risk of favouritism (or its opposite).

"It's opposite" meaning, "We all hate company X, so let's not let them
join the list"?

Yes.

Post by Ian Jackson
I don't want to criticise another community's process, but I strongly
feel that our arrangements should have broad eligibility based on
objective criteria.

Having black-and-white rules is nice and simple and safe; but in most
reasonably "rich" domains, it's very difficult to come up with simple,
objective criteria that cover all situations satisfactorily. This is
true in morality and law; my guess is that it's true here as well.
But I'd be willing to take a look at such a list; maybe I'm wrong
about how objective we can make things. :-)

I think the spirit behind our previous criteria is objective. The
problem we had was just that the rules didn't specify enough about the
*form of the predisclosure list application*.

That's why my proposed change doesn't actually touch the criteria part
of the policy. It just formalises the application process.

Ian.

[Ian Jackson]

Post by Ian Campbell

Post by Ian Jackson
Please provide URLs which are accessible and legible on mobile phone
browsers, which do not require cookies enabled to load, and which
are useable with text mode browsers, browsers which do not execute
Javascript, and with screen readers and other accessibility
software. If the member of the Xen Project Security Team who
processes your application finds that their usual web browser does
not display the required information, when presented with the URLs
in your email, your application might be delayed or even rejected.

While I appreciate where you are coming from I don't think it is the
place of this policy to rail against the crapitude of the modern web and
try and enforce our own standards on things (much as I would like too).
I don't think it is unreasonable to expect that members of the security
team who typically run a browser with this crud disabled (which includes
myself) would load up their special sandboxed/throwaway browser with a
default config when faced with this sort of thing.

I don't think members of the security team should be expected to
either (a) set up a parallel sandboxed web browsing infrastructure,
and keep that sandbox highly available so that it can be used during a
security crisis, or (b) expose themselves to attacks of various kinds.

The security list is very different to most of the situations where I
am currently expecting to use my crud-enabled browser (as you so aptly
put it). At the moment I use my crud-enabled browser when I am
expecting to spend money, or engage with organisations that I already
have a relationship with. That is, where I have already made a
decision to trust the entity whose webshite I'm trying to look at.

I am not personally willing to take random URLs sent to me in email
from strangers and simply visit them in my usual crud-enabled browser
- the same browser I use for my internet banking. I do have a
*sandboxed* crud-enabled browser but it lives at home on a machine
which has restricted access to and from the rest of my network - and I
certainly wouldn't want to try to let it display on my Trusted
Computing Base.

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.

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.

Ian.

[Matt Wilson]

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

[...]

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

Post by Ian Jackson
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

[George Dunlap]

Post by Matt Wilson
[...]

Post by Ian Jackson
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
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.

We might remove some of the (potential) pressure to rush things by
saying that once approved, new members will not receive information
about *currently embargoed* disclosures, but only about *future*
disclosures.

I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
policy) they wouldn't have been eligible to receive XSA-108 anyway.

But perhaps that would be too unpopular to actually implement...

-George

[Matt Wilson]

[...]

Post by George Dunlap

Post by Matt Wilson
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.

We might remove some of the (potential) pressure to rush things by
saying that once approved, new members will not receive information
about *currently embargoed* disclosures, but only about *future*
disclosures.
I.e., the rush of people for XSA-108 wouldn't be in a rush because (by
policy) they wouldn't have been eligible to receive XSA-108 anyway.
But perhaps that would be too unpopular to actually implement...

The decision making mechanics aside, that makes sense to me.

--msw

[Ian Campbell]

Post by Matt Wilson
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
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.

Post by Matt Wilson
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.

[Lars Kurth]

Post by Ian Campbell

Post by Matt Wilson
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
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. The two may provide a good balance, and allow for some flexibility in ambiguous cases.

In particular if we either have a strong owner or follow the "two +1 with no -1" model of a set of decision makers who earned that status over time. More or less what we use for access to Coverity Scan output.

Regards
Lars

[Ian Campbell]

Post by Lars Kurth

Post by Ian Campbell

Post by Matt Wilson
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
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.

[Bastian Blank]

Post by Ian Jackson
The -discuss list is moderated by the Xen Project Security Team.
Announcements of private availability of fixed versions, and
technical messages about embargoed advisories, will be approved.
Messages dealing with policy matters will be rejected with a
reference to the Security Team contact address and/or public Xen
mailing lists.

Why do you think such a hypotetical list needs to be moderated?

Post by Ian Jackson
List members who are service providers may deploy fixed versions
during the embargo, PROVIDED THAT any action taken by the service
provider gives no indication (to their users or anyone else) as to
the nature of the vulnerability.

Why this constraint to "who are service providers"?

Post by Ian Jackson
The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.
The Security Team has no discretion to accept applications which do
not provide all of the information required above.

Is there are particular reason why do you want to restrict them?

Bastian

[James Bulpin]

[snip]

Post by Ian Jackson
List members who are service providers may deploy fixed versions
during the embargo, PROVIDED THAT any action taken by the service
provider gives no indication (to their users or anyone else) as to
the nature of the vulnerability.

Why this constraint to "who are service providers"?

+1

We already have a definition of eligibility for membership of the
pre-disclosure list and therefore I don't think it is necessary or
desirable to further constrain specific privileges to subsets of the
list members.

Cheers,
James

[Ian Jackson]

Post by Bastian Blank

Post by Ian Jackson
The -discuss list is moderated by the Xen Project Security Team.
Announcements of private availability of fixed versions, and
technical messages about embargoed advisories, will be approved.
Messages dealing with policy matters will be rejected with a
reference to the Security Team contact address and/or public Xen
mailing lists.

Why do you think such a hypotetical list needs to be moderated?

Good question. Primarily because I anticipate two potential failure
modes:

1. People posting non-password-protected URLs, or the like. If the
list is moderated we can notice this quickly and hopefully have
things taken down.

2. Predisclosure list members using the embargoed-information-sharing
forum as a venue for political consensus-building, planning, and
pressurising.

Of these I am most worried about the 2nd.

We have already suffered from a few very dramatic incidents, where
predisclosure list members used their privileged informational
position to try to gain advantage in policymaking and policy
interpretation.

The idea that the predisclosure list members are somehow the most
proper or most real stakeholders and that it is their opinion which
ought to count is distressingly prevalent - especially, it appears,
amongst some of the senior management of some predisclosure list
members. When a security crisis is in full swing, such management
often becomes involved. As I say we have had multiple occasions
where intense political pressure was applied.

It would be a very bad idea to explicitly provide a forum which
predisclosure list members - whose interests are ill-aligned with
those of the public at large - could use for confidential lobbying,
political coordination, and networking. (It might even be illegal;
private collusion by predisclosure list members to manipulate
policymaking might well sometimes be illegal in any case.)

If the list is to be unmoderated, at the very least, we would need an
automatic mechanism which would publish all of the exchanges on a
particular issue at the end of its embargo. ATM we don't have
software to do that.

Post by Bastian Blank

Post by Ian Jackson
List members who are service providers may deploy fixed versions
during the embargo, PROVIDED THAT any action taken by the service
provider gives no indication (to their users or anyone else) as to
the nature of the vulnerability.

Why this constraint to "who are service providers"?

Thanks for pointing out this problem.

This was not intended to be a constraint; it was intended to mean
`_even_ those who are service providers'. Since it was previously
`obvious' that people with private Xen deployments can deploy fixes
when they get them.

I will make a revised proposal for wording in this area.

Post by Bastian Blank

Post by Ian Jackson
The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.
The Security Team has no discretion to accept applications which do
not provide all of the information required above.

Is there are particular reason why do you want to restrict them?

As a member of the Security Team I would like to be able to say `sorry
your application did not qualify'. I don't want to have to say `sorry
your application didn't quite meet the criteria and we have chosen not
to exercise our discretion'.

Thanks,
Ian.

[Ian Campbell]

create ^
thanks

Initial post wasn't bcc-d to the bug tracker.

[x***@bugs.xenproject.org]

Post by Ian Campbell
create ^

Created new bug #44 rooted at `<***@mariner.uk.xensource.com>'
Title: `Security policy ambiguities - XSA-108 process post-mortem'

Post by Ian Campbell
thanks

Finished processing.

Modified/created Bugs:
- 44: http://bugs.xenproject.org/xen/bug/44 (new)

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs
Contact xen-bugs-***@bugs.xenproject.org with any infrastructure issues

[Lars Kurth]

Post by Matt Wilson
On this point in particular, back in 2012 [1] I suggested that all
membership requests should be discussed in public on a community email
list like xen-devel, or another email list to avoid noise. The Xen
Project Security Team shouldn't have to evaluate petitions for
membership while managing an embargoed issue. I brought this up again
in 2013 [2] regarding the Coverity process.

Matt,
I don’t have an issue with such an approach, in particular as this is a proven model elsewhere. I would like to understand though how the oss-security process works in practice. Aka how are decisions made, who can join the list, how are conflicts resolved, etc. It seems to me that such a process would be more transparent and also fair. In particular, if we have clear criteria as to what needs to be in place to be eligible.
It seems to me that if we do this, we may need to look at the Project Governance as well, as having a stake in decision making requires maintainer status today. The existing decision making process could easily be used to discuss access related to Coverity. It is not entirely clear to me whether maintainers should have to carry the burden of making decisions on who can join the pre-disclosure list.
Do you expect that maintainers would decide who can join the pre-disclosure list after a public discussion?
Or is there another group of community members who have earned some kind of credibility to make decisions? And if so, who are they and how is credibility earned? I am assuming that oss-security has developed its own group of distinguished members.
Also, we would need to ensure that requests are not dropped and that the required admin works (adding entities who qualify to the pre-disclosure list as well as adding them to the website).
Best Regards
Lars

[Matt Wilson]

Post by Lars Kurth

Post by Matt Wilson
On this point in particular, back in 2012 [1] I suggested that all
membership requests should be discussed in public on a community email
list like xen-devel, or another email list to avoid noise. The Xen
Project Security Team shouldn't have to evaluate petitions for
membership while managing an embargoed issue. I brought this up again
in 2013 [2] regarding the Coverity process.

Matt,
I don’t have an issue with such an approach, in particular as this
is a proven model elsewhere. I would like to understand though how
the oss-security process works in practice. Aka how are decisions
made, who can join the list, how are conflicts resolved, etc. It
seems to me that such a process would be more transparent and also
fair. In particular, if we have clear criteria as to what needs to
be in place to be eligible.

Indeed, the criteria for the distros and linux-distros lists are less
completely spelled out compared to the current Xen pre-disclosure
criteria. You have to look through the discussions on oss-security to
see how requests are evaluated. Typically there is a bias toward not
adding new people to the list unless there is a clear justification
through debate. It's much less of a "if you can tick all these boxes"
process and more of a discussion.

Consider this similar to "how do I get my patch applied to the
hypervisor?" You propose a patch, it is debated, and if it is good for
the project it will be applied. It may not be good for the project, in
which case it will not be applied. Some people may say this is unfair,
and that individuals or organizations that get their patches applied
have an advantage over others.

What is the conflict resolution path for "my patch isn't being applied
to upstream Xen"? :-)

Post by Lars Kurth
It seems to me that if we do this, we may need to look at the
Project Governance as well, as having a stake in decision making
requires maintainer status today. The existing decision making
process could easily be used to discuss access related to
Coverity. It is not entirely clear to me whether maintainers should
have to carry the burden of making decisions on who can join the
pre-disclosure list.

I believe that strong projects have strong owners. I worry about
projects that fall quickly to making decisions by committee. The "two
+1 with no -1" model that you proposed for Coverity in [1] seems to be
a reasonable balance.

Post by Lars Kurth
Do you expect that maintainers would decide who can join the
pre-disclosure list after a public discussion?

I think this is up for discussion. If the Xen Project community (in
particular, those who do the work) wants to take a voting approach or
an individual maintainer / set of maintainers approach. For the
distros@ list, ultimately I think it comes down to what Alexander (aka
Solar Designer <***@openwall.com>) decides to do, after being
informed by the debate and overall consensus on the list.

Post by Lars Kurth
Or is there another group of community members who have earned some
kind of credibility to make decisions? And if so, who are they and
how is credibility earned? I am assuming that oss-security has
developed its own group of distinguished members.

It has, largely though known individuals who are active in coordinated
security response over the years. Though at the end of the day
Alexander is the one who has to do the changes to the remailer.

Post by Lars Kurth
Also, we would need to ensure that requests are not dropped and that
the required admin works (adding entities who qualify to the
pre-disclosure list as well as adding them to the website).

I think this is the same as getting a patch applied. Patches get
dropped. People proposing patches send pings. Maintainers get
busy. This is a part of life in working with open source projects. I
think it's best to avoid strict request SLAs, just as we don't have a
"your patch will be applied in 7 days" SLA.

--msw

[1] http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg02366.html

[Lars Kurth]

Post by Matt Wilson

Post by Lars Kurth
I don’t have an issue with such an approach, in particular as this
is a proven model elsewhere. I would like to understand though how
the oss-security process works in practice. Aka how are decisions
made, who can join the list, how are conflicts resolved, etc. It
seems to me that such a process would be more transparent and also
fair. In particular, if we have clear criteria as to what needs to
be in place to be eligible.

Indeed, the criteria for the distros and linux-distros lists are less
completely spelled out compared to the current Xen pre-disclosure
criteria. You have to look through the discussions on oss-security to
see how requests are evaluated. Typically there is a bias toward not
adding new people to the list unless there is a clear justification
through debate. It's much less of a "if you can tick all these boxes"
process and more of a discussion.

The changes on the table are really more practical and aim at demonstrating a) use of Xen and b) a mature security vulnerability process. So I don't think there is a contradiction with having criteria.

Post by Matt Wilson
Consider this similar to "how do I get my patch applied to the
hypervisor?" You propose a patch, it is debated, and if it is good for
the project it will be applied. It may not be good for the project, in
which case it will not be applied. Some people may say this is unfair,
and that individuals or organizations that get their patches applied
have an advantage over others.
What is the conflict resolution path for "my patch isn't being applied
to upstream Xen"? :-)

Maintainer(s) > committer(s) > project lead (> advisory board in some extremely rare circumstances) - in practice however, 99.99% of all issues get resolved at maintainers & committers stage without a vote. I cannot recall an issue where the project lead had to step in as long as I worked with the project and we never had the AB engaged.

To make this work within the existing governance, we would need the equivalent of maintainer(s) > committer(s) > project lead for the pre-disclosure list. We don't have to have a full hierarchy: a project lead makes no sense in this case, or the project lead would just be the Xen HV project lead. If we compare with oss-sec the equivalent of the committer is Alexander.

So I guess what I am saying is that this is doable, without governance changes.

Post by Matt Wilson

Post by Lars Kurth
It seems to me that if we do this, we may need to look at the
Project Governance as well, as having a stake in decision making
requires maintainer status today. The existing decision making
process could easily be used to discuss access related to
Coverity. It is not entirely clear to me whether maintainers should
have to carry the burden of making decisions on who can join the
pre-disclosure list.

I believe that strong projects have strong owners. I worry about
projects that fall quickly to making decisions by committee. The "two
+1 with no -1" model that you proposed for Coverity in [1] seems to be
a reasonable balance.

I stated before that we hardly ever use the voting model for day-to-day activities. Only for process changes, new projects and committer/project lead elections. Personally, I believe that avoiding a formal vote in this case is preferable.

So the question then would be who would be the owner (aka maintainer and/or committer) of the security pre-disclosure list. The only natural candidates we have right now are members of the Security Team. Of course this may evolve over time, in particular if people who have already a standing in the wider FOSS security community get actively engaged with the process.

So assuming that someone from the Security Team is willing to step up, and the community agrees, this could be done. But in practice, the burden would still fall onto members of Security Team and all we would change is to create more transparency - at least in the short term. Please do correct me, if you think I am wrong.

Post by Matt Wilson

Post by Lars Kurth
Also, we would need to ensure that requests are not dropped and that
the required admin works (adding entities who qualify to the
pre-disclosure list as well as adding them to the website).

I think this is the same as getting a patch applied. Patches get
dropped. People proposing patches send pings. Maintainers get
busy. This is a part of life in working with open source projects. I
think it's best to avoid strict request SLAs, just as we don't have a
"your patch will be applied in 7 days" SLA.

That is OK. A bit of a filter on the seriousness of someone requesting to be on the list.

Regards
Lars

[Matt Wilson]

Post by Lars Kurth

Post by Matt Wilson

Post by Lars Kurth
I don’t have an issue with such an approach, in particular as this
is a proven model elsewhere. I would like to understand though how
the oss-security process works in practice. Aka how are decisions
made, who can join the list, how are conflicts resolved, etc. It
seems to me that such a process would be more transparent and also
fair. In particular, if we have clear criteria as to what needs to
be in place to be eligible.

Indeed, the criteria for the distros and linux-distros lists are less
completely spelled out compared to the current Xen pre-disclosure
criteria. You have to look through the discussions on oss-security to
see how requests are evaluated. Typically there is a bias toward not
adding new people to the list unless there is a clear justification
through debate. It's much less of a "if you can tick all these boxes"
process and more of a discussion.

The changes on the table are really more practical and aim at
demonstrating a) use of Xen and b) a mature security vulnerability
process. So I don't think there is a contradiction with having
criteria.

I don't think a) and b) are nearly enough. The bar needs to be set a
lot higher. But this is something we can discuss in a different part
of the thread.

Post by Lars Kurth

Post by Matt Wilson
Consider this similar to "how do I get my patch applied to the
hypervisor?" You propose a patch, it is debated, and if it is good for
the project it will be applied. It may not be good for the project, in
which case it will not be applied. Some people may say this is unfair,
and that individuals or organizations that get their patches applied
have an advantage over others.
What is the conflict resolution path for "my patch isn't being applied
to upstream Xen"? :-)

Maintainer(s) > committer(s) > project lead (> advisory board in
some extremely rare circumstances) - in practice however, 99.99% of
all issues get resolved at maintainers & committers stage without a
vote. I cannot recall an issue where the project lead had to step in
as long as I worked with the project and we never had the AB
engaged.

I was asking tongue-in-cheek...

Usually things get sorted out through email discussion and a general
consensus is reached. I think we get a bit caught up in defining
parliamentary procedure for situations that rarely, if ever, come up.

Post by Lars Kurth
To make this work within the existing governance, we would need the
equivalent of maintainer(s) > committer(s) > project lead for the
pre-disclosure list. We don't have to have a full hierarchy: a
project lead makes no sense in this case, or the project lead would
just be the Xen HV project lead. If we compare with oss-sec the
equivalent of the committer is Alexander.

To me, I think that the existing Xen Project meritocracy structure
should work. Those who do the work (i.e., frequent contributors,
maintainers, etc) have shown a commitment to the health and well-being
of the project and the community. I don't think that this needs to be
a function or system that is apart from how the community makes other
decisions.

Post by Lars Kurth
So I guess what I am saying is that this is doable, without governance changes.

I think so too.

Post by Lars Kurth

Post by Matt Wilson

Post by Lars Kurth
It seems to me that if we do this, we may need to look at the
Project Governance as well, as having a stake in decision making
requires maintainer status today. The existing decision making
process could easily be used to discuss access related to
Coverity. It is not entirely clear to me whether maintainers should
have to carry the burden of making decisions on who can join the
pre-disclosure list.

I believe that strong projects have strong owners. I worry about
projects that fall quickly to making decisions by committee. The "two
+1 with no -1" model that you proposed for Coverity in [1] seems to be
a reasonable balance.

I stated before that we hardly ever use the voting model for
day-to-day activities. Only for process changes, new projects and
committer/project lead elections. Personally, I believe that
avoiding a formal vote in this case is preferable.

+1

Post by Lars Kurth
So the question then would be who would be the owner (aka maintainer
and/or committer) of the security pre-disclosure list. The only
natural candidates we have right now are members of the Security
Team. Of course this may evolve over time, in particular if people
who have already a standing in the wider FOSS security community get
actively engaged with the process.

I think that this may only really matter in cases where someone needs
to referee in the case of lack of consensus.

Post by Lars Kurth
So assuming that someone from the Security Team is willing to step
up, and the community agrees, this could be done. But in practice,
the burden would still fall onto members of Security Team and all we
would change is to create more transparency - at least in the short
term. Please do correct me, if you think I am wrong.

I'm not so sure. I think first we need to have community consensus on
disclosure membership decisions. This is more than transparency, it's
also moving the decision making process into the community. The only
question to me is when there isn't a community consensus, in which
case it seems like the Last Resort mechanisms in the Project
Governance should be a way to remove the burden.

Post by Lars Kurth

Post by Matt Wilson

Post by Lars Kurth
Also, we would need to ensure that requests are not dropped and that
the required admin works (adding entities who qualify to the
pre-disclosure list as well as adding them to the website).

I think this is the same as getting a patch applied. Patches get
dropped. People proposing patches send pings. Maintainers get
busy. This is a part of life in working with open source projects. I
think it's best to avoid strict request SLAs, just as we don't have a
"your patch will be applied in 7 days" SLA.

That is OK. A bit of a filter on the seriousness of someone
requesting to be on the list.

--msw

[Ian Jackson]

Post by Matt Wilson

Post by Lars Kurth
The changes on the table are really more practical and aim at
demonstrating a) use of Xen and b) a mature security vulnerability
process. So I don't think there is a contradiction with having
criteria.

I don't think a) and b) are nearly enough. The bar needs to be set a
lot higher. But this is something we can discuss in a different part
of the thread.

I agree with Ian Campbell on this topic. The predisclosure list ought
to remain very broad. Like Ian, I would give very different answers
to all the other questions, if the membership criteria were narrowed.

Ian.

[James Bulpin]

[snip]
It is (still!) ambiguous whether predisclosure list members may share
fixes and other information with other predisclosure list members. We
intended to fix this ambiguity following the XSA-7 discussion but
the policy was never updated.
During the XSA-108 embargo the Security Team were asked whether this
permitted; we concluded that since we had said `yes' last time, and
documented this in the XSA-7 postmortem, and the community had failed
to change the policy, we should probably say `yes' again.
The community should formally correct this ambiguity.

I would like to see it explicitly permitted for predisclosure list members
to share source and binary fixes along with impact and mitigation
information with each other. The latter is important as a Xen distributor
may wish to interpret the raw information in terms more meaningful to
that distributor's users (for example if the distributor's product hides
PV/HVM/etc virt mode behind templates then that distributor may wish to
inform its users which templates are impacted rather than the more raw
form of (e.g.) "PV guests").

[snip]
Deployment on public systems of fixed versions during embargo
=============================================================
It is ambiguous whether the wording above prohibits deployment by a
service provider of patched hosting software running customer VMs.
Some predisclosure list members thought that this was prohibited;
others thought that it was permitted and accordingly deployed the
XSA-108 fix during the embargo.
This question should be resolved, clearly, one way or the other.

I would like to see it explicitly permitted for _any_ predisclosure
list member to deploy a fix on production systems before the embargo
is lifted. However there should be an "exception" mechanism for the
(hopefully uncommon) case that such a deployment would create an
unacceptably high probability of the details of the vulnerability
being discoverable. This exception mechanism would be used based on
the judgement of the Security Team with post-mortems used to provide
feedback on this decision making if necessary.

Cheers,
James

[Tim Deegan]

Post by James Bulpin

[snip]
It is (still!) ambiguous whether predisclosure list members may share
fixes and other information with other predisclosure list members. We
intended to fix this ambiguity following the XSA-7 discussion but
the policy was never updated.
During the XSA-108 embargo the Security Team were asked whether this
permitted; we concluded that since we had said `yes' last time, and
documented this in the XSA-7 postmortem, and the community had failed
to change the policy, we should probably say `yes' again.
The community should formally correct this ambiguity.

I would like to see it explicitly permitted for predisclosure list members
to share source and binary fixes along with impact and mitigation
information with each other. The latter is important as a Xen distributor
may wish to interpret the raw information in terms more meaningful to
that distributor's users (for example if the distributor's product hides
PV/HVM/etc virt mode behind templates then that distributor may wish to
inform its users which templates are impacted rather than the more raw
form of (e.g.) "PV guests").

[snip]
Deployment on public systems of fixed versions during embargo
=============================================================
It is ambiguous whether the wording above prohibits deployment by a
service provider of patched hosting software running customer VMs.
Some predisclosure list members thought that this was prohibited;
others thought that it was permitted and accordingly deployed the
XSA-108 fix during the embargo.
This question should be resolved, clearly, one way or the other.

I would like to see it explicitly permitted for _any_ predisclosure
list member to deploy a fix on production systems before the embargo
is lifted.

I reluctantly agree.

The original purpose (IIRC) of the predisclosure list was to allow
development and testing of fixes to happen in advance of disclosure.
Adding large service providers to the list increased fairness: they
are likely to have modified or wholly custom-built Xen distributions
requiring their own dev & test work, and so would be at a disadvantage
when the vulnerability was disclosed. Allowing them to _deploy_ in
advance, however, gives them an advantage over non-members -- their
systems are demonstrably more secure.

However, I think that given the community's decision to widen the
predisclosure list as much as it has (so that it now covers basically
any service provider), that advantage goes away. In which case we
should allow deployment on the grounds that it means fewer unpatched
systems when the embargo expires.

There is a slippery-slope argument here that having such a large list
means that details will inevitably leak, and we might as well save
ourselves all this effort and disclose immediately, but I don't really
believe it. :) All I'll say for that is that we should be very clear
about the expectation that predisclosure periods will be _short_.

Cheers,

Tim.