Closed Bug 1255809 Opened 4 years ago Closed 4 years ago

Sign test extensions in devtools/client/webide/test/addons

Categories

(DevTools :: WebIDE, defect, P1)

defect

Tracking

(firefox46 fixed, firefox47 fixed, firefox48 fixed)

RESOLVED FIXED
Firefox 48
Tracking Status
firefox46 --- fixed
firefox47 --- fixed
firefox48 --- fixed

People

(Reporter: ahal, Assigned: ahal)

References

Details

(Whiteboard: [btpp-fix-now])

https://dxr.mozilla.org/mozilla-central/search?q=path:devtools%2Fclient%2Fwebide%2Ftest%2Faddons

It looks like at least the fxos_1_0_simulator-*.xpi addons will need to be signed, possibly more. Jryans says he thinks many of the tests that use these may be disabled.

Here's the log with the failure to install:
http://archive.mozilla.org/pub/firefox/try-builds/ahalberstadt@mozilla.com-a2ef842752b0f6afb41bfc550b12d3ba8c3e6024/try-linux-debug/try_ubuntu32_vm-debug_test-mochitest-chrome-1-bm04-tests1-linux32-build327.txt.gz

(Ctrl-F for "signature is required but missing")

There is documentation on signing addons here:
https://wiki.mozilla.org/EngineeringProductivity/HowTo/SignExtensions

I'm volunteering to do the signing, but the addons are already owned by a different AMO account. Here are all our options:

1. Add 'release+signaddons@mozilla.com' as a co-owner of these addons on AMO
2. Give me the signing keys of the existing owner
3. Sign them yourselves using the existing owner
4. Allow me to change the addon ids so AMO will think they are new addons
5. Disable the test(s) that use them
6. Install these as temporary addons so they don't need to be signed (I'd prefer to avoid this option for now as it likely means missing the 46 train for enforcing addons.. this can always be revisit later)
Blocks: 1233200
:ahal, how do I reproduce the failure locally?  Do I need special prefs?  Do I need a debug build?
Flags: needinfo?(ahalberstadt)
You should be able to set this pref to true:
https://dxr.mozilla.org/mozilla-central/source/testing/profiles/prefs_general.js#73

Alternatively, run on a build with this patch applied:
https://hg.mozilla.org/try/rev/bcf5f271f529
Flags: needinfo?(ahalberstadt)
I confirmed there's only a single test failure:
https://dxr.mozilla.org/mozilla-central/source/devtools/client/webide/test/test_simulators.html

Disabling that test turns the run green again. So I presume we just need to sign the simulator addons.
:ahal, what's the timeline for this?  Is the goal to make some change that can be uplifted up to 46?

Marking as fix now for the moment, since I am guessing quick action is needed.
Assignee: nobody → jryans
Flags: needinfo?(ahalberstadt)
Priority: -- → P1
Whiteboard: [btpp-fix-now]
Yeah that's the idea, this is on a pretty tight timeline. They want at least a month of baking time, so the cutoff is sometime this week.

Because addon signing is only being enforced on beta, another option is to temporarily skip test_simulators.html on beta while this is worked on and re-enable when the signed extensions are uplifted.
Flags: needinfo?(ahalberstadt)
I just gave release+signaddons@mozilla.com owner access on firefox-os-1-0-simulator, if that's ok jryans.
(In reply to Andy McKay [:andym] from comment #6)
> I just gave release+signaddons@mozilla.com owner access on
> firefox-os-1-0-simulator, if that's ok jryans.

Is that the add-on that I created just last week when trying to understand this problem?  It looks like it is, since I see you've added this additional owner.  It doesn't seem like that was the original issue :ahal hit then, since I was able to create it myself after this bug was created.

:ahal, did you in fact attempt signing with fxos_1_0_simulator-*.xpi, or was it a different one in the directory?

I am anticipating conflicts with other (not 1.0) test simulators that were signed by some magic script from the Cloud Services team (:jason was involved).  If that's the case, they are not simulator IDs that anyone on DevTools has access to modify, so an alternate approach may be needed.

I am at a work week this week, so I'm a bit low on time for this issue.  It might be best to start by disabling the test in beta first to remove some of the time pressure here.
Flags: needinfo?(ahalberstadt)
It looks like test_simulators.html uses all of these addons:
https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools%2Fclient%2Fwebide%2Ftest%2Faddons%2F*simulator*.xpi&redirect=false&case=false

Though I found something interesting. When I try to sign e.g fxdt-adapters-linux32.xpi, I get this error:
> JPM [info] Signing XPI: fxdt-adapters-linux32.xpi
> JPM [error] Server response: You do not own this addon. ( status: 403 )
> JPM [info] FAIL

But when I try to sign, e.g 'fxos_1_0_simulator-linux.xpi', I get this error instead:
> JPM [info] Signing XPI: fxos_1_0_simulator-linux.xpi
> JPM [error] Server response: Version already exists. ( status: 409 )
> JPM [info] FAIL

And signing fxos_2_0_simulator-linux64.xpi worked! So maybe it was just the "fxdt-adapters" and "adbhelper" addons that I couldn't sign. I'll see how far I can get and post back.
Flags: needinfo?(ahalberstadt)
(In reply to Andrew Halberstadt [:ahal] from comment #8)
> It looks like test_simulators.html uses all of these addons:
> https://dxr.mozilla.org/mozilla-central/
> search?q=path%3Adevtools%2Fclient%2Fwebide%2Ftest%2Faddons%2F*simulator*.
> xpi&redirect=false&case=false
> 
> Though I found something interesting. When I try to sign e.g
> fxdt-adapters-linux32.xpi, I get this error:
> > JPM [info] Signing XPI: fxdt-adapters-linux32.xpi
> > JPM [error] Server response: You do not own this addon. ( status: 403 )
> > JPM [info] FAIL

Ah, okay, I did not realize from the bug that fxdt-adapters and adbhelper were also involved.  Those are owned add-ons.  Signed versions already exist:

https://archive.mozilla.org/pub/labs/valence/
https://archive.mozilla.org/pub/labs/fxos-simulator/adb-helper/

So, we may just need to update the in-tree test copy with a newer one that is signed.

> But when I try to sign, e.g 'fxos_1_0_simulator-linux.xpi', I get this error
> instead:
> > JPM [info] Signing XPI: fxos_1_0_simulator-linux.xpi
> > JPM [error] Server response: Version already exists. ( status: 409 )
> > JPM [info] FAIL
> 
> And signing fxos_2_0_simulator-linux64.xpi worked! So maybe it was just the
> "fxdt-adapters" and "adbhelper" addons that I couldn't sign. I'll see how
> far I can get and post back.

For these, hopefully you are able to sign them.  It could get confusing if you alone are the owner, in the case that we need to make functional changes in the future...  Maybe I can be added as owner for new ones created by you?
Sorry for the confusion.. I don't believe fxdt-adapters are involved. Initially I thought they were, but then you pointed out that you thought those tests were disabled already. I was saying that I must of neglected to try the simulator ones after already getting permission.

I was able to sign all the simulator extensions (after doing version bumps in the install.rdfs). There's nothing really to review, as it's all binary changes.. so :jryans, maybe your permission to land pending a successful try run can count as an r+ ?
Flags: needinfo?(jryans)
Ugh, I'm not Englishing good today, let me try again.

I got the simulator addons signed. I'll push to try to verify it fixes the problem. Since there's no diff to review (binary changes only), I'll take a written permission to land en lieu of review if that works for you.
(In reply to Andrew Halberstadt [:ahal] from comment #11)
> Ugh, I'm not Englishing good today, let me try again.
> 
> I got the simulator addons signed. I'll push to try to verify it fixes the
> problem. Since there's no diff to review (binary changes only), I'll take a
> written permission to land en lieu of review if that works for you.

Okay, that works for me. r+ assuming those are the only changes needed.
Flags: needinfo?(jryans)
Assignee: jryans → ahalberstadt
https://hg.mozilla.org/mozilla-central/rev/36ad1b3de910
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.