Now old vaults are recognized as an "Initialized" MetaMask instance.
Upon logging in, when fetching the initial password-derived key, if there is no new-style vault, but there is an old style vault, it is migrated to the new format before proceeding through the usual unlocking steps.
This contract hex does include the value `f4`, but it was compiled from a contract with no instance of `.delegatecall`. I believe `f4` in this case is part of some other value or contract address, and `ethBinToOps` has some error in how it skips pushed data.
@kumavis
SubmitPassword was not creating a new id-management
This is because I broke up the old "createIdmgmt" method to not perform as much conditional logic.
Now the pieces are reusable and do what they should do.
Fixed bug where the second new vault created in an IdStore would initially return the accounts from the original store.
Also fixed some tests that were incorrect.
eth-lightwallet was previously not salting vault passwords, potentially making it easier to crack them once obtained.
This branch incorporates the API changes to allow us to take advantage of the new salting logic.
This is still throwing deprecation warnings, but that's actually a bug in eth-lightwallet I wrote, [I've submitted a PR for that here](https://github.com/ConsenSys/eth-lightwallet/pull/116).
Fixes#555
* Add mozilla plugin key to manifest
* Move all chrome references into platform-checking module
Addresses #453
* Add chrome global back to linter blacklist
* Add tests