Brainstorming workaround for dealing with signing issue

[Noitidart]

I just thought of a work around.

It is given that, internet connection HAS to be there for this addon. As in when the user is about to click the "add to firefox" button, internet has to be connected for it to work. Combining this with the fact that:
"A beta version should be signed immediately" (source: Mozilla Discourse :: Self sign my extensions - Comment 3) - I thought of this idea.

We have a dummy account on AMO. We sign into this account from the addon. This account already has a dummy addon listing. We reuse this listing for every addon. So the addon we just downloaded, we upload to AMO as a beta. It is signed immediately. We then download and install that xpi.

What do you think?

[jerone]

Without knowing anything about AMO signing process, I see two issues with your suggestion:

1. Does that mean we get two versions of an addon installed (one original and one signed with dummy account)?
2. Some authors might not be so happy that this addon is releasing an existing (active) addon on another account.

[Noitidart]

Great points @jerone.

Re: 1. We cant install that first version because its not signed, it won't install. So nope, we'll only be installing one.

Re: 2. After we download and install the addon, we delete the addon from the listing. So it won't remain there and won't be public.

Also, we should first check if it can install without need of signing (dev/nightly/unbranded) and only resort to this method in the else case.

[jerone]

Re: 1. We cant install that first version because its not signed, it won't install. So nope, we'll only be installing one.

I meant when I previously installed for example GreaseMonkey and then, with this addon, try to install the latest source version. What will happen? Does the latest source version override the original one, or will it create two version of GreaseMonkey?

Re: 2. After we download and install the addon, we delete the addon from the listing. So it won't remain there and won't be public.

Installing with GitHubExtIns will still be possible with signed addons?

Also, we should first check if it can install without need of signing (dev/nightly/unbranded) and only resort to this method in the else case.

Does AMO provide stats about Firefox versions used when installing this addon (dev, beta, released)?

BTW: new layout changes to GitHub are coming: https://github.com/blog/2085-a-new-look-for-repositories.

[Noitidart]

I meant when I previously installed for example GreaseMonkey and then, with this addon, try to install the latest source version. What will happen? Does the latest source version override the original one, or will it create two version of GreaseMonkey?

Oh excellent point! I didn't realize that! We'll have to set auto-update to off when we install the addon.

Installing with GitHubExtIns will still be possible with signed addons?

With this method, we get it immediately signed on AMO, so I strongly suspect it would work.

Does AMO provide stats about Firefox versions used when installing this addon (dev, beta, released)?

AMO doesn't but you can get that info from the addon scope.

BTW: new layout changes to GitHub are coming: https://github.com/blog/2085-a-new-look-for-repositories.

Oh dang thanks for that. This addon is a god send especially for those trying to test their addons on Android. So we should update to use this.

I also want to update this to use AsyncZip.js https://github.com/Noitidart/AysncZip/wiki/AsyncZip

[Noitidart]

@jerone it seems unlisted addons are automatic at the end of this week - https://blog.mozilla.org/addons/2015/12/01/de-coupling-reviews-from-signing-unlisted-add-ons/ - maybe we can leverage this?

[jerone]

I'm wondering how fast the "completely automated signing process" will be; seconds, minutes, hours, ...

[Noitidart]

Good point lets try to test this weekend.

Another thing though that's good about unlisted addons is that it doesnt deliver auto updates. So we don't have to worry about turning updates off for that install.

[Noitidart]

Whoa apparently there is a self-sign API - http://olympia.readthedocs.org/en/latest/topics/api/auth.html?

http://olympia.readthedocs.org/en/latest/topics/api/signing.html

[diegocr]

Hi there,

This turned into an interesting discussion :) Thanks @Noitidart for the provided links.

Looks like unlisted addon status and the self-sign API could be the perfect "workaround" we should deal with. However, i was just wondering something... following that approach, under which AMO account will be placed the extensions installed by GitHubExtIns?

Taking the GreaseMonkey example, will it be created under the GreaseMonkey's author account (if AMO takes the Addon ID (em:id)), or otherwise it'll be under the account of the JWT issuer?

AMO doesn't allow having two addons with the same ID, therefore it'll be likely under the author's account, if this is even possible (security measures, one creating an unlisted addon for someone else's [listed] addon) it might creates some nightmare for him i guess...

In the other hand, we could change the Addon ID before sending it for signing, but i'm not sure if the AMO staff will like that... Also, how will they see hundred of people (the users of GitHubExtIns) repeatedly sending addons for signing, and how the system will deal with several different people potentially sending the same addons?

Just a few concerns, but in any case i'm in the position of waiting until the signing requirements hits the stable branch and then we'll see how to deal with it, since otherwise Mozilla might keep changing their mind and therefore we are just wasting time here speculating.

Cheers.

[Noitidart]

Thanks @diegocr :)

The idea of using the actual users account is an excellent one! I didn't think of that.

However it seems there may be an alternative, apparently ther are endpoints, we can hit for "self-signing" which is also immediate. This is a very interesting thing i did not know about. So waiting till this stuff settles is a safe idea. :)

[Noitidart]

Here is a helper shell script to put an addon through the signing api - https://github.com/piroor/makexpi/blob/master/sign_xpi.sh

[Noitidart]

Here is a helper shell script to put an addon through the signing api - https://github.com/piroor/makexpi/blob/master/sign_xpi.sh

but apparently the API actually creates a new "version" for
every signing, instead of just signing for unversioned files.

Im taking this from an ongoing discussion on how devs can test their addons.

By the way, jpm run feature is broken on sdk addons too, ridiculous

[Noitidart]

Ok this is our solution - https://blog.mozilla.org/addons/2015/12/23/loading-temporary-add-ons/comment-page-1/#comment-220750

Easy, no need for connection to the internet.

[Noitidart]

No docs yet but – AddonManager.installTemporaryAddon(aNsiFileToXpi)

DXR – https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/AddonManager.jsm#2314

[Noitidart]

Here's how to use the jpm sign amo api via addons on main thread - https://github.com/Noitidart/Chrome-Store-Foxified/blob/ee3ad5486fa1539b88670f30e66fe277ec6d8afd/bootstrap.js#L208-L215