Re: [edk2-devel] pixiefail

["Laszlo Ersek" <lersek@redhat.com>]

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 <lersek@redhat.com
> <mailto: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
>     <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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-