Closed Bug 1060624 Opened 10 years ago Closed 10 years ago

QA open squid proxy in SCL3

Categories

(mozilla.org :: Project Review, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: whimboo, Assigned: michalpurzynski1)

Details

(Whiteboard: [qa-automation-blocked])

Initial Questions:

Project/Feature Name: QA open squid proxy in SCL3
Tracking  ID:917204
Description:
The Firefox Desktop Automation team is running Mozmill tests (https://developer.mozilla.org/en/Mozmill_Tests), which mainly cover testcases - also very exotic ones - which can NOT be done by any in-tree test framework (like mochitest, browser chrome, xpcshell). That also includes a full access to the network, which is totally prohibited for the in-tree tests.

One of those initiatives is to create automated tests for testing proxy related regressions in Firefox. There are no such tests available yet, and the chances to regress some other code of this component again are high.

Given that our Mozmill tests are not only executed from our test machines in SCL3, but also from various people outside of the Mozilla network, all of them would need access to this open squid proxy to be able to run the Mozmill tests.

The one and only end-point (host) to reach when using this open proxy should be mozqa.com (mozqa1.qa.scl3.mozilla.com and NO other host. Whereby all subdomains should be reachable, and protocols like HTTP, HTTPS, and FTP supported.

As an example you can take bug 917205. Here Firefox crashes when a proxy is selected and an FTP site gets opened after Firefox is restarted. To archive such a test, the Mozmill test itself will automatically set the open squid proxy as the active one, performs a restart of Firefox, and loads an FTP page. Afterward the proxy gets reset.
Additional Information:
There is no project / feature page available yet.

There is not release date but having this sooner than later would be appreciated. For now I set end of the current quarter, which is an additional month to the date already given on bug 917204.

It could be that I missed something, but as Richard said on bug 917204 we can iterate.
Key Initiative: Firefox Desktop
Release Date: 2014-09-30
Project Status: active
Mozilla Data: No
Mozilla Related: Firefox Desktop, Mozmill testing
Separate Party: No
Henrik - I believe you're looking for a security review, but since you answered "No" to the data related questions,  no security bug was opened. I've cced Curtis Koenig who should be able to help.
Flags: needinfo?(curtisk)
Not sure if that is necessary. We already got such a review for mozqa1.qa.scl3.mozilla.com, which is the one and only reachable host. Be aware that this machine is already publicly available via mozqa.com. The squid proxy is just a pass-through connection. That's all.
Passing this on to the security operations team to review
Flags: needinfo?(curtisk) → needinfo?(jstevensen)
How do we attach a security bug for the review here? Do I need to create a secreview bug and just add it as a dependency or something else?
Flags: needinfo?(jstevensen) → needinfo?(curtisk)
(In reply to Michal Purzynski [:michal`] (use NEEDINFO) from comment #4)
> How do we attach a security bug for the review here? Do I need to create a
> secreview bug and just add it as a dependency or something else?

That works, and is quite often how it's done. Or you can just add comments to this bug. If the contents need to be hidden for some reason then a separate bug is the preferred route.
Flags: needinfo?(curtisk)
Michal, is there anything which is blocking us to continue on this bug?
Flags: needinfo?(michal.novotny)
Flags: needinfo?(michal.novotny) → needinfo?(mpurzynski)
Can we please get any feedback on this project? Putting this bug on our blocker list.
Whiteboard: [qa-automation-blocked]
If I understand it correctly, the whole testing framework can be accessed already without the new proxy, i.e. we are not opening additional access that it's not opened now?

If so, I will just close this bug as fixed and you will request whatever you need from IT and link to this bug so the secreview status is 'OK'.
Flags: needinfo?(mpurzynski)
Correct. All the content we want to have access here is already accessible via the public mozqa.com website. The only thing which has to be setup correctly is the IP routing so we ensure that the proxy really only serves data from mozqa.com and nothing else.
Well that would rather be some kind of Squid ACLs I think.

Anyway, closing this but with a comment.

Good to go, just make sure the Squid instance will only serve the same data that mozqa.com does and does NOT become any kind of open proxy.

Your next step should be opening an IT bug asking for a VM with Squid and correct ACLs, network flows and linking this bug. Let's keep the VM in same Vlan that the mozqa is.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: sec-review+
Resolution: --- → FIXED
Assignee: nobody → mpurzynski
Thanks Michal!
Blocks: 1088570
No longer blocks: 1088570
You need to log in before you can comment on or make changes to this bug.