The phishing warning page URL environment variable has been renamed
from `PHISHING_PAGE_URL` to `PHISHING_WARNING_PAGE_URL`. We call this
page the "phishing warning page" everywhere else, and this name seemed
better suited (it's not a phishing page itself).
The variable has been listed and documented in `.metamaskrc.dist` as
well.
An externally hosted phishing warning page is now used rather than the
built-in phishing warning page.The phishing page warning URL is set via
configuration file or environment variable. The default URL is either
the expected production URL or `http://localhost:9999/` for e2e testing
environments.
The new external phishing page includes a design change when it is
loaded within an iframe. In that case it now shows a condensed message,
and prompts the user to open the full warning page in a new tab to see
more details or bypass the warning. This is to prevent a clickjacking
attack from safelisting a site without user consent.
The new external phishing page also includes a simple caching service
worker to ensure it continues to work offline (or if our hosting goes
offline), as long as the user has successfully loaded the page at least
once. We also load the page temporarily during the extension startup
process to trigger the service worker installation.
The old phishing page and all related lines have been removed. The
property `web_accessible_resources` has also been removed from the
manifest. The only entry apart from the phishing page was `inpage.js`,
and we don't need that to be web accessible anymore because we inject
the script inline into each page rather than loading the file directly.
New e2e tests have been added to cover more phishing warning page
functionality, including the "safelist" action and the "iframe" case.
* Update version parsing to allow rollback release
When we want to rollback a release on Chrome, sometimes we use the
fourth part of the version for the rollback release. This is because
the Chrome web stores does not directly allow rolling back, but instead
requires us to re-submit the release we want to roll back to with a
higher version number.
The manifest version parsing now allows for a fourth version part.
The comments have also been updated to be more descriptive, and to fix
a minor inaccuracy.
* Fix typo in comment
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Adds a new flag, `--apply-lavamoat`, to the main build script. The flag controls whether LavaMoat is actually applied to the output of the build process. The flag defaults to `true`, but we explicitly set it to `false` in the `start` package script. Meanwhile, the `start:lavamoat` script is modified such that it applies LavaMoat to the build output in development mode, but it no longer runs the build process itself under LavaMoat as there aren't very compelling reasons to do so.
This change is motivated by the fact that development builds do not have their own dedicated LavaMoat policies, which causes development builds to fail since #14537. The downside of this change is that LavaMoat-related failures will not be detected when running `yarn start`. @kumavis has plans for fixing this problem in a future major version of the `@lavamoat` suite.
* Rename NotificationController to AnnouncementController
* Fix test
* Add test for missing NotificationController state
* Bump controllers
* Move test to correct file
* Rename config key
* Add migration 71 to list of migrations
* Fix selector after migration
* fix failed off chain tx mismatch with next confirmed transaction
* dont drop failed txs when tx in confirmed
* add comment for reassigning logic
* resolve change requests
We currently store the JSON-RPC request and response objects in the permission activity log. The utility of doing this was always rather dubious, but never problematic. Until now.
In Flask, as the restricted methods have expanded in number, user secrets may be included on JSON-RPC message objects. This PR removes these properties from the permission activity log, and adds a migration which does the same to existing log objects. We don't interact with the log objects anywhere in our codebase, but we don't want unexpected properties to cause errors in the future should any log objects be retained.
This PR also updates relevant tests and test data. It makes a minor functional change to how a request is designated as a success or failure, but this should not change any behavior in practice.
benlwyre
Daniel
Jyoti Puri
Brad Decker
Frederik Bolding
Mark Stacey
Dan J Miller
Lachlan Tweedie
Hassan Malik
Ariella Vu
Niranjana Binoy
Alex Donesky
kumavis
Erik Marks
Shane
ryanml
Guillaume Roux
David Walsh
Hennadii Ivtushok
kumavis
amerkadicE
MetaMask Bot
VSaric