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