Re: [edk2-devel] pixiefail

["vincent zimmer" <vincent.zimmer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]

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

On Wed, Jan 24, 2024 at 6:57 AM Laszlo Ersek <lersek@redhat.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
> > 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 (#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]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 3715 bytes --]