Get builds reproducible enough for Firefox to resume accepting

[danfinlay]

Mozilla has increased the strictness of their addon acceptance, and now requires that the source code we provide reliably produce exact matches of our submitted built addon.

Our build is not perfectly deterministic, it varies slightly on different platforms.

This is very bad for our Firefox support, and so we have a lot of bugs on Firefox that have been fixed on master.

This issue represents the urgent need to resume our ability to publish to Firefox's addon store.

[danfinlay]

This could also be fixed by negotiating better terms with Mozilla, to get them accepting our builds as they are (since their acceptance criteria do not seem to require deterministic builds).

[danfinlay]

Maybe related to:
browserify/browserify#1796

[danfinlay]

Also related to #3664.

[williamchong]

just curious, will this allow a deterministic script hash usable in CSP to mitigate #3133 ?

[danfinlay]

Investigated a bit, looks very likely that browserify non-determinism is caused by a bug in uglifyify that deletes options flags when they pass through the transform.

There seems to be a good fix for it in this PR, but it's been sitting around for nearly a year, so I don't expect it merged any time soon.

We should probably move to a different minification strategy, but in the meanwhile, I've merged that patch into my own branch at danfinlay/uglifyify#keep-flags, so we can install from that and have control of our source, I can also move that into the MetaMask org.

Another fix could be to remove minification, but I know that could increase our bundle size beyond what Mozilla accepts (oh, the irony, that their requirements caused us to breach them!)

I think the short-term fix is to probably use this branch, so I'll open a PR for switching to that, and we can see how Mozilla likes that if no one objects.

[danfinlay]

Yes, I agree. The issue was automatically closed, my mistake for using "fixes" wording on the PR.