From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id C35FFD807AB for ; Wed, 24 Jan 2024 15:27:13 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=cWS+ldoS5KCrCWb2uPAciY/UR18HPKWxoS7dxm9ZWhg=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1706110032; v=1; b=Bl6arUGMNaBAXxvbPBtYJ8jqoZk4PVhtxE8pB+PigKBwhAP392LSnJGiNQmsBssJ6tBUISXa T9It352mNqyNFSU0QPt698eZNHkTUTpkyOS0/T5JSM0glXYtjFL0m9mXKKKjrtyADujYMc4k+ar UFtF+Anfjh3V9Gf2ADkpbYxY= X-Received: by 127.0.0.2 with SMTP id 81kWYY7687511x1WBcAnWyns; Wed, 24 Jan 2024 07:27:12 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.25417.1706110026894423344 for ; Wed, 24 Jan 2024 07:27:07 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-193-5lE77vf3N1e5fKUnNdYMiA-1; Wed, 24 Jan 2024 10:27:02 -0500 X-MC-Unique: 5lE77vf3N1e5fKUnNdYMiA-1 X-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B5FBE185A78A; Wed, 24 Jan 2024 15:27:01 +0000 (UTC) X-Received: from [10.39.195.127] (unknown [10.39.195.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CA237C2E1E8; Wed, 24 Jan 2024 15:27:00 +0000 (UTC) Message-ID: <6a15eb13-8ab2-0355-f9fa-e2b15805b2ae@redhat.com> Date: Wed, 24 Jan 2024 16:26:59 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] pixiefail To: Vincent Zimmer , devel@edk2.groups.io Cc: dougflick@microsoft.com, Gerd Hoffmann , Jon Maloy References: From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: U0iCPK9C1L0V10BCpmhKnSMVx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=Bl6arUGM; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) On 1/24/24 16:20, Vincent Zimmer wrote: > I agree on your sentiment about Bugzilla (bz) not being ideal for this. > This space has been a multi-year journey from usrt-based tickets, > bespoke advisories, bz, etc into today's world of tianocore infosec, > tianocore as its own CVE Naming Authority (CNA) and working to leverage > the extant features of github. On that latter point, there is work afoot > to evolve from the present bz-based process > https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues to a github-based one https://github.com/tianocore/tianocore.github.io/wiki/GHSA-GitHub-Security-Advisories-Proceess-(Draft) . Things are in transition now and I'd echo Doug's sentiment that getting more feedback and engagement from the community would be valuable in getting the various parts tested, evolved, documented, reviewed, etc. > Vincent The wiki article (draft) on the GHSA process looks great! I didn't know! Thanks! Laszlo > > On Wed, Jan 24, 2024 at 6:57 AM Laszlo Ersek > wrote: > > On 1/24/24 15:35, Laszlo Ersek wrote: > > > I figure the most flexible approach for those that dislike email-based > > review for embargoed patches would be if github.com > supported locked > > down *PRs* (i.e., not private organizatons). In other words, if those > > PRs would be submitted against the same base repository and master > > branch as every other PR, *but* they wouldn't be visible to anyone > > except to a restricted group, and could never be merged. (For merging, > > the approved version of the series would have to be posted publicly, > > after the embargo.) > > > > ... Technically, the last paragraph could be implemented with current > > github.com features: create a locked-down > organization, fork edk2 under > > that organization (without adding any non-upstream changes to the > fork), > > and submit the embargoed patch series as a PR against the fork. Never > > merge the patch set into the fork (only use the fork for patch > review). > > Well, running the usual CI checks on the embargoed patch set, *inside > the fork*, would be an extra problem... I don't know how github.com > > accounts for CI minutes in forks. Especially closed forks. > > Laszlo > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114311): https://edk2.groups.io/g/devel/message/114311 Mute This Topic: https://groups.io/mt/103913088/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-