Waiting for validation for 2 months ! What should I do to make it happen?

Add-ons Add-on Support
#1

I published an extension that summer : https://addons.mozilla.org/en-US/firefox/addon/uniquepasswordbuilder-addon/
It’s a password manager I use and depend to login to website and I think it could be useful to others.

I asked for validation the 2th of august.
I’m waiting since then… (also, some weeks ago, I switched from full validation to preliminary review, hopping it would be quicker).
Right now, I’m 51 of 154 in queue position and, for two months, I never went below 30…
It seems that some extensions are bypassing mine…

Since I’m using Firefox Developer Edition which has been updated to version 43 this morning, I’m not able to use my extension anymore… So I’m not really happy right now.

If Mozilla requires validated extension, the last they can do is doing their job as validating extension in a reasonable time.
What should I do to make my extension be validated ?

#2

It is on Admin Review queue which takes longer since there are fewer Admin reviewers than normal viewers.

Sine it has minified code and sources are added, it goes to the admin queue.
If ‘upb-main.min.js’ is an established library, you could have added its official source to “Notes for Reviewers”. If it is not an official library, then it takes longer as the process gets more complicated.

The clear source for the minified code has to be checked line by line (and for a large one, that takes some time). If there are no problem with the code, then it has to be minified and compared with the included minified version. That also takes time. If it doesnt match, it will be rejected.

#3

Thanks for the reply.

upb-main.min.js is not an established library. It’s a concatenation of js-scrypt library ( https://github.com/tonyg/js-scrypt ) which I need and my own source code (on github, by the way : https://github.com/paulgreg/UniquePasswordBuilder ).

#4

I would suggest not minifying, and if possible not cating those two together, but using them separately.

#5

Well I also waiting since July for my admin review and have no minified code in my source… It might be nice to keep the position in the queue when updating the addon. The compatibility issue I fixed was originally in May, and it is nerving when actually the addon is not working for any one.

On the other side to say it more clearly - the mood for fixing issues fast and to invest time to developing is quite decreasing. This is in my hubble opinion a bit pity for a browser which lives from its community and widespreaded addons :smile:

Breaking discussion
#6

Ok… It’s just weird to not do that since it’s basic JS optimization (also, I’m sharing code between website and extension which explains that process).

#7

@gpaul Minifying optimizes in the sense that it takes less time to load it from a server. With an addon it’s already loaded, and would add only milliseconds to browser load time. Same thing with cating them. If you have no minified code and all libraries in their own unmodified (meaning they have to be a bit for bit match, so EOL needs to stay the same) .js file, you’ll be able to be unflagged from the admin queue and return to the normal queue most likely. As @erosman says, non-admin reviewers get to things a lot quicker.

Just minify and cat for your website, don’t for the addon. It’ll hopefully make your life easier.

1 Like
#8

I agree reducing JS size for an extension is not relevant since it’s loaded locally.
However, minifying JS size also impacts parsing and compiler performance, specially like in my case, for a low-level cryptographic library (js-scrypt). It may not be a huge gap but still, it’s a best practice…

#9

Just uploaded a new version (0.1.2) with sources files not concatened and not minified.
However, the js-scrypt library I’m using has been generated with Emscripten and is a mess to read : https://github.com/tonyg/js-scrypt/blob/master/browser/scrypt.js (Emscripten goal is not to be readable by human but to port C library to JS)…

#10

@erosman Sounds like it may not need an admin anymore, opinion?

#11

@arenlor … Actually, besides the fact that it is on Admin queue, it is still minified.

The latest Version 0.1.2 · September 28, 2015 scrypt.js has its whitespaces but …
1- It is still minified:

function cX(a, b, c, d) {
 a = a | 0;
 b = b | 0;
 c = c | 0;
 d = d | 0;
 var e = 0, f = 0;
 e = a;
 a = c;
 c = cU(e, a) | 0;
 f = H;
 return (H = (ad(b, a) | 0) + (ad(d, e) | 0) + f | f & 0, c | 0 | 0) | 0;
}

2- It is 10,282 lines of code like above. That is something for a reviewer with advanced skills (and a lot of free time & patience).

#12

It’s not “minified” but as I said previously, scrypt is a library in C, ported to JavaScript via Emscripten which is kind of cross-compilation.
It’s “compiled” into LLVM then to JavaScript.

If you want to examine the code, you need to look at the C scrypt original library, written by Colin Percival (a well known cryptographic expert) then compiled it via Emscripten and check if both outputs are the same… It looks like that will take forever.

I would love to do that using Web Cryptographic API and not depend on that cross-compiled library but scrypt isn’t part of it right now… It doesn’t seem I have a lot of options.

#13

scrypt is really a tough one to review. I’m not sure whether changing the algorithm is an option for you but deriving keys from a passphrase is actually possible relatively easily with WebCrypto. See http://blog.engelke.com/2015/02/14/deriving-keys-from-passwords-with-webcrypto/ for instructions and a live demo. This functionality is available in Firefox 34 and above according to MDN.

#14

The problem is I’ll brake compatibility with passwords already generated. That means that users using the bookmarklet (because it has been a bookmarklet before the extension) have to change their passwords for each site they used it… So that’s not really an option.

Also, I find really weird to completely change my code and break retro-compatibility just for review purpose…

#15

Yes, that’s why I asked whether it would be an option. Unfortunately, I don’t see any real migration path - other than keeping the legacy bookmarklet around and building up a new user base with the extension.

No, not just that - it would also make maintaining your extension much simpler (also attracting contributors for it if you care about that).

#16

js-scrypt is a library like jquery or backbone. It exposes a method to compute a hash and that’s it.
Contributors (myself included) don’t need to understand it, like you do not need to understand how jQuery internally works in order to use it.

Also, I chose scrypt because it’s a memory hard problem, which is more resistant to ASIC miner than some other hashing algorithm.

#17

Sure, it’s a library - but whoever is going to review it (not me) will have to verify that the version you are using matches the C sources and then review the latter. For example, there are eval() calls in the generated code and it has to be verified that these are safe. As mentioned above, there are more resources available for admin reviews now so I guess your chances aren’t too bad now.

#18

Thanks for the hope :smile:

And indeed, there are some ‘eval’ function which I don’t like. Maybe I should try to build the lib myself via a recent version of emscripten to see if they can be removed.

#19

I just find out about another scrypt library in JS which isn’t compiled via emscripten : https://github.com/dchest/scrypt-async-js
I’ll try to use that one which is plain JS and so, easier to review.

#20

If that Library is dchest/scrypt-async-js, then it will help you GREATLY.
It is only 478 lines comparing to 10,282 lines of the other one and a lot easier to review.

You can also use the minified version scrypt-async.min.js and include a link to the source in the "Notes for Reviewers"
N.B. It must be identical to source (same checksums) to be acceptable.