Bug 916627

Summary: Requesting re-review of tor package
Product: [Fedora] Fedora Reporter: Jamie Nguyen <jamielinux>
Component: torAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: awilliam, lmacken, misc, pwouters
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-16 01:38:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jamie Nguyen 2013-02-28 14:15:38 UTC
This package is already part of Fedora, but after a change of maintainership, there are significant changes to the package so I would like to request a re-review.

Spec: http://jamielinux.fedorapeople.org/fix-tor/tor.spec
SRPM: http://jamielinux.fedorapeople.org/fix-tor/SRPMS/tor-0.2.3.25-1924.fc18.src.rpm

Patches from this series have been applied:
http://jamielinux.fedorapeople.org/fix-tor/series/

Reviewing the latest spec should be quite straightforward, as excluding the changelog it's only 120 lines, compared to the 250 lines is used to be. The package is buildable and installable/upgradable after each patch in the series, so the reviewer may alternatively choose to review each patch individually.

Comment 1 Kevin Kofler 2013-02-28 22:20:32 UTC
One thing I notice is this:
> export LDFLAGS='-Wl,--as-needed'
Doesn't this trash the default RPM_LD_FLAGS? I think you want:
export LDFLAGS='%{?__global_ldflags} -Wl,--as-needed'
instead.

(And I assume you'll reset Release to 1 with the next version upgrade. I realize we're stuck with the 19xx nonsense for now because the upgrade path needs to be kept.)

Comment 2 Michael S. 2013-02-28 22:52:16 UTC
Could you push systemd file upstream, as well as the logrotate file ?

And adding a comment saying "remove this obsolete in fedora for this version of fedora" would be nice so we can clean them one day.

and %{_datadir}/tor/ seems to not be owned by the rpm.

Comment 3 Michael S. 2013-02-28 22:52:54 UTC
I would also comment why torsocks is needed ( I guess that's for torify )

Comment 4 Jamie Nguyen 2013-03-01 00:45:29 UTC
Thanks for the re-reviews so far Kevin and Michael. I knew it was a good idea.

Kevin wrote:
>One thing I notice is this:
>> export LDFLAGS='-Wl,--as-needed'

This is a remnant of the previous package that I forgot to remove. I don't really see a compelling reason for it, and upstream don't do it in their package, so I've removed it until someone convinces me otherwise.


Michael wrote:
> Could you push systemd file upstream, as well as the logrotate file ?

Logrotate file is already upstream. The version in this package is slightly modified (as we run with different user, and reload with systemd instead of initscripts). I've added a comment about this.

I've opened a ticket upstream about including the systemd file.


Michael wrote:
> And adding a comment saying "remove this obsolete in fedora for
> this version of fedora"

Done.


Michael wrote:
> and %{_datadir}/tor/ seems to not be owned by the rpm.

Good catch, this was my mistake. Fixed.


Michael wrote:
> I would also comment why torsocks is needed ( I guess that's
> for torify )

Yes it's for torify. Comment added.


Spec: http://jamielinux.fedorapeople.org/fix-tor/tor-1927.spec
SRPM: http://jamielinux.fedorapeople.org/fix-tor/SRPMS/tor-0.2.3.25-1927.fc18.src.rpm

Comment 5 Jamie Nguyen 2013-03-01 00:46:44 UTC
Kevin wrote:
> (And I assume you'll reset Release to 1 with the next
> version upgrade. I realize we're stuck with the 19xx
> nonsense for now because the upgrade path needs to be
> kept.)

Yes that is correct. I fully intend to amend this when appropriate.

Comment 6 Adam Williamson 2013-03-01 23:24:58 UTC
Jamie: "This is a remnant of the previous package that I forgot to remove. I don't really see a compelling reason for it"

--as-needed is intended to reduce overlinking, IIRC. I don't think a package maintainer adding it to a single downstream spec by fiat is a good idea, though; it should either be something upstream does, or some kind of project-wide policy. So I'd support removing it. I believe it's highly unlikely that removing it could make things _less_ likely to work, though in theory it might mean the compiled code links against more stuff than it strictly has to. (My knowledge on this area is somewhat out of date and the flag may be irrelevant these days).

Aside from that, FWIW, I eyeballed the spec and it looks good to me. Thanks for your work on this.

Comment 7 Jamie Nguyen 2013-03-02 10:48:45 UTC
Thanks very much Adam for contributing to the re-review. My understanding of --as-needed is pretty rudimentary, but my take on it is pretty similar to yours. I'm glad you support removing it. And thanks for looking through the spec. The more eyes the better, as I'm just human after all and I've made bad mistakes before...


We've made a couple more commits since last time.

Spec: http://jamielinux.fedorapeople.org/fix-tor/tor-1929.spec
SRPM: http://jamielinux.fedorapeople.org/fix-tor/SRPMS/tor-0.2.3.25-1929.fc18.src.rpm

* Sat Mar 02 2013 Jamie Nguyen <jamielinux> 0.2.3.25-1929
- add "Log notice syslog" back to tor.defaults-torrc as recommended by
  upstream: https://bugzilla.redhat.com/show_bug.cgi?id=532373#c19

* Fri Mar 01 2013 Jamie Nguyen <jamielinux> 0.2.3.25-1928
- increase LimitNOFILE in tor.service from 4096 to 32768, as advised by
  upstream: https://trac.torproject.org/projects/tor/ticket/8368#comment:4


misc also mentioned some systemd hardening that might be done (eg, chroot or restricting access to certain directories, restricting access to /dev etc.) so we'll be tackling that after the first update has been pushed to the repository.

Comment 8 Fedora Update System 2013-03-05 00:34:40 UTC
tor-0.2.3.25-1802.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/tor-0.2.3.25-1802.fc18

Comment 9 Fedora Update System 2013-03-05 23:20:08 UTC
Package tor-0.2.3.25-1802.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing tor-0.2.3.25-1802.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-3434/tor-0.2.3.25-1802.fc18
then log in and leave karma (feedback).

Comment 10 Paul Wouters 2013-03-06 14:32:01 UTC
I did a review, but since I'm co-maintainer, if we do an official review, someone else should do it to.

- I changed the URL to use https - I removed the unused lastver/verinfo files

- I'm confused why /var/log/tor is group-readable but /var/lib/tor is
  not. I assume we either trust the group, or not. I'd say enable group
  read for /var/lib/tor. That way a user can add themselves to the group
  and look at what /  how tor is doing without needing root or sudo to the
  toranon user. Or change /var/log/tor to be user/root only.
  (waiting on answer of upstream)

- I assume once a new release happens by upstream, we are getting rid of
  the insane four digit versioning?  
  (Jamie confirmed)

- /usr/bin/torify should never be needed, since we Require: torsocks ?
  Can we just not install it? Would a user call this directly?
  (if not, should it not go into /usr/lib/tor/ or libexec?)
  (Jamie clarified users might call it and expect it to be there, so ok)

Package Review
==============

Key:
[x] = Pass
[!] = Fail
[-] = Not applicable
[?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
[-]: Package do not use a name that already exist
     Note: A package already exist with this name, please check
     https://admin.fedoraproject.org/pkgdb/acls/name/tor
See: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Conflicting_Package_Names
[!]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 1433600 bytes in 10 files.
See: http://fedoraproject.org/wiki/Packaging/Guidelines#PackageDocumentation

pwouters: docs are changelog/release notes. A bit large, but seems silly to package separately.
          Should we not package it up?

===== MUST items =====

C/C++:
[x]: Header files in -devel subpackage, if present.
[x]: Package does not contain any libtool archives (.la)
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package contains no bundled libraries.
[x]: Changelog in prescribed format.
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Sources contain only permissible code or content.
[x]: %config files are marked noreplace or the reason is justified.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package requires other packages for directories it uses.
[x]: Package uses nothing in %doc for runtime.
[x]: Package is not known to require ExcludeArch.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package complies to the Packaging Guidelines
[x]: Spec file lacks Packager, Vendor, PreReq tags.
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "BSD (3 clause)", "*No copyright* Beerware", "GPL (v2 or later)",
     "Unknown or generated". 4 files have unknown license. Detailed output of
     licensecheck in /home/paul/fedora/tor/review-tor/licensecheck.txt

pwouters: those are fine

[x]: Package consistently uses macro is (instead of hard-coded directory
     names).
[x]: Package is named using only allowed ASCII characters.
[x]: Package is named according to the Package Naming Guidelines.
[x]: No %config files under /usr.
[x]: Package does not generate any conflict.
     Note: Package contains no Conflicts: tag(s)
[-]: Package do not use a name that already exist
[x]: Package obeys FHS, except libexecdir and /usr/target.
[x]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: Package installs properly.
[x]: Package is not relocatable.
[x]: Requires correct, justified where necessary.
[x]: CheckResultdir
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file is legible and written in American English.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: Package contains systemd file(s) if in need.
[x]: File names are valid UTF-8.
[x]: Useful -debuginfo package or justification otherwise.
[!]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 1433600 bytes in 10 files.
pwouters: OK, its release notes and changelogs.
[x]: Packages must not store files under /srv, /opt or /usr/local
===== SHOULD items =====

Generic:
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Dist tag is present.
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[-]: Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: The placement of pkgconfig(.pc) files are correct.
[x]: Scriptlets must be sane, if used.
[x]: SourceX tarball generation or download is documented.
[x]: SourceX / PatchY prefixed with %{name}.
[x]: SourceX is a working URL.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[x]: Spec use %global instead of %define.

===== EXTRA items =====
Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
     Note: Arch-ed rpms have a total of 5877760 bytes in /usr/share 5877760
     tor-0.2.3.25-1929.fc18.x86_64.rpm

pwouters: is ok, caused by large changelog/release notes files.

Rpmlint
-------
Checking: tor-0.2.3.25-1929.fc18.x86_64.rpm
          tor-debuginfo-0.2.3.25-1929.fc18.x86_64.rpm
          tor-0.2.3.25-1929.fc18.src.rpm
tor.x86_64: W: spelling-error Summary(en_US) Anonymizing -> Anatomizing, Canonizing, Anodizing
tor.x86_64: W: only-non-binary-in-usr-lib
tor.x86_64: W: non-standard-uid /var/log/tor toranon
tor.x86_64: W: non-standard-gid /var/log/tor toranon
tor.x86_64: E: non-standard-dir-perm /var/log/tor 0750L
tor.x86_64: W: non-standard-uid /var/lib/tor toranon
tor.x86_64: W: non-standard-gid /var/lib/tor toranon
tor.x86_64: E: non-standard-dir-perm /var/lib/tor 0700L

pwouters: I do think /var/lib/tor should be 0750

tor.src: W: spelling-error Summary(en_US) Anonymizing -> Anatomizing, Canonizing, Anodizing
3 packages and 0 specfiles checked; 2 errors, 7 warnings.

Rpmlint (installed packages)
----------------------------
# rpmlint tor tor-debuginfo
tor.x86_64: W: spelling-error Summary(en_US) Anonymizing -> Anatomizing, Canonizing, Anodizing
tor.x86_64: W: only-non-binary-in-usr-lib
tor.x86_64: W: non-standard-uid /var/log/tor toranon
tor.x86_64: W: non-standard-gid /var/log/tor toranon
tor.x86_64: E: non-standard-dir-perm /var/log/tor 0750L
tor.x86_64: W: non-standard-uid /var/lib/tor toranon
tor.x86_64: W: non-standard-gid /var/lib/tor toranon
tor.x86_64: E: non-standard-dir-perm /var/lib/tor 0700L
2 packages and 0 specfiles checked; 2 errors, 6 warnings.
# echo 'rpmlint-done:'



Requires
--------
tor-0.2.3.25-1929.fc18.x86_64.rpm (rpmlib, GLIBC filtered):

    /bin/sh
    config(tor) = 0.2.3.25-1929.fc18
    libc.so.6()(64bit)
    libcrypto.so.10()(64bit)
    libcrypto.so.10(OPENSSL_1.0.1)(64bit)
    libcrypto.so.10(libcrypto.so.10)(64bit)
    libdl.so.2()(64bit)
    libevent-2.0.so.5()(64bit)
    libm.so.6()(64bit)
    libpthread.so.0()(64bit)
    librt.so.1()(64bit)
    libssl.so.10()(64bit)
    libssl.so.10(libssl.so.10)(64bit)
    libz.so.1()(64bit)
    rtld(GNU_HASH)
    shadow-utils
    systemd
    torsocks

tor-debuginfo-0.2.3.25-1929.fc18.x86_64.rpm (rpmlib, GLIBC filtered):



Provides
--------
tor-0.2.3.25-1929.fc18.x86_64.rpm:

    config(tor) = 0.2.3.25-1929.fc18
    tor = 0.2.3.25-1929.fc18
    tor(x86-64) = 0.2.3.25-1929.fc18
    tor-core = 0:0.2.3.25-1929.fc18
    tor-systemd = 0:0.2.3.25-1929.fc18
    torify = 0:0.2.3.25-1929.fc18

tor-debuginfo-0.2.3.25-1929.fc18.x86_64.rpm:

    tor-debuginfo = 0.2.3.25-1929.fc18
    tor-debuginfo(x86-64) = 0.2.3.25-1929.fc18

MD5-sum check
-------------
Using local file /home/paul/fedora/tor/tor.logrotate as upstream
file:///home/paul/fedora/tor/tor.logrotate :
  CHECKSUM(SHA256) this package     : 0d45f7a0fecc1fa0b11438e82cbaeaece766c5d72ae26aed36d4558d5ac3a650
  CHECKSUM(SHA256) upstream package : 0d45f7a0fecc1fa0b11438e82cbaeaece766c5d72ae26aed36d4558d5ac3a650
Using local file /home/paul/fedora/tor/tor.defaults-torrc as upstream
file:///home/paul/fedora/tor/tor.defaults-torrc :
  CHECKSUM(SHA256) this package     : bec4638642961432a978e1e0d5cf10a26b4dca076a2e6f55a5c4ae5830643eb2
  CHECKSUM(SHA256) upstream package : bec4638642961432a978e1e0d5cf10a26b4dca076a2e6f55a5c4ae5830643eb2
https://www.torproject.org/dist/tor-0.2.3.25.tar.gz :
  CHECKSUM(SHA256) this package     : bb2d6f1136f33e11d37e6e34184143bf191e59501613daf33ae3d6f78f3176a0
  CHECKSUM(SHA256) upstream package : bb2d6f1136f33e11d37e6e34184143bf191e59501613daf33ae3d6f78f3176a0
https://www.torproject.org/dist/tor-0.2.3.25.tar.gz.asc :
  CHECKSUM(SHA256) this package     : e48fb60547eca4c9b40e2d43802f8ddd9d17502432428122607cad7174f4327c
  CHECKSUM(SHA256) upstream package : e48fb60547eca4c9b40e2d43802f8ddd9d17502432428122607cad7174f4327c
Using local file /home/paul/fedora/tor/tor.systemd.service as upstream
file:///home/paul/fedora/tor/tor.systemd.service :
  CHECKSUM(SHA256) this package     : 9251be4fd8b325656cc70f501e69f9ab94637f8d1cfeae3f2efac7388cd4e5ff
  CHECKSUM(SHA256) upstream package : 9251be4fd8b325656cc70f501e69f9ab94637f8d1cfeae3f2efac7388cd4e5ff


Generated by fedora-review 0.3.1 (b71abc1) last change: 2012-10-16
Buildroot used: fedora-18-x86_64
Command line :/usr/bin/fedora-review -rn tor-0.2.3.25-1929.fc19.src.rpm

Comment 11 Jamie Nguyen 2013-03-08 07:01:16 UTC
Thanks for the re-review Paul!

> I'm confused why /var/log/tor is group-readable but /var/lib/tor is
> not. I assume we either trust the group, or not. I'd say enable group
> read for /var/lib/tor. That way a user can add themselves to the group
> and look at what /  how tor is doing without needing root or sudo to the
> toranon user. Or change /var/log/tor to be user/root only.
> (waiting on answer of upstream)

I changed /var/lib/tor to 0750 to match /var/log/tor, but then at runtime tor "fixes" the permissions of /var/lib/tor back to 0700. So instead now both /var/log/tor and /var/lib/tor are 0700.

I think at this stage I'm quite happy with the amount of re-review that has been done for this package with at least 5 sets of eyes having looking through it. Thanks everyone! If there are any other comments/criticisms then please do speak up.

Comment 12 Fedora Update System 2013-03-16 01:38:52 UTC
tor-0.2.3.25-1802.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.