Package Details: firefox-extension-https-everywhere 5.2.5-1

Git Clone URL: https://aur.archlinux.org/firefox-extension-https-everywhere.git (read-only)
Package Base: firefox-extension-https-everywhere
Description: Plugin for firefox which ensures you are using https whenever it's possible.
Upstream URL: https://www.eff.org/https-everywhere
Licenses: GPL2
Submitter: hcartiaux
Maintainer: hcartiaux (Eschwartz)
Last Packager: Eschwartz
Votes: 41
Popularity: 0.094445
First Submitted: 2011-11-08 21:24
Last Updated: 2016-09-22 04:26

Latest Comments

dvzrv commented on 2016-09-22 10:13

@Eschwartz: 5.2.5 doesn't validate with firefox 49

Eschwartz commented on 2016-09-05 14:08

Updated. :)

AMO finally let it pass full review. At one point they were extremely fast, but it took a lot longer this time, so I was worrying that they might have regressed to never-never land again... but all is well.

Gruentee commented on 2016-09-05 13:12

New checksum

8206329c71af19e051d650c34fdc67b3f61a392c1ef80a4a6f40c8fb0abc662a

Eschwartz commented on 2016-07-21 02:25

Pushed an update to 5.2.1

Also, a bit of templated code which should detect when an extension does not have signing data sufficient for Firefox to approve of, and add a warning and install script.
Which should help maintainers easily determine if their extensions have issues, and conditionally give the warning to end-users, not that I anticipate the need. Mozilla has been good about reviewing HTTPS Everywhere these days.

Since I did try to make this as generic a template as possible...

Eschwartz commented on 2016-02-19 18:27

Awesome.

Not sure why it was updated to 5.1.3 a month early, but updated now.
Removed the post-install warning, and hopefully this is a good omen for the future.

polyzen commented on 2016-02-19 17:51

The verified version is now up on AMO.

Eschwartz commented on 2015-12-23 18:28

Updated, with the latest still-unreviewed version, and a post-install warning.

hcartiaux commented on 2015-12-18 22:23

@Eschwartz: thanks for the help, done!

I will not use a custom firefox, I don't want to recompile it :)
For the moment, I've set xpinstall.signatures.required to false in about:config.

If we can't find a solution before the release of firefox 44, I will stop managing my extension via pacman...

Eschwartz commented on 2015-12-18 19:11

I'd be happy to co-maintain it, help keep an eye on the latest release and check when it passes AMO review...

But I'm thinking people with extensions, particularly the troublesome ones, may wish in the long term to use an AUR-built Firefox with this patch: https://bugs.archlinux.org/task/47432

hcartiaux commented on 2015-12-18 17:19

@polyzen:
> You should remove the unzip makedep and the prepare function

It's needed to recover the emid, bsdtar does not unzip correctly the xpi


@Eschwartz: I'm blocked at this point, there's a new release, 5.1.2, but it's not on AMO. If somebody wants to help, I can add co-maintainers...

Eschwartz commented on 2015-12-16 02:39

This didn't fix the signing issue, it seems the real problem is that the signing mechanism must perform some virtual `chmod 600 META-INF/*` (explains the problems I had with unzipping *other* extensions, you need to explicitly `chmod -R ugo+rX`) plus of course the signing mechanism.
Extensions don't work if the signatures are only readable by root. :rolleyes:

Yes, I am still kicking myself for not seeing that months ago. Sigh. I will just tell myself it is all Mozilla's fault for making things complicated, right? :lol:


I see NO solution short of disabling verification or praying to Mozilla that they will one day get around to reviewing it properly.
Here is the bugreport I opened to beseech the Arch devs to disable extension verification in the repo firefox: https://bugs.archlinux.org/task/47395



And https-everywhere breaks when installed as a *.xpi, it doesn't appear to pick up any rulesets. (See, the developers must have known what they were talking about after all...)
I have also now found an extension which does not require unpacking, and actually breaks when unpacked, so my extensions quest is now fulfilled. :p

polyzen commented on 2015-12-14 13:51

You should remove the unzip makedep and the prepare function

hcartiaux commented on 2015-12-14 10:58

I've updated the PKGBUILD with a new install method (moving the xpi in the global extension dir)...
Unfortunately, only 5.1.0 appears to be signed on AMO, all the other releases/xpi (eff/AMO) appears non-signed.

I don't want to decrease the PKGBUILD version, so it should be fixed with the next release on AMO...

hcartiaux commented on 2015-11-25 10:55

I've updated the sha256sums, I will take the time soon to test and update all my PKGBUILD with the new signing mechanism...

Eschwartz commented on 2015-11-25 02:03

Yes, it still shows as not verified.

I filed a bugreport on Mozilla's bugzilla [1] trying to figure out what's going on, apparently it is all because of "sideloaded" extensions.

I am getting more and more confused about what they mean by "sideloaded" extensions, though. :lol:


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1218158

polyzen commented on 2015-11-23 01:01

It has to be installed straight from the website, even.

polyzen commented on 2015-11-23 00:57

Eschwartz, does the add-ons manager show this as not verified for you? Only way I can get it to show as verified, is to install straight through the browser.

If I move the verified extension from my profile to the global extensions dir, it no longer shows as verifieed. It still shows as unverified when I move it back..

Eschwartz commented on 2015-11-22 22:59

I did mention the checksum issue way back in October...

Not sure why the checksum hasn't been updated, but other than that it is fine. :)

polyzen commented on 2015-11-22 22:42

Not sure if this was clear: the current checksum is for 5.1.1 before it was signed.

polyzen commented on 2015-11-22 22:41

GI_Jack, both sources (AMO and EFF) are now signed, so the signed copy is what you've downloaded. This just needs a checksum bump

GI_Jack commented on 2015-11-22 22:23

sha256 sum is off, plz check:

sha256sums=('c5eee0285962daeda587499ca284281f4606f2cc27a51ada611996dbd84444a4')

is what I am getting. I am holding off until some other people comment.

polyzen commented on 2015-10-11 05:42

According to this issue [1], HTTPS Everywhere has to be manually reviewed every release. The review of 5.1.1 hasn't been completed, and that's why it's unverified. You can see here [2] if you click "Add to Firefox" next to 5.1.1.

[1] https://github.com/EFForg/https-everywhere/issues/2051
[2] https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/versions/

Eschwartz commented on 2015-10-02 18:09

Ah, that sounds helpful.
So, many of these extensions could just be left in an XPI.


Unfortunately, that doesn't help *this* extension.
And for the ones that need unzipping, I still favor disabling validation in the Firefox build.
I like that idea regardless, but that's offtopic. :o

polyzen commented on 2015-10-02 17:31

Extensions are supposed to explicitly state it needs to be extracted
in its install.rdf.
https://developer.mozilla.org/en-US/docs/Extensions/Updating_extensions_for_Firefox_4#XPI_unpacking

Apparently, you've nailed it! https-everywhere is afaicr the only
extension I use that requires this. Perhaps it works zipped and they
have misunderstood?
<em:unpack>true</em:unpack> <!-- Required for Firefox 4 -->

Eschwartz commented on 2015-10-02 16:41

firefox-extension-ublock-origin merely copied the XPI to /usr/lib/firefox/browser/extensions/
That is the first firefox extension in the AUR that I've seen do that.

Usually they get unzipped. Apparently it is the unzipping that messes verification up.
example: firefox-extension-ghostery is downloaded direct from AMO and shows verification warnings.
Lastpass (private PKGBUILD) and Adblock Plus are *always* distributed through their website, not AMO, and show verification warnings.

Recommended way is to unzip:
https://developer.mozilla.org/en-US/Add-ons/Installing_extensions

"To install extensions into these directories you must extract the extension to a directory with the same name as the the extension's ID. The ID is defined in the install.rdf of the extension, between the <id></id> tags."

But...

"In Firefox 4 you may also just copy the extension's XPI to the directory and name it <ID>.xpi as long as the extension does not require extraction to work correctly."
Does that mean restartless extensions only???

polyzen commented on 2015-10-02 15:25

Eschwartz, all the other AMO sourced system-installed packages that I use are verified -- hoping the issue I had with this one was PEBCAK. Try firefox-extension-ublock-origin, for instance.

The others are addons are apparently unmaintained and still not on AMO -- should poke their upstream. Oh, and of course there's pentadactyl ;p

Eschwartz commented on 2015-10-02 06:11

checksum failed, but it's still the same version. What's up with that...


On the signing issue, I get that for all system-installed extensions. Most of which are downloaded from AMO.
I would much prefer to ignore the signing policy and beg the Arch devs to disable extension validation. :P

polyzen commented on 2015-09-19 02:36

Afaik, the AMO versions pages would say if an addon isn't signed, but according to FF, it doesn't seem to be signed from either source...

polyzen commented on 2015-09-18 14:35

I may have spoken too soon

polyzen commented on 2015-09-18 13:57

Source from AMO if you want it to be signed https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/versions/

FF said https-everywhere-5.1.0-eff.xpi was signed, but https-everywhere-5.1.1-eff.xpi apparently is not

hcartiaux commented on 2015-08-19 08:59

Thanks for your comment, I've tried to fix the PKGBUILD accordingly and I updated it to 5.1.0 at the same time.

Marcel_K commented on 2015-08-18 20:26

Please enclose every instance of $srcdir, $pkgdir, and, in your case, $dstdir, within double quotes to allow for spaces in directory names.

Is it really necessary to chmod all directories *and* files to 755? I experienced the plugin isn't recognized when removing that line from my PKGBUILD, but *all* files?

BTW, you don't need that || return 1 anymore.

wizard8449 commented on 2015-04-13 06:47

Small typo in the PKGBUILD prepare section. Changes directory to srcdir then executes one directory back so it doesn't find the package.

Currently is:
unzip -qqo ../https-everywhere-${_plugin_version}.xpi

Should be:
unzip -qqo ./https-everywhere-${_plugin_version}.xpi

hcartiaux commented on 2014-05-09 08:41

Ok, I've checked how it's done in Debian:
https://packages.debian.org/fr/sid/xul-ext-https-everywhere

Debian patches the extension in order to fix the path for the rulesets db.

Sorry for this bug, I'll fix it asap.

hcartiaux commented on 2014-05-07 08:25

The rules are now in a sqlite database: defaults/rulesets.sqlite
I need some time to debug...

aphirst commented on 2014-05-05 10:42

Installed 3.5.1 to a fresh Arch install, with a fresh Firefox install, and does not seem to actually include any preset rules. None are ever listed in the HTTPS-Everywhere URL-bar icon...

/usr/lib/firefox/browser/extensions/https-everywhere@eff.org/chrome/content/rules/ is empty other than a readme file. The equivalent folder on the project's git repository contains thousands of rules.

Keysuke commented on 2014-04-20 08:45

3.5 released

hcartiaux commented on 2013-10-11 14:47

There's a bug with bsdtar and the new xpi package.
Basically:

wget https://www.eff.org/files/https-everywhere-3.4.2.xpi
bsdtar -xf https-everywhere-3.4.2.xpi
cat install.rdf

All the files are empty

unzip install.rdf
-> OK

I don't have the time to debug it...
I will upload a PKGBUILD with a ugly workaround for this version, and remove it for the next updates...

hcartiaux commented on 2013-03-19 11:10

Thanks for your advises, it's fixed.

gtmanfred commented on 2013-03-18 21:54

anything that touches $pkgdir should be in the package() function

do not use mv to put stuff in $pkgdir, use cp -dpr --no-preserve=ownership

ajs124 commented on 2012-11-02 20:26

3.0.3 was released

GI_Jack commented on 2012-10-09 13:59

3.0 released

hcartiaux commented on 2012-08-20 13:11

Thanks holyArch, it's updated ;)

holyArch commented on 2012-08-20 00:10

2.2 released

holyArch commented on 2012-08-20 00:09

2.2.1 released

hcartiaux commented on 2012-03-12 18:35

Yes, sure...

% makepkg -g
==> Récupération des sources...
-> Téléchargement de https-everywhere-latest.xpi...
==> Génération des sommes de contrôle des sources...

md5sums=('05921026cda5038d1a4f27d2cf8a083d')

Anonymous comment on 2012-03-12 00:53

md5sum has failed for several weeks => flagged OOD

Anonymous comment on 2012-03-12 00:52

==> Validating files with md5sums...
https-everywhere-latest.xpi ... FAIL
==> ERROR : One or more files are not valid !