> On Apr 15, 2019, at 11:06 PM, Wang, Jian J <jian.j.w...@intel.com> wrote: > > Laszlo, > > I got your point, and understood the requirements for source released > platforms. > I think it's something needing all vendors who have concerns to get agreement > with. It's part of 'optimization' Vincent mentioned in another email. Stephano > will set up meetings to drive related discussions. >
As Laszlo points out we are an open source project. Seems like how to release binaries is more the purview of the UEFI USRT, so I agree a meeting is a good idea. Thanks, Andrew Fish > Jian > >> -----Original Message----- >> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> >> [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behalf Of >> Laszlo Ersek >> Sent: Tuesday, April 16, 2019 1:04 AM >> To: Wang, Jian J <jian.j.w...@intel.com <mailto:jian.j.w...@intel.com>>; >> devel@edk2.groups.io <mailto:devel@edk2.groups.io> >> Cc: Zimmer, Vincent <vincent.zim...@intel.com >> <mailto:vincent.zim...@intel.com>>; Cetola, Stephano >> <stephano.cet...@intel.com <mailto:stephano.cet...@intel.com>>; Gao, Liming >> <liming....@intel.com <mailto:liming....@intel.com>> >> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling >> process >> >> On 04/15/19 07:36, Wang, Jian J wrote: >>> Laszlo, >>> >>> >>>> -----Original Message----- >>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of >>>> Laszlo Ersek >>>> Sent: Friday, April 12, 2019 8:52 PM >>>> To: Wang, Jian J <jian.j.w...@intel.com> >>>> Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zim...@intel.com>; >>>> Cetola, Stephano <stephano.cet...@intel.com>; Gao, Liming >>>> <liming....@intel.com> >>>> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling >> process >>>> >>>> (Dropping b...@edk2.groups.io <b...@edk2.groups.io> from the address >>>> list, as that should be a list to receive automated Bugzilla email.) >>>> >>>> On 04/12/19 10:43, Wang, Jian J wrote: >>>>> Hi, >>>>> >>>>> Currently, we generally follow below process to handle security bugs. >>>>> But there're no document to describe the detailed working flow. There're >>>>> also discussions on lacking of important information, poor issue >>>>> description >>>>> and no timely notification on update, etc. >>>>> >>>>> "0 - New Security Bug" >>>>> -> "1 - Triage" >>>>> -> "2 - Mitigation" >>>>> -> "3 - Embargo" >>>>> -> "4 - Disclosure" >>>>> -> "5 - Exit"; >>>>> >>>>> I have a proposal at following page to elaborate the process and try to >> address >>>>> all problems reported so far. Following content is for discussion only. >>>>> Once >> the >>>>> process is finalized, it will be moved to official edk2 wiki page. >>>>> >>>>> https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security- >>>> issue-process >>>>> >>>>> Any opinions and suggestions are welcomed. >>>> >>>> Thanks for working on this! >>>> >>>> I've skimmed the diagrams. I have one suggestion and one request for >>>> clarification. >>>> >>>> >>>> - Suggestion: a CVE number should be requested (if appropriate) as soon >>>> as the CVSS score (i.e. the nature of the vulnerability) has been >>>> calculated, and it has been determined whether platforms in practice >>>> (both physical and virtual) are affected. >>>> >>>> This is important because vendors should have a common (cross-vendor) >>>> reference for tracking the issue even in their own internal systems, and >>>> this reference should be available to all vendors internally as soon as >>>> upstream determines the issue has security impact. >>>> >>>> Additionally, as soon as members begin collaborating on actual patches, >>>> the patches should carry the CVE number in the subject line(s). >>>> >>> >>> No strong opinion. If no objection, let's do as you suggested. >>> >>>> >>>> - Request for clarification: the Embargo diagram should clarify that >>>> vendors are *forbidden* from shipping fixes in their own products, >>>> regardless of format, until the embargo is lifted. The point of an >>>> embargo is to release/ship the fixes all at once, across all vendors. >>>> >>>> It's OK to wait for a while between "3.5 Announce Embargo End", and "4.3 >>>> Open BZ To Public" / "4.4 Open source the patch". That's the interval >>>> when vendors would release their fixes all together. >>>> >>>> It's *not* OK, for any vendor, to ship their own fixes before "3.5 >>>> Announce Embargo End". >>>> >>>> Yes, this means that some vendors will have to wait on other vendors, >>>> and some vendors will have to work more hastily than they are used to, >>>> for the sake of other vendors. This is what coordinated/responsible >>>> disclosure means, and it aims to benefit the cumulative user base. >>> >>> I think it's impractical to ask all vendors to release the fixes at the same >>> time. >> >> They don't need to agree on the latest date to release the fix. They >> need to agree on the earliest date of release though. That's the *point* >> of an embargo. >> >> Assume Red Hat is invited to discuss a security issue in one of the edk2 >> modules that affects OVMF. Red Hat participates in the analysis, patch >> review, maybe Red Hat even contributes one or two of the patches. (We >> could even report a security issue in the first place; there have been >> examples.) >> >> After a bit of work, everyone agrees that patches prepared by the >> infosec group are fine, and we set an embargo / earliest release date, >> before informing the grand public, and posting the upstream patches to >> edk2-devel. >> >> However, assume that every vendor is permitted to ship the fixes >> whenever they want, in their own products. Great, Red Hat ships the OVMF >> firmware as host-OS *software* packages, as binary and as *source* RPMs. >> So, if involved vendors themselves are not required to adhere to the >> embargo in their own products, then let's say Red Hat ships the patches >> in *source code* form, complete with issue description / commit >> messages, in just two weeks after the patches are considered >> functionally appropriate, by the infosec group. >> >> All the while physical platform vendors might need half a year or more. >> >> Would all vendors like that? I don't think so. >> >> And, if Red Hat is expected to wait for physical vendors, we certainly >> expect the same in return. >> >> This is not a theoretical question: until now, we've *significantly* >> delayed product features at least twice, waiting for physical firmware >> vendors, under security issues that we have reported. >> >>> The longer a security issue exists in a product, the more damage >>> may be caused potentially. >> >> No doubt. >> >> This is why setting embargo dates is a trade-off. Any given vendor wants >> to get the fix as quickly as possible to its own users, obviously. At >> the same time, they should not screw over the users of *other* vendors >> (e.g. users of their competitors) -- so that next time, they can >> reasonably expect the other vendors to wait for them, in exchange. >> >> All vendors need to take some extra risk in order to protect the users >> of the *other* vendors. How long exactly vendors are willing to wait for >> each other should be a case-by-case discussion, but the generic >> principle is that they do set a *common* earliest release date. >> >>> I don't think any vendor want to risk that. But >>> it's reasonable and feasible to ask vendors not to expose the issue details >>> in the embargo period. >> >> I disagree. >> >> What you describe implies shipping the fix in binary-only form, or with >> other means of obfuscation. >> >> This would hugely discriminate against open source vendors, as they ship >> all fixes (security or not) in both binary and source form. >> >>> So my understanding is that embargo is for preparing the security issue >>> information disclosure purpose, during which all vendors should integrate >>> the mitigation solution into their products. >> >> Integrate into their products: yes. Release to their users: no. >> >>> Actually, once someone else >>> find the same issue and open it to public in the period, we should end the >>> embargo immediately. This step is missing in the work flow chart. >> >> Agreed! >> >> Thanks, >> Laszlo >> >>> Vincent, please correct me if anything wrong here. >>> >>> Regards, >>> Jian >>>> >>>> Thanks >>>> Laszlo >>>> >>>> >>> >> >> >> > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39154): https://edk2.groups.io/g/devel/message/39154 Mute This Topic: https://groups.io/mt/31055577/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
