Pale Moon forum

Now that Mozilla has shut down signing for plugins packaged in XPI (extension) files (that contain just the plugin and install.rdf) , is there a recommended way to sign such XPI files for use with Pale Moon (or other browsers with ongoing support for real plugins)?

We could of cause install with an unsigned XPI and let the user ignore the "author not verified", but maybe there is some variation of XPI signing which actually works with Pale Moon. Note that we already have real code signing certificates and sign the plugin DLL file, so a way to sign the XPI with a CA-issued cert would be the easiest solution.

If I'm not mistaken, there were a couple of articles about self-signing add-ons, but I can't find them right now.
Anyway, personally I think that signing the single files is a perfectly valid alternative, and ideally a user that gets the add-on from Pale Moon's official repository would trust it since it has been approved by the people in charge.
Yeah, there's a lot of implied trust, but it's not too different than CAs.

Add-on signing is broken in Tycho and UXP: viewtopic.php?p=131558#p131558.

The plugin will be distributed directly from the site(s) that need it, as it is rather purpose specific (it is not a generic thing like Java or Flash). So little point in putting it on the add-ons site.

I saw that old discussion from February but couldn't tell if it was outdated and things had changed in the past 7 months.

Currently it seem that both Pale Moon and Basilisk will simply ignore the signature.

Pale Moon should respect signatures if existent and reject if not valid assuming that was true in Tycho since the entirety of the Tycho Add-ons Manager was ported to UXP.. Basilisk however may just ignore them because it uses the WebExtensions enabled Add-ons Manager that came with the codebase when it was forked away from ESR52.

Easy enough test is to grab a signed extension from AMO and then modify some files in it and seeing if it installs or is rejected. However, as stated it may be busted. Not like it matters, neither application requires signed extensions nor will they.

One point of signatures is to convince the user the plugin is from a known source (company name and address) and mostly harmless (which it is).

Another point is to simply detect corrupted downloads (signature hashes don't match file contents, as an additional check beyond the ZIP CRCs).

Those are separate goals from walled garden blocking of unsigned plugins.

This is what happened when I tried to install a modified Mozilla-signed overlay extension in Basilisk UXP, Firefox 52, and Pale Moon 26/27/28:
Pale Moon 26:Pale Moon 27:Pale Moon 28:Basilisk UXP: Nothing about add-on signing will show up in Error Console
Firefox 52:and Looks like it is busted in Pale Moon...

jb_wisemo wrote:One point of signatures is to convince the user the plugin is from a known source (company name and address) and mostly harmless (which it is).

99.9% of extensions are not distributed by companies, and when they are, they tend to be distributed in their own installer along with the companion product they are for.

To get organization signing in a signed XPI (which uses JAR-style signing), you would also need an (expensive) EV code signing certificate.

Another point is to simply detect corrupted downloads (signature hashes don't match file contents, as an additional check beyond the ZIP CRCs).

ZIP archive checksums are enough. If any corruption occurs there it will fail extraction and the extension won't be installed. The only added "integrity" check with JAR-style signing beyond that is if an extension has deliberately been tampered with.

Those are separate goals from walled garden blocking of unsigned plugins.

Not really. The 1st one simply doesn't apply, also because signing has been broken by Mozilla (see below). And the 2nd one is very much in the realm of protecting extensions from "unauthorized modifications" (so only if redistribution happens with a signature attached but the files were altered...). Since author-signing isn't enforced, this is moot because the signature meta data can simply be removed and it will install as unsigned.

yami_ wrote:Looks like it is busted in Pale Moon...

It is, and it has been. It is also busted in Firefox. Why? Because Mozilla busted it on purpose! I've had a rather extensive discussion with mozilla about this and they basically redefined what "extension signing" meant in terms of treating the manifest differently and tying it to a Mozilla CA cert instead of independent certification per-extension. All this to enforce their "the publisher signs the extension, not the author" angle.

We need to simply remove JAR signature checking altogether because it has been broken for years. After that, if needed, we can look into creating a different way of doing authentication of extensions.

Note that while enforcing signing by some official entity is very much the walled garden, telling the user about broken signatures is all about protecting the user.

The key difference is who makes the decision to accept a plugin or not: A dictator (like Mozilla) or the user.

A user is also free to accept something weaker than EV, such as the traditional cheap code signing certificates from StartCom (RIP) or even self-signed extensions.