[edk2-devel] pixiefail

[edk2-devel] pixiefail

[Gerd Hoffmann]

  Hi,

What is the state of affairs wrt. the pixiefail vulnerabilities?

The advisory is published
(https://github.com/tianocore/edk2/security/advisories/GHSA-hc6x-cw6p-gj7h),
it says the plan is to have the fixes included in the next (Feb 2024)
stable tag.  I see bugzilla has patches attached, most of them written
by Doug Flick.  There is not that much time left until code freeze
starts.  Shouldn't we get the ball rolling to get the patches reviewed
and merged?  Given that the pixiefail details where published last week
it should be ok to simply send the patches to the devel list for review.

thanks & take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114216): https://edk2.groups.io/g/devel/message/114216
Mute This Topic: https://groups.io/mt/103913088/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] pixiefail

[Doug Flick via groups.io]

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.

- Doug

-----Original Message-----
From: Gerd Hoffmann <kraxel@redhat.com>
Sent: Tuesday, January 23, 2024 8:36 AM
To: devel@edk2.groups.io; Doug Flick <dougflick@microsoft.com>
Cc: Jon Maloy <jmaloy@redhat.com>
Subject: [EXTERNAL] pixiefail

[You don't often get email from kraxel@redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

  Hi,

What is the state of affairs wrt. the pixiefail vulnerabilities?

The advisory is published
(https://github.com/tianocore/edk2/security/advisories/GHSA-hc6x-cw6p-gj7h),
it says the plan is to have the fixes included in the next (Feb 2024) stable tag.  I see bugzilla has patches attached, most of them written by Doug Flick.  There is not that much time left until code freeze starts.  Shouldn't we get the ball rolling to get the patches reviewed and merged?  Given that the pixiefail details where published last week it should be ok to simply send the patches to the devel list for review.

thanks & take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114228): https://edk2.groups.io/g/devel/message/114228
Mute This Topic: https://groups.io/mt/103913088/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] pixiefail

[Laszlo Ersek]

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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] pixiefail

[Laszlo Ersek]

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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114307): https://edk2.groups.io/g/devel/message/114307
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] pixiefail

[vincent zimmer]

[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]

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
>
>
>
> 
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114310): https://edk2.groups.io/g/devel/message/114310
Mute This Topic: https://groups.io/mt/103913088/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 3715 bytes --]

Re: [edk2-devel] pixiefail

[Laszlo Ersek]

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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] pixiefail

[Gerd Hoffmann]

On Wed, Jan 24, 2024 at 07:20:34AM -0800, 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
> 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.

The GHSA process certainly is an improvement over using patches attached
to bugzilla.  There still is room for improvement though.  Community
engagement is a problem indeed, and my overall impression is that it is
even worse than on the edk2 devel list.

I think part of the problem might be lack of notifications.  I can't
remember being notified in case the "tianocore infosec team" group is
added to a new GHSA, so it's hard to learn about new advisories ...

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114332): https://edk2.groups.io/g/devel/message/114332
Mute This Topic: https://groups.io/mt/103913088/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-