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 A96E17803E1 for ; Wed, 24 Jan 2024 15:20:49 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=gb8AB7gJ0CpW7VtV+SxeAkzRzS2amKl7A9DBcwCFzSo=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1706109648; v=1; b=GDekb7SRkB/ZlsYo5/oy6qiPgWcdtPjf/o0TlXMUzkh/nHh0GvnSXpi1tJSesPds2EW9Fq0y 0QPdv7kix1cDIfobF42pWs3WdjJmZuMoLrWKHaubY7bok5oUKtHP40vplSHuvkTCD5/m6hS/rko ItXiBaIv7H34S+ObMAFIvVO8= X-Received: by 127.0.0.2 with SMTP id CGNpYY7687511xrI9IgZvLDk; Wed, 24 Jan 2024 07:20:48 -0800 X-Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by mx.groups.io with SMTP id smtpd.web11.25276.1706109647444979161 for ; Wed, 24 Jan 2024 07:20:47 -0800 X-Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-3392291b21bso4788994f8f.1 for ; Wed, 24 Jan 2024 07:20:47 -0800 (PST) X-Gm-Message-State: PQFDpG7LvkADPDfnpOhjoocEx7686176AA= X-Google-Smtp-Source: AGHT+IFDjP9jvo5JW6zktJLcpjQd19PVge7y+thFvMbrUy/ArukFuHmRXKX2RZJtVOg/XAaNsjv3wXvu7KUU2bdyorM= X-Received: by 2002:a5d:6584:0:b0:339:4759:6de9 with SMTP id q4-20020a5d6584000000b0033947596de9mr655851wru.74.1706109645292; Wed, 24 Jan 2024 07:20:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "vincent zimmer" Date: Wed, 24 Jan 2024 07:20:34 -0800 Message-ID: Subject: Re: [edk2-devel] pixiefail To: devel@edk2.groups.io, lersek@redhat.com Cc: dougflick@microsoft.com, Gerd Hoffmann , Jon Maloy 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,vincent.zimmer@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: multipart/alternative; boundary="0000000000005b0c48060fb29b28" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=GDekb7SR; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io --0000000000005b0c48060fb29b28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-Is= sues 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 On Wed, Jan 24, 2024 at 6:57=E2=80=AFAM Laszlo Ersek wr= ote: > 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 > > > >=20 > > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114310): https://edk2.groups.io/g/devel/message/114310 Mute This Topic: https://groups.io/mt/103913088/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --0000000000005b0c48060fb29b28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree on your sentiment about Bugzilla=C2=A0(bz)=C2=A0no= t 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 tianoc= ore infosec, tianocore as its own CVE Naming Authority (CNA) and working to= leverage the extant features of github. On that latter point,=C2=A0there i= s work afoot to evolve from the present bz-based process h= ttps://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Iss= ues to a github-based one=C2=A0= https://github.com/tianocore/tianocore.github.io/wiki/GHSA-GitHub-Security-= Advisories-Proceess-(Draft). Things are in transition now and I'd e= cho 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

On Wed, Jan 24, 2024 at 6:57=E2= =80=AFAM Laszlo Ersek <lersek@redha= t.com> 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<= br> > 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<= br> > git= hub.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<= br> > 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:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#114310) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--0000000000005b0c48060fb29b28--