Bug 1128754 - Review Request: mozilla-requestpolicy - Firefox and Seamonkey extension that gives you control over cross-site requests
Summary: Review Request: mozilla-requestpolicy - Firefox and Seamonkey extension that ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paulo Andrade
QA Contact: Paulo Andrade
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-11 13:21 UTC by Antonio
Modified: 2015-02-14 02:51 UTC (History)
3 users (show)

Fixed In Version: mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-06 04:02:29 UTC
paulo.cesar.pereira.de.andrade: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1048493 None CLOSED Review Request: icecat - GNU version of Firefox browser 2018-10-03 17:42:37 UTC

Internal Links: 1048493 1185562

Description Antonio 2014-08-11 13:21:43 UTC
Spec URL: https://sagitter.fedorapeople.org/mozilla-requestpolicy/mozilla-requestpolicy.spec
SRPM URL: https://sagitter.fedorapeople.org/mozilla-requestpolicy/mozilla-requestpolicy-0.5.28-1.fc20.src.rpm

Description: With RequestPolicy installed, you will see a new flag icon normally 
at the top-right of your browser. 
This flag turns red when RequestPolicy has blocked requests 
from the current website you are viewing.

You'll notice on web pages you visit that blocked cross-site images 
are indicated with a red flag and border in the place of where 
the image would have been. Hovering your cursor over the blocked 
image will tell you which domain the blocked image was from.

Clicking on the RequestPolicy icon in the status bar brings up
a menu of options. The menu looks like the image below.

The menu indicates destination domains from the current site 
that have either been blocked or allowed.Each of the destination 
domains listed have their own menus which give you options 
about which requests to allow.

Fedora Account System Username: sagitter

Comment 1 Christopher Meng 2014-08-30 00:58:19 UTC
I will give it a try later, as I've never reviewed such packages..

Comment 2 Antonio 2015-01-22 22:15:03 UTC
I assign reviewer to default according to the policies for stalled package reviews.

Comment 4 Paulo Andrade 2015-01-23 14:01:45 UTC
I would like some comments about these "===== MUST items =====":

1. It says License GPLv3+ and LGPLv3+ MPLv2
I believe it is LGPLv2.1+ (the icons) and not LGPLv3+. Please verify.
I believe the MPLv2 are only the tests, so, MPLv2 should be only sources,
not installed files. Please verify.
"""
[ ]: If the package is under multiple licenses, the licensing breakdown must
     be documented in the spec.
"""
The license tag should also have an extra "and" if keeping as is, that is:
-GPLv3+ and LGPLv3+ MPLv2
+GPLv3+ and LGPLv3+ and MPLv2

2. It is the owner of %{firefox_inst_dir} and %{seamonkey_inst_dir}
This looks wrong. Too bad firefox-filesystem is not the onwer of %{firefox_inst_dir}, but there are other packages that think they are the owner.
seamonkey is the owner of %{seamonkey_inst_dir}.
I think it should be worth a bug report for firefox-filesystem for it to become owner of %{firefox_inst_dir}
"""
[ ]: Package must own all directories that it creates.
     Note: Directories without known owners:
     /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
[ ]: Package does not own files or directories owned by other packages.
     Note: Dirs in package are owned also by: /usr/share/mozilla/extensions
     /{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}(mozilla-esteid, seamonkey,
     mozilla-https-everywhere)
"""

3. Please correct:
"""
[ ]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf %{buildroot} present but not required
"""

Comment 5 Antonio 2015-01-23 14:43:44 UTC
(In reply to Paulo Andrade from comment #4)
> 
> 2. It is the owner of %{firefox_inst_dir} and %{seamonkey_inst_dir}
> This looks wrong. Too bad firefox-filesystem is not the onwer of
> %{firefox_inst_dir}, but there are other packages that think they are the
> owner.
> seamonkey is the owner of %{seamonkey_inst_dir}.
> I think it should be worth a bug report for firefox-filesystem for it to
> become owner of %{firefox_inst_dir}
> """
> [ ]: Package must own all directories that it creates.
>      Note: Directories without known owners:
>      /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
> [ ]: Package does not own files or directories owned by other packages.
>      Note: Dirs in package are owned also by: /usr/share/mozilla/extensions
>      /{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}(mozilla-esteid, seamonkey,
>      mozilla-https-everywhere)
> """

%{firefox_inst_dir}=%{moz_extensions}/%{firefox_app_id}/requestpolicy@requestpolicy.com

must be owned by this package.

%{moz_extensions}/%{firefox_app_id} is co-owned with 'firefox'.
%{moz_extensions} is owned by 'mozilla-filesystem' that is required by 'firefox'.

Is it not right?

Comment 7 Paulo Andrade 2015-01-24 14:34:21 UTC
Since it requires firefox in rhel, there it should not
need to also be the owner of %{firefox_inst_dir}.
In non rhel it does not explicitly require firefox,
so, should be ok to co-own the directory.
I say that because it usually is not considered a
good idea to have multiple packages owning the same
(file or) directory.

Anyway looking at https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
I think it should be worth opening a bug report asking
for mozilla-filesystem to become the owner of
%{moz_extensions}/%{firefox_app_id}, or, have the
package also require firefox on Fedora.

But I will not consider it a blocker.

The package is approved.

Comment 8 Antonio 2015-01-24 18:31:54 UTC
New Package SCM Request
=======================
Package Name: mozilla-requestpolicy
Short Description: Firefox and Seamonkey extension that gives you control over cross-site
Upstream URL: https://www.requestpolicy.com
Owners: sagitter
Branches: f21 f20 el6 el7

Comment 9 Gwyn Ciesla 2015-01-25 21:49:25 UTC
Git done (by process-git-requests).

Comment 10 Fedora Update System 2015-01-26 17:38:51 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el7

Comment 11 Fedora Update System 2015-01-26 17:38:56 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el6

Comment 12 Fedora Update System 2015-01-26 17:39:02 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/mozilla-requestpolicy-1.0-0.2.20141213gitd27363.fc21

Comment 13 Fedora Update System 2015-01-26 17:39:08 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mozilla-requestpolicy-1.0-0.2.20141213gitd27363.fc20

Comment 14 Fedora Update System 2015-01-27 19:31:59 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el6 has been pushed to the Fedora EPEL 6 testing repository.

Comment 15 Fedora Update System 2015-02-06 04:02:29 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.fc20 has been pushed to the Fedora 20 stable repository.

Comment 16 Fedora Update System 2015-02-06 04:03:15 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.fc21 has been pushed to the Fedora 21 stable repository.

Comment 17 Fedora Update System 2015-02-14 02:42:32 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el7 has been pushed to the Fedora EPEL 7 stable repository.

Comment 18 Fedora Update System 2015-02-14 02:51:30 UTC
mozilla-requestpolicy-1.0-0.2.20141213gitd27363.el6 has been pushed to the Fedora EPEL 6 stable repository.


Note You need to log in before you can comment on or make changes to this bug.