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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev