Discussion about Firefox add-on signing

[Caistarrin TM]

Hello,

I’m sure many of you are aware of Mozilla’s new requirement that Firefox add-ons be submitted to AMO for signing. We’ve submitted PME for review, and while we’re still in the queue, the initial screening returned a lot of warning messages. Most of these messages referenced code forked from Zotero. We don’t know yet if any of this will be called out by the reviewer, but anything that holds back PME is bound to be problematic for Zotero as well.

It would likely benefit us both to collaborate on efforts to fix issues that the AMO review brings up. We were also hoping to get your thoughts on how Zotero plans to tackle the new signing requirements, and we may be able to offer some assistance in getting through the signing process.

Best regards,

- Caistarrin

ProQuest PME team dev
Github: sircmyst

[Dan Stillman]

The Mozilla folks have said repeatedly that the screening process for
signing won't use the same checks as the the current AMO checks, so
we're not worrying about this until they've made the actual tests they
plan to use available. I and many others made our concerns about the
proposal — including the concern that unreliable AMO-style tests would
be included in the screening process — quite clear on the mailing list,
so at this point we're just waiting for further details from Mozilla.

But if you take them at their word, the signing requirement is to combat
malware. Zotero isn't malware, and therefore it shouldn't be rejected by
the new system.

[Frank Bennett]

I've just woken up to this, but after reading through the discussions at Mozilla, I see that, as Dan says, the review process for externally hosted extensions will be more lenient.

For MLZ specifically, this will likely force a beneficial change, though.

MLZ currently modifies the user's Zotero database directly, and this is (understandably) the single largest sticking point for users who have some need for its extended functionality. It does this only because, from the start of the project, MLZ has used the same internal ID as Zotero proper. It is almost a certainty that this will fail code review of any sort, and there isn't really an argument for why it must be so.

I'm currently working on a rebranding of the MLZ tools under a new name ("Juris-M" - the site that will house the newly rechristened tools is here: https://juris-m.github.io). The rebranding release will be an opportunity to give the desktop client its own ID, and to make the install process draw a copy of the user's database before applying schema changes. Since MLZ/Juris-M is sync-compatible with zotero.org, syncing to the same account will set the same content in both the Juris-M and the original Zotero database. The result will be that:

* The user's original Zotero database will be unaffected.
* The user can run Juris-M, Zotero for Firefox, and Standalone on the same system.
* No steps will be required to "revert" to a Zotero-based configuration (users would simply remove the Juris-M extension and carry on).

Because the ID will change, I reckon that it won't be possible to migrate users automatically to the Juris-M install; but with the renaming, the need to install manually can be explained clearly and simply.

That's the off-the-cuff plan. The rebranding should take place sometime between now and the Summer break.

Frank

[Ephrim Khong]

Let me use this opportunity to say that the signing requirement might
put some burden onto those of us who use a private server. The client
has SYNC_URL and API_URL hard-coded, and patching it will probably
invalidate the signature.

While Mozilla has promised some way of allowing private/company-wide
add-ons, the FAQ [1] is not very promising, probably postponing this to
somewhen 2016 by pointing to the ESR version. Also the fact that add-on
developers will have to use a specially compiled version of firefox does
not increase likelyhood that a deployment mechanism will be ready in
time, otherwise that mechanism could be used to test add-ons.

I see two alternatives - (1) re-pack the patched client and let mozilla
sign it. I hope the signature process will be private, otherwise there
might be copyright issues regarding the Zotero TM. Hopefully, their
automatic filters will let is pass, since it's mostly identical to the
original zotero client. Or (2), have some way of setting SYNC_URL and
API_URL (about:config?) in the original zotero add-on...

- Eph

[1] https://wiki.mozilla.org/Addons/Extension_Signing

> --
> You received this message because you are subscribed to the Google
> Groups "zotero-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to zotero-dev+...@googlegroups.com
> <mailto:zotero-dev+...@googlegroups.com>.
> To post to this group, send email to zoter...@googlegroups.com
> <mailto:zoter...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/zotero-dev.
> For more options, visit https://groups.google.com/d/optout.

[Emiliano Heyns]

I'm actually fighting my way through this "lenient" process, and it's a total, utter mess. My extension (BBT) trivially triggers the non-automated review, a process which Moz is not even close to having figured out yet. I have yet to have review feedback for a single submission, and there's zero feedback on when you're up for review other than your position in the queue. I'm trying to rewrite the parts that trigger automated review, which unfortunately includes:

* replacing my use of xregexp

* replacing my use of jsencrypt

* replacing my use of Function

* replacing my use of __exposedProps__, and I currently have no idea whether I can work around that at all

* the list goes on

On a lark, I've uploaded Zotero 4.0.26.4, and it doesn't even trigger the manual review process, it just flat-out fails to qualify, because "Error: The validation process took too long to complete. Contact an addons.mozilla.org editor for more information. Validation timeout after 180 seconds". It did find the time to find several "Signing severity: high" problems. I wouldn't be too complacent about passing this validation process.

[Dan Stillman]

I think you're jumping the gun the here, and I certainly wouldn't waste
time reworking your code yet. They haven't announced the availability of
the unlisted-extension process — in fact, they specifically said it's
not ready yet — and I wouldn't assume that all the warnings that are
showing up — which are just that, warnings — will prevent automatic signing.

I'm aware of the timeout and the warnings, and we'll address those
things with Mozilla if they're still issues when this is actually announced.

[Emiliano Heyns]

On Wednesday, April 15, 2015 at 1:01:43 PM UTC+2, Eph Khong wrote:

Let me use this opportunity to say that the signing requirement might
put some burden onto those of us who use a private server. The client
has SYNC_URL and API_URL hard-coded, and patching it will probably
invalidate the signature.

Not probably. Certainly.

 

While Mozilla has promised some way of allowing private/company-wide
add-ons, the FAQ [1] is not very promising, probably postponing this to
somewhen 2016 by pointing to the ESR version. Also the fact that add-on
developers will have to use a specially compiled version of firefox does
not increase likelyhood that a deployment mechanism will be ready in
time, otherwise that mechanism could be used to test add-ons.

I'll probably start recommending people run standalone, or use a dev build for day to day use. I've been trying to talk some sense into the Moz people around their chosen process, and nothing I've seen so far has been encouraging.

 

[Emiliano Heyns]

On Tuesday, June 9, 2015 at 12:21:47 AM UTC+2, Dan Stillman wrote:

I think you're jumping the gun the here, and I certainly wouldn't waste
time reworking your code yet. They haven't announced the availability of
the unlisted-extension process — in fact, they specifically said it's
not ready yet

You can upload extension for unlisted review right now. I agree it's not ready yet, from my point of view.

 

 and I wouldn't assume that all the warnings that are
showing up — which are just that, warnings — will prevent automatic signing.

I've been led to believe they will. They're warnings in the sense that they won't prevent signing full-stop. The severe warnings mean you get shunted to the manual review process. Good luck getting 275kloc of code reviewed. I have just 4kloc, and I have not yet had a single review ever. Not "failing reviews". Just no reviews.

[Dan Stillman]

On 6/8/15 6:31 PM, Emiliano Heyns wrote:
> On Tuesday, June 9, 2015 at 12:21:47 AM UTC+2, Dan Stillman wrote:
>
>
> I think you're jumping the gun the here, and I certainly wouldn't
> waste
> time reworking your code yet. They haven't announced the
> availability of
> the unlisted-extension process — in fact, they specifically said it's
> not ready yet
>
>
> You can upload extension for unlisted review right now.

And they responded to you and said that was just for testing and
shouldn't be seen as representative of the final process.

> I agree it's not ready yet, from my point of view.
>
> and I wouldn't assume that all the warnings that are
> showing up — which are just that, warnings — will prevent
> automatic signing.
>
>
> I've been led to believe they will.

They haven't said that anywhere I've seen (though I'll admit that
"Signing severity: high" isn't promising). Maybe those warnings will be
prevent auto-signing, in which case we'll deal with it then. And, to
clarify, having the warnings you've complained about prevent automatic
signing would be unacceptable in my view. But I don't see much point in
panicking about this until the functionality is actually announced.