[webkit-dev] Design for review: EWS for security bugs

[Alexey Proskuryakov]

> 16 июня 2018 г., в 0:12, Daniel Bates <dbates at webkit.org> написал(а):
> 
> Hi all,
> 
> I am working to support EWS processing of patches on security bugs (see <https://bugs.webkit.org/show_bug.cgi?id=186291 <https://bugs.webkit.org/show_bug.cgi?id=186291>>) and I am writing to this list to solicit feedback on any show-stopper bugs in the proposed design. Historically we have not supported this functionality because the EWS was designed to use Bugzilla as its data store and hence the EWS machines (considered untrusted) would need a Bugzilla account with access to all security bugs. Here is my idea to solve this problem without privileging these machines with full security bug access:
> 
> Have webkit-queues.webkit.org <http://webkit-queues.webkit.org/> host copies of security sensitive patches. These patches will be deleted once all EWS queues have processed them. Access to these patches will be guarded by an API key(s) to prevent anonymous access. Each EWS machine will need one. Otherwise, it will skip such patches.
> The tool webkit-patch will now upload a copy of each patch attached to a security bug to webkit-queues.webkit.org <http://webkit-queues.webkit.org/> as part of submitting a patch to EWS.
> Add a Bugzilla extension to CC the EWS feeder queue on a bug if it has a patch up for review, including security bugs. (The EWS feeder queue is responsible for polling Bugzilla to find unreviewed patches and submitting them to webkit-queues.webkit.org <http://webkit-queues.webkit.org/>).
> The EWS feeder queue will now upload a copy of each patch attached to a security bug to webkit-queues.webkit.org <http://webkit-queues.webkit.org/> as part of submitting a patch to EWS.
> 
> Then EWS machines will be able to process security sensitive patches, report compile-time errors and the list of failing tests. There are three known issues with this approach: 1) EWS bots cannot comment on security bugs 2) EWS bots cannot upload layout test failure tarballs to security bugs and 3) the "Submit for EWS analysis" button will not work. I plan to solve these issues in subsequent bugs. One way to solve the first two issues is to have webkit-queues.webkit.org <http://webkit-queues.webkit.org/> store comments and tarballs and teach the EWS feeder queue (or another bot) to submit these comments and upload these tarballs to Bugzilla on behalf of the EWS bots (since the EWS feeder queue has access to the security bug by design decision (3)). To solve the last issue without requiring a person to re-enter their Bugzilla credentials there are at least three approaches: 1) set an appropriate CORS policy for webkit-queues.webkit.org <http://webkit-queues.webkit.org/> to access Bugzilla 2) webkit-queues.webkit.org <http://webkit-queues.webkit.org/> asks Bugzilla to POST a form back to it or 3) re-implement and host the "Submit for EWS analysis" button on Bugzilla so that it can upload the security sensitive patch to EWS when clicked then redirect to the status-bubbles page on webkit-queues.webkit.org <http://webkit-queues.webkit.org/>.

I just have a comment about the known issues. Not sure if it makes sense to invest effort into addressing these within current design, as we want to stop using custom EWS code and move as much as possible to Buildbot.

The stack that EWS is currently built on is very different from anything else we use, so it's difficult to maintain.

- Alexey

> I am open to suggestions.
> 
> Dan
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180620/c649d684/attachment.html>