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

[Daniel Bates]

Hi all,

I am working to support EWS processing of patches on security bugs (see <
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:


   1. Have 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.
   2. The tool webkit-patch will now upload a copy of each patch attached
   to a security bug to webkit-queues.webkit.org as part of submitting a
   patch to EWS.
   3. 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).
   4. The EWS feeder queue will now upload a copy of each patch attached to
   a security bug to 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 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 to access Bugzilla 2)
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.

I am open to suggestions.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180615/0cfcba33/attachment.html>