search

Sotera / DatawakeDepot

Loopback web application for administration of Datawake networks
Apache License 2.0
9 stars 7 forks source link

Toolbar: New version of Firefox enforces signed addons #121

Open bmcdougald opened 8 years ago

bmcdougald commented 8 years ago

If you upgrade to the new version of Firefox (43.0.4), it will disable the Datawake plugin toolbar. We need to figure out how to "sign" our addon to avoid this.

The workaround is to override this security feature in Firefox via the following: -- In firefox browser type 'about:config' in the address bar and hit enter. -- Use the filter to find xpinstall.signatures.required -- Set this value from true to false.

bmcdougald commented 8 years ago

I looked into what it would take to sign our XPI. Some of what I found wasn't very encouraging. It certainly would involve some major changes on our end for how we generate the XPI files. There is the option to manually submit an addon to the automated validator (only available for unlisted addons ... good for us, listed ones have to go through manual review process). If it passes validation, the new version of the plugin is signed and hosted on the AMO (Addons Mozilla Org) page. There is a more automated way of handling the validation where we can use 'jpm sign' and their API to get the validation for signing during the process that builds the XPI. In that case the XPI (if passed) is hosted on the unlisted section of the AMO site and a user is redirected to the download link for the updated signed XPI. This would move away from our depot hub way of distributing XPIs. Another problem with the jpm sign ability is that it will only sign and redirect if the version number has changed from what it already has hosted. That is a problem when we currently generated uniquely configured XPIs based on server but that all share the same version number. We'd have to get clever and have our version be something like ".<version#>" or something to that effect that would make their validator/signor think what we were trying to get signed was indeed a new version.

Long story short, there doesn't seem to be a quick and easy solution to having our stuff "signed", the only quick solution seems to be the workaround described in my comments for the initial ticket. We should keep in mind though, that Mozilla claims this workaround setting is only available on the Developer Edition and Nightly versions of their browser, however I'm using the regular one off of their main download page and currently have the option to use the workaround. This doesn't mean that they may indeed remove it in the future.

Much of the info I found is best summarized here https://developer.mozilla.org/en-US/Add-ons/Distribution

bwhiteman commented 8 years ago

[https://wiki.mozilla.org/Add-ons/Extension_Signing](Mozilla anouncement) [https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/jpm#jpm_sign](JPM Sign).

It appears that the approval process is automated and quick. We should be able to get an API key and use jpm sign to create plugins for client deployments. While inconvenient, this shouldn't be a large hurdle.

bmcdougald commented 8 years ago

It's not that easy. I eluded to why in my previous comments. In order to kick off the auto-verification via the JPM API key, we have to be submitting a newer version number than the last time a key was requested. The reason this is a problem is we currently have ONE version number of the plugin but the plugin is created on every server we stand up a new stack on unique to that stack. When the XPI is created on that server when it goes to create the xpi, it will make a call to the API to get the signature key. It will fail to get a key if someone on a different server has already requested a key for that version number. Mike suggested a workaround would be to version the plugins based on the IP or something of the server followed by a dash or something then the plugin code version. That way each server would have "unique" version numbers. This would potentially solve the signing process issue.

However, even if we get that working we may run into issues. If our plugin xpi that's submitted via the API fails their validation (and we don't know what they are checking) for any reason, a key will not be issued and no one on that server can create a plugin at that point. If the automated validation fails, Mozilla does a manual validation of the code which takes a minimum of 3 days.

It also appears that we would have to change how the Depot works if we use Mozilla's addon store (even if we choose to have it "unlisted") to sign our extension, because THEY host the file and users are redirected to their link when they click to install the plugin. This could get hairy given every server will have a unique XPI and our current depot build processes for the XPI host locally and users install from there...not Mozilla's store.

This is not something simple to knock out. We have some concerns that need to be really thought about when we try and fix this. People have asked Mozilla about privately hosted XPIs for enterprise users, Mozilla's comment was they currently have no other solution at this time other than the processes already in place.