Good point! It looks like all of the rules are here[1], so as long as there is oversight by the EFF, their repo isn't compromised, someone doesn't put out a fake build, etc., we should be safe.
Also it looks like[2] some rules are built in such a way that only the protocol is changed and the domain is left as-is.
HTTPS Everywhere has a few important precautions in place, and would welcome suggestions or code contributions for others. One of these is reproducibility of the package build, so you can check out the source tree, verify the signed tag, and build the same byte-for-byte identical XPI file that is being distributed from EFF's web site. (I just did this for the 5.0.1 XPI and the files were the same, although my colleague who made that release notes that there is a still-incompletely-documented dependency on the libsqlite3 version.)
There are also scripts that indicate whether rules redirect to non-HTTPS targets and whether the rules contain non-ASCII characters (to avoid homoglyph attacks, like <rule from="^https?://www\.paypal\.com/" to="https://www.pаypаl.cοm/">).
Because of the challenges of parsing PCRE with backreferences, there are no scripts that check whether the target domains are the same as the source domains (and there have been a small number of rules that did intentionally rewrite to a different domain). These do get read by human beings before being included in the project, and traditionally new rules are included for months in the development release before being migrated into the stable release, but it would be a great thing if more human beings would check them, or help develop scripts that do so in new ways.
One idea that we've talked about in the past is to divide rules into simple and complex, and then single out only the complex rules for extra human auditing. (Simple rules would be syntactically constrained not to rewrite across domains.)
There are also scripts that indicate whether rules redirect to non-HTTPS targets and whether the rules contain non-ASCII characters (to avoid homoglyph attacks, like <rule from="^https?://www\.paypal\.com/" to="https://www.pаypаl.cοm/">).
Because of the challenges of parsing PCRE with backreferences, there are no scripts that check whether the target domains are the same as the source domains (and there have been a small number of rules that did intentionally rewrite to a different domain). These do get read by human beings before being included in the project, and traditionally new rules are included for months in the development release before being migrated into the stable release, but it would be a great thing if more human beings would check them, or help develop scripts that do so in new ways.
One idea that we've talked about in the past is to divide rules into simple and complex, and then single out only the complex rules for extra human auditing. (Simple rules would be syntactically constrained not to rewrite across domains.)