Your message dated Sun, 30 Nov 2014 23:25:51 +0100
with message-id <[email protected]>
and subject line Re: Bug#771588: unblock: https-everywhere/4.0.2-3
has caused the Debian Bug report #771588,
regarding unblock: https-everywhere/4.0.2-3
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
771588: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771588
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: unblock
Please unblock package https-everywhere
https-everywhere (4.0.2-3) unstable; urgency=medium
* forgotten bug closer in previous changelog entry
* add Bug-Debian to no-unconditional-FAQ-load.patch description
-- Damyan Ivanov <[email protected]> Fri, 28 Nov 2014 09:59:35 +0000
https-everywhere (4.0.2-2) unstable; urgency=medium
* Team upload
* Patch src/chrome/content/toolbar_button.js to make loading of the FAQ
require user action.
When run for the first time, the addon shows a notification bar.
Closing that bar loads the HTTPS-everywhere FAQ from the authors' site.
This is a privacy breach. This patch requires pressing a 'FAQ…' button
before loading the remote page.
Closes: #771286
-- Damyan Ivanov <[email protected]> Fri, 28 Nov 2014 09:31:54 +0000
This is similar in spirit with the unblock for greasemonkey/2.2-2, tracked in
#771242.
The changes add a patch requires that the user presses a button in order to
load the remote page, and just cdismissing the notification does nothing.
Patch attached, as well as a debdiff against 4.0.2-1 in Jessie.
unblock https-everywhere/4.0.2-3
Thanks,
dam
-- System Information:
Debian Release: jessie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: load FAQ after install only if requested
The first time the browser is started after installing
xul-ext-https-everywhere, a notification bar is shown, informing of
the fact that some https enforcement is active and pointing to the
toolbar button for options.
.
What is bad about that is that when the notification is dismissed, the
browser is forced to open https://www.eff.org/https-everywhere/faq
.
This is a privacy breach, as it informs the authors (and user's ISP)
that there is a new installation of https-everywhere.
.
The attached patch adds a dedicated button to the notification bar.
Pressing that button loads the FAQ page as before, and just dismissing
the notification bar does nothing. In other words, it makes the user
*request* the FAQ before loading it.
Author: Damyan Ivanov <[email protected]>
Forwarded: https://github.com/EFForg/https-everywhere/issues/769
Bug-Debian: https://bugs.debian.org/771286
--- a/src/chrome/content/toolbar_button.js
+++ b/src/chrome/content/toolbar_button.js
@@ -122,11 +122,15 @@ httpsEverywhere.toolbarButton = {
'https-everywhere',
'chrome://https-everywhere/skin/https-everywhere-24.png',
nBox.PRIORITY_WARNING_MEDIUM,
- [],
- function(action) {
- // see https://developer.mozilla.org/en-US/docs/XUL/Method/appendNotification#Notification_box_events
- gBrowser.selectedTab = gBrowser.addTab(faqURL);
- }
+ [
+ { accessKey: 'F',
+ callback: function(ntf, btn) {
+ // see https://developer.mozilla.org/en-US/docs/XUL/Method/appendNotification#Notification_box_events
+ gBrowser.selectedTab = gBrowser.addTab(faqURL);
+ },
+ label: 'FAQ…',
+ }
+ ]
);
}
gBrowser.removeEventListener("DOMContentLoaded", tb.handleShowHint, true);
diff -Nru https-everywhere-4.0.2/debian/changelog https-everywhere-4.0.2/debian/changelog
--- https-everywhere-4.0.2/debian/changelog 2014-10-17 01:29:13.000000000 +0300
+++ https-everywhere-4.0.2/debian/changelog 2014-11-28 12:00:13.000000000 +0200
@@ -1,3 +1,24 @@
+https-everywhere (4.0.2-3) unstable; urgency=medium
+
+ * forgotten bug closer in previous changelog entry
+ * add Bug-Debian to no-unconditional-FAQ-load.patch description
+
+ -- Damyan Ivanov <[email protected]> Fri, 28 Nov 2014 09:59:35 +0000
+
+https-everywhere (4.0.2-2) unstable; urgency=medium
+
+ * Team upload
+
+ * Patch src/chrome/content/toolbar_button.js to make loading of the FAQ
+ require user action.
+ When run for the first time, the addon shows a notification bar.
+ Closing that bar loads the HTTPS-everywhere FAQ from the authors' site.
+ This is a privacy breach. This patch requires pressing a 'FAQ…' button
+ before loading the remote page.
+ Closes: #771286
+
+ -- Damyan Ivanov <[email protected]> Fri, 28 Nov 2014 09:31:54 +0000
+
https-everywhere (4.0.2-1) unstable; urgency=low
* New upstream release.
diff -Nru https-everywhere-4.0.2/debian/patches/no-unconditional-FAQ-load.patch https-everywhere-4.0.2/debian/patches/no-unconditional-FAQ-load.patch
--- https-everywhere-4.0.2/debian/patches/no-unconditional-FAQ-load.patch 1970-01-01 02:00:00.000000000 +0200
+++ https-everywhere-4.0.2/debian/patches/no-unconditional-FAQ-load.patch 2014-11-28 11:58:21.000000000 +0200
@@ -0,0 +1,43 @@
+Description: load FAQ after install only if requested
+ The first time the browser is started after installing
+ xul-ext-https-everywhere, a notification bar is shown, informing of
+ the fact that some https enforcement is active and pointing to the
+ toolbar button for options.
+ .
+ What is bad about that is that when the notification is dismissed, the
+ browser is forced to open https://www.eff.org/https-everywhere/faq
+ .
+ This is a privacy breach, as it informs the authors (and user's ISP)
+ that there is a new installation of https-everywhere.
+ .
+ The attached patch adds a dedicated button to the notification bar.
+ Pressing that button loads the FAQ page as before, and just dismissing
+ the notification bar does nothing. In other words, it makes the user
+ *request* the FAQ before loading it.
+Author: Damyan Ivanov <[email protected]>
+Forwarded: https://github.com/EFForg/https-everywhere/issues/769
+Bug-Debian: https://bugs.debian.org/771286
+
+--- a/src/chrome/content/toolbar_button.js
++++ b/src/chrome/content/toolbar_button.js
+@@ -122,11 +122,15 @@ httpsEverywhere.toolbarButton = {
+ 'https-everywhere',
+ 'chrome://https-everywhere/skin/https-everywhere-24.png',
+ nBox.PRIORITY_WARNING_MEDIUM,
+- [],
+- function(action) {
+- // see https://developer.mozilla.org/en-US/docs/XUL/Method/appendNotification#Notification_box_events
+- gBrowser.selectedTab = gBrowser.addTab(faqURL);
+- }
++ [
++ { accessKey: 'F',
++ callback: function(ntf, btn) {
++ // see https://developer.mozilla.org/en-US/docs/XUL/Method/appendNotification#Notification_box_events
++ gBrowser.selectedTab = gBrowser.addTab(faqURL);
++ },
++ label: 'FAQ…',
++ }
++ ]
+ );
+ }
+ gBrowser.removeEventListener("DOMContentLoaded", tb.handleShowHint, true);
diff -Nru https-everywhere-4.0.2/debian/patches/series https-everywhere-4.0.2/debian/patches/series
--- https-everywhere-4.0.2/debian/patches/series 2014-10-17 01:29:13.000000000 +0300
+++ https-everywhere-4.0.2/debian/patches/series 2014-11-28 10:17:31.000000000 +0200
@@ -3,3 +3,4 @@
use-newer-timestamp-date.patch
make-clean.patch
use-recorded-upstream-commit-id.patch
+no-unconditional-FAQ-load.patch
--- End Message ---
--- Begin Message ---
On 2014-11-30 22:56, Damyan Ivanov wrote:
> Package: release.debian.org
> Severity: normal
> User: [email protected]
> Usertags: unblock
>
> Please unblock package https-everywhere
>
> [...]
>
> This is similar in spirit with the unblock for greasemonkey/2.2-2, tracked in
> #771242.
>
> The changes add a patch requires that the user presses a button in order to
> load the remote page, and just cdismissing the notification does nothing.
>
> Patch attached, as well as a debdiff against 4.0.2-1 in Jessie.
>
> unblock https-everywhere/4.0.2-3
>
>
> Thanks,
> dam
>
> [...]
Unblocked, thanks.
~Niels
--- End Message ---
