Re: [edk2-devel] pixiefail

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

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