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 > > <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) > > <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 <ler...@redhat.com > <mailto:ler...@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 > <http://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 <http://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 > <http://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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
