From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78BC1C4338F for ; Fri, 23 Jul 2021 13:09:59 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 217A960E8C for ; Fri, 23 Jul 2021 13:09:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 217A960E8C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=umich.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.160109.294402 (Exim 4.92) (envelope-from ) id 1m6uvw-0007It-D8; Fri, 23 Jul 2021 13:09:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 160109.294402; Fri, 23 Jul 2021 13:09:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1m6uvw-0007Im-AJ; Fri, 23 Jul 2021 13:09:44 +0000 Received: by outflank-mailman (input) for mailman id 160109; Fri, 23 Jul 2021 13:09:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1m6uvu-0007Ig-4m for xen-devel@lists.xenproject.org; Fri, 23 Jul 2021 13:09:42 +0000 Received: from mail-ed1-x531.google.com (unknown [2a00:1450:4864:20::531]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3c0c4be2-3c5e-4cd5-b1ac-07e5fbee84bc; Fri, 23 Jul 2021 13:09:40 +0000 (UTC) Received: by mail-ed1-x531.google.com with SMTP id k15so1640468edq.13 for ; Fri, 23 Jul 2021 06:09:40 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3c0c4be2-3c5e-4cd5-b1ac-07e5fbee84bc DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rRCzeO219V/p2TwkNxchXI7lnEXVmeMIUIGjhcs9Cmc=; b=Gve9eT3FTWtBeRJta891nIb8UUgzP17toaBL/RargwdNQBGJOa3CixohERx3eWJo6R RsJZPwPVjoowy/K8N5ntIA9fXqf8h1X/EntqBd0k917FERdLzZqb5Lp4OCTKS98F4NuR xWPGCFrzeStcAlqJPtNN66keuNU1rfQPKK6gphVDq96CPCNp4QW/Xmtpl3N2Ld1yte8h d0Lv4wPfGAINObFcQLbhsTFU4lu3obDL610xZoCXQV7uPI0N+RNsExRGt2yhLzS5QZFG BskV5NnfEeupwErZLFSGMEMbbSdVMUovcdds/3bzlQanXizKVygi9113iLoAWZlP/Dgf pAAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rRCzeO219V/p2TwkNxchXI7lnEXVmeMIUIGjhcs9Cmc=; b=YMKV/8AyQlH05yOeguaZ25YgvQUX65UUd7imeG3neviW+V+ItPlkfeNMWxzQIh/g+O eRedMIh3biBXg4d+E+EIT5+kfOsuQ/SXpo6wRi93E4WqYAuh3sSgRqJUxnMGMXb0++af qOXLgE6Yxl48xaagkkB8/Yl9T4XGZsGuk7bj2y0DRDZOzlEPV2QYGS2whB4KxQd2c1fB MYFDKS7so3TeFrE3ZyjjlpHekTDA5d2WE4fDHBv9huQM5e9g7gmw+L+u2VC/2VwHtOUA gc5wFg+tpnhvmurdyZdvrVTKV4ijyYSlXhferXAC8YcQ3nODO1pte2+/YayIgL8io/Dt kOjA== X-Gm-Message-State: AOAM532nYyTji//IdHUucDeNIJmaNspPfwZ3A7VIHgYfNqaGvCPj/3F/ Ouvck9gbh8WAEAFo9CsxafjsRAVVOaSGjPEMEh0= X-Google-Smtp-Source: ABdhPJx+jSbNzbaJnnWuUzAsdb5uut9qOiEPl7V6+jaybztx+I60jl3/lqVoy389jbonlvhjNKVp4klPRmdK6RfjBio= X-Received: by 2002:a05:6402:2206:: with SMTP id cq6mr5499274edb.209.1627045779797; Fri, 23 Jul 2021 06:09:39 -0700 (PDT) MIME-Version: 1.0 References: <87r1fzclw0.fsf@vates.fr> <6da30009-d817-f48e-11b4-ba9c92cde93d@suse.com> <87k0lqmmf8.fsf@vates.fr> <87wnpqm380.fsf@vates.fr> <14d1b95e-9d3a-8464-010b-d7796a26a8c4@suse.com> <87tukqy9gw.fsf@vates.fr> In-Reply-To: <87tukqy9gw.fsf@vates.fr> From: George Dunlap Date: Fri, 23 Jul 2021 14:09:28 +0100 Message-ID: Subject: Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list To: "Charles-H. Schulz" Cc: Jan Beulich , xen-devel , George Dunlap Content-Type: multipart/alternative; boundary="000000000000bcf98105c7ca1dee" --000000000000bcf98105c7ca1dee Content-Type: text/plain; charset="UTF-8" On Mon, Jul 19, 2021 at 9:49 AM Charles-H. Schulz wrote: > > Jan Beulich @ 2021-07-19 08:44 CEST: > > >> > >> They act as a resource center for their downstreams, but the > information goes > >> top down, i.e from the software developer to the downstream, not the > >> opposite. Also how it entails an even bigger change to the list policy > is > >> unclear to me. > > > > For things to make sense (as you seem to agree with as per further up), > > if their downstreams aren't to subscribe to our (and perhaps other) > > pre-disclosure list themselves, the CERTs would need to act as a proxy, > > in that they'd be permitted to relay the information before the embargo > > ends. I didn't think there would be much of a difficulty seeing that > > this would be more of a change to the policy. > > Indeed, because you assume that CERTs will communicate information before > they are public. But they don't work that way in that they act as the legal > and actual hub for the public information and listing of vulnerabilities > reports (CVEs etc.) What they do before the end of the embargo date I > already > explained, and that specifically does not entail sharing the information > with > downstream users. So to me there is no big change of policy - this is the > highway patrol sharing the license plate numbers of criminals or suspects > with the city police. > Nonetheless, you still haven't made a clear case why being informed of the vulnerabilities *under embargo* is necessary. Anyone can sign up to the xen-announce mailing list and receive notifications of XSAs at the moment the embargo lifts. We advertise *that new advisories are coming out* on the main XSA webpage [1] and in a machine-readable JSON file [2] as soon as the predisclosure happens. (There are also libraries [3] to consume the JSON file, and an example program [4] which could be run in a cron job to alert someone to upcoming public XSA disclosures.) The delta between the predisclosure and the public disclosure is typically two weeks. Someone could argue that all of the activities you describe -- looking for larger patterns of vulnerabilities, acting as a clearinghouse / notification channel / advisory system for downstreams, etc -- could be done by observing the public disclosures, particularly if suitable people were alerted to upcoming public disclosures (and thus ready to process them as soon as they come out). What is needed is to make the case that this is insufficient -- that having the extra two weeks to process things before the public disclosure will be of material benefit in those activities. (Hopefully it should be clear that I'm inviting you to make such a case.) [1] https://xenbits.xenproject.org/xsa/ [2] https://xenbits.xenproject.org/xsa/xsa.json [3] https://gitlab.com/xen-project/people/gdunlap/go-xenlib/-/tree/master/xsalib [4] https://gitlab.com/xen-project/people/gdunlap/go-xenlib/-/tree/master/scripts/xsa-alert > >> The what if question is not a valid one, as you are either recognized > as a > >> national CERT (there may sometimes be more than one) or you're not, by > >> regulatory approval of some sort. Nobody else can claim they're a > national > >> CERT. > >> You can be a private CERT, but that's out of the scope of my request. > >> > >>> The present items on the list try to use pretty generic > >>> terms, while your suggestion is pretty specific. > >> > >> So how is that a problem in our this specific instance? > > > > Why would we exclude private CERTs? I could easily see there being > > countries which have no "national CERT" (for a variety of reasons), > > with some private / non-government organization jumping in. > > > > This is a good point I'm not making :) > My request is solely about national CERTs, I do not feel that I have enough > standing here requesting that private CERTs be added to the list, although > I'm sure there's a point to be made here as well. > Jan, I think if you think it's better to include "private CERTs" (do such things exist?), then it should be up to you (or someone else in favor of such a thing) to craft the criteria for inclusion. I personally think limiting ourselves to national CERTs to begin with is fine. In any case, what's needed to move things forward (absent further discussion) is: 1. Specific proposed changes to the security policy to be hammered out 2. Someone to hold a project-wide vote, in accordance with the XenProject Governance Document. Normally #2 would be me, but today is my last day until January. -George --000000000000bcf98105c7ca1dee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 19, 2021 at 9:49 AM Charl= es-H. Schulz <charles.schulz@= vates.fr> wrote:

Jan Beulich @ 2021-07-19 08:44 CEST:

>>
>> They act as a resource center for their downstreams, but the infor= mation goes
>> top down, i.e from the software developer to the downstream, not t= he
>> opposite. Also how it entails an even bigger change to the list po= licy is
>> unclear to me.
>
> For things to make sense (as you seem to agree with as per further up)= ,
> if their downstreams aren't to subscribe to our (and perhaps other= )
> pre-disclosure list themselves, the CERTs would need to act as a proxy= ,
> in that they'd be permitted to relay the information before the em= bargo
> ends. I didn't think there would be much of a difficulty seeing th= at
> this would be more of a change to the policy.

Indeed, because you assume that CERTs will communicate information before they are public. But they don't work that way in that they act as the l= egal
and actual hub for the public information and listing of vulnerabilities reports (CVEs etc.) What they do before the end of the embargo date I alrea= dy
explained, and that specifically does not entail sharing the information wi= th
downstream users. So to me there is no big change of policy - this is the highway patrol sharing the license plate numbers of criminals or suspects with the city police.

Nonetheless, you= still haven't made a clear case why being informed of the vulnerabilit= ies *under embargo* is necessary.=C2=A0 Anyone can sign up to the xen-annou= nce mailing list and receive notifications of XSAs at the moment the embarg= o lifts.=C2=A0 We advertise *that new advisories are coming out* on the mai= n XSA webpage [1] and in a machine-readable JSON file [2] as soon as the pr= edisclosure happens.=C2=A0 (There are also libraries [3] to consume the JSO= N file, and an example program [4] which could be run in a cron job to aler= t someone to upcoming public XSA disclosures.) The delta between the predis= closure and the public disclosure is typically two weeks.

Someone could argue that all of the activities you describe -- lookin= g for larger patterns of vulnerabilities, acting as a clearinghouse / notif= ication channel / advisory system for downstreams, etc -- could be done by = observing the public disclosures, particularly if suitable people were aler= ted to upcoming public disclosures (and thus ready to process them as soon = as they come out).=C2=A0 What is needed is to make the case that this is in= sufficient -- that having the extra two weeks to process things before the = public disclosure will be of material benefit in those activities.

(Hopefully it should be clear that I'm inviting you to= make such a case.)

=C2=A0
>> The what if question is not a valid one, as you are either recogni= zed as a
>> national CERT (there may sometimes be more than one) or you're= not, by
>> regulatory approval of some sort.=C2=A0 Nobody else can claim they= 're a national
>> CERT.
>> You can be a private CERT, but that's out of the scope of my r= equest.
>>
>>> The present items on the list try to use pretty generic
>>> terms, while your suggestion is pretty specific.
>>
>> So how is that a problem in our this specific instance?
>
> Why would we exclude private CERTs? I could easily see there being
> countries which have no "national CERT" (for a variety of re= asons),
> with some private / non-government organization jumping in.
>

This is a good point I'm not making :)
My request is solely about national CERTs, I do not feel that I have enough=
standing here requesting that private CERTs be added to the list, although<= br> I'm sure there's a point to be made here as well.
<= div>
Jan, I think if you think it's better to include &qu= ot;private CERTs" (do such things exist?), then it should be up to you= (or someone else in favor of such a thing) to craft the criteria for inclu= sion.=C2=A0 I personally think limiting ourselves to national CERTs to begi= n with is fine.

In any case, what's needed to move = things forward (absent further discussion) is:

1. Specific proposed changes to th= e security policy to be hammered out
2. Someone to hold a project-wide vote, = in accordance with the XenProject Governance Document.

Normally #2 would be me, b= ut today is my last day until January.

=
=C2=A0-George
--000000000000bcf98105c7ca1dee--