Opened 9 years ago

Closed 8 years ago

#3533 closed defect (fixed)

HTTPS Everywhere doesn't rewrite URLs passed as command line arguments to Firefox

Reported by: schoen Owned by: pde
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords:
Cc: inkerman42@…, dm0 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In Firefox 5.0 in Ubuntu's Natty Narwhal, with HTTPS Everywhere 1.0.0development.3, a URL initally passed to Firefox from the command line is never rewritten. E.g.

$ firefox http://www.google.com/

results in a new Firefox process showing the unencrypted http://www.google.com/. However, manually typing "http://www.google.com/" in the address bar of a running Firefox works correctly. Also, running an additional "firefox" command once Firefox is already running results in the existing Firefox opening a new tab, in which the URL is properly secured.

HTTPS Everywhere believes that the rule has been applied in that the rule is correctly displayed in the context menu and is green. But in reality, the rule has not actually been successfully applied.

I believe this problem does not occur in Firefox 3.6.18.

Child Tickets

Attachments (1)

bug_3533_2.patch (3.2 KB) - added by haviah 8 years ago.
Resolving ruleset directory synchronously via chrome:// URL instead of AddonManager

Download all attachments as: .zip

Change History (8)

comment:1 Changed 9 years ago by schoen

Confirmed that the problem does not occur in Firefox 3.6.18.

comment:2 Changed 9 years ago by pde

Priority: majornormal
Status: newaccepted

One possible reason for this is that HTTPS Everywhere's initialisation code hasn't run yet when that request is sent. Note that as of commit cbd9dbce, there has been an extra asynchronous step in Firefox 4+ initialisiation. You could see if that commit introduced this issue.

comment:3 Changed 8 years ago by inkerman

Cc: inkerman42@… added

Changed 8 years ago by haviah

Attachment: bug_3533_2.patch added

Resolving ruleset directory synchronously via chrome:// URL instead of AddonManager

comment:4 Changed 8 years ago by haviah

In the attached patch, the AddonManager asynchronous call is replaced by resolving of URL "chrome://https-everywhere/content/rules/" to get the ruleset dir, which works for both cases - addon installed in profile directory and global install (/usr/share/mozilla/...).

Since the there is no asynchronous step in initialization, the race condition does not occur.

Tested on FF 3.6.23 and 7.0.1 (Linux).

comment:5 Changed 8 years ago by pde

Cc: dm0 added

Applied in git master:

https://gitweb.torproject.org/https-everywhere.git/commitdiff/76799bf56bb89422fd2e40ce7fb739ae0a7c45f9

Ideally we would also test that this doesn't break centrally-installed packages of HTTPS Everywhere before this gets released. CCing dm0, who has been interested in that subject in the past...

comment:6 Changed 8 years ago by dm0

I did some brief testing on my systems with the stable 7.0.1 and the nightly build (alpha of version 10), and it looks good to me so far.

comment:7 Changed 8 years ago by pde

Resolution: fixed
Status: acceptedclosed

This fix has been released in 2.0development.3, closing.

Note: See TracTickets for help on using tickets.