|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem
On 14 Nov 2014, at 12:50, Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> Lars Kurth writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108
> process post-mortem"):
>> 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
>
>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |