On 1/23/24 19:49, Doug Flick via groups.io wrote: > Gerd, > > As a new EDK2 developer, I'm working through getting the patches up > to EDK2 but I have to follow the EDK2 patch process which is not the > fastest thing to follow and also not my day job. If you want to see > where I am you can look at the CI Pipeline. The patches were reviewed > during the GHSA process by the Infosec group and have been shipping > in devices already. I'm hoping to have the patches on the mailing > list by EOD. This is a great topic for ways we can speed up the > review process and contribution process - particularly for security > patches and it would be great to get more people actively involved in > reviews and testing during creation and delivery of patches.
The review process for embargoed security patches has never been worked out, to my knowledge. Bugzilla is unsuitable for that. (I'm speaking from experience. It is impossible to comment sensibly on patches attached to bugzilla tickets, and in particular incremental reviews are terrible.) In some other projects, email based patch review remains the process for embargoed patches too, with one difference to the normal process: either no mailing list is included (that is, the email thread, including the initial posting of the series, keeps addressing the same fixed set of humans), or else, a mailing list with no public archives, and with hand-moderated memberships, is included. This permits for the same tooling (git-am for local testing, and inline review comments) as the normal, public workflow. However, some of the edk2 participants don't consider such an email-based process secure enough for circulating embargoed patches. A closed organization on github.com might be used as a replacement. That would have its own problems, though (inconsistency with the normal patch review process, extra management of memberships, disappearance of early (hence, not merged) versions of security patch sets, etc). 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). Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114304): https://edk2.groups.io/g/devel/message/114304 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] -=-=-=-=-=-=-=-=-=-=-=-
