Created attachment 367046 [details]
combined patches for tor

bumped severity because it is important that the anonimity issues gets resolved, and I haven't heard anything from the package maintainer yet.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

tor-0.2.1.20-1200.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/tor-0.2.1.20-1200.fc12

tor-0.2.1.20-1100.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/tor-0.2.1.20-1100.fc11

> fedora rpm refers to old tor.eff.org url

thanks; fixed


> fedora rpm doesn't set ulimit -n, so you can't run a fast relay
> (this bug is not yet fixed. I need to look into how to do this in a
> way that's compatible with before. Probably a /etc/sysconfig/tor
> file)

I increased limit to 4096 in the upstart script; LSB users have to do
it in /etc/sysconfig/tor as described by you


> fedora rpm fabricates its own geoip file?

it made it easy to use actual geoip data; by default the shipped data
are used.  I thought it would be a good idea to allow updating of such
very dynamic stuff instead of using information which are shipped
every 6-9 months by a new tor release.

But due to your concern I removed the related code.


> fedora rpm doesn't log by default?

WONTFIX:

* Sun Dec 17 2006 Enrico Scholz <enrico.scholz.de> - 0.1.1.26-1
- do not turn on logging by default; it's easier to say "we do not log
  anything" to the police instead of enumerating the logged event
  classes and trying to explain that they do not contain any valuable
  information


> Fedora init scripts kill all tor processes

thanks; I added '-p <pidfile>' at the missing places


> Output in %post violates Fedora Packaging guidelines

WONTFIX; The alternative would be something like '%postun() script
failed'. RH/Fedora should fix its core utils before it can expect to
follow such guidelines.


> Typo in initng script preventing daemon to work properly

thx; fixed


> tor 0.2.1.20 fixes the gcc warning. removed patch.
> Added --enable-gcc-warnings to configure flags

there are new warnings breaking -Werror

| crypto.c: In function 'crypto_pk_write_key_to_string_impl':
| crypto.c:535: error: comparison of unsigned expression >= 0 is always true


> Removed old copy of kernel include netfilter-ipv4.h which was not used

thanks; fixed


> Fixed init scripts to use Fedora Guideline Package version which
> prevents trying to execute non-existing files in /usr/lib/lsb/

???

tor-0.2.1.20-1200.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tor'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12002

Thanks for applying the fixes.

I'll look at the fixes and the new tor version. And supply a patch for the default init scripts and ulimits. I understand your logging reasons.

I think the continued package violation of the %post output is very childish - if you want to address this bug, the mailinglist is a much better place to have this discussion then to burden the tor users with some flamebait.

Please adjust the package to follow the guidelines for sysvinit scripts? 

https://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscript_packaging

Please don't use optional lsb commands, but the scriptlets listed above? 
This was discussed at todays FESCo meeting, and we would really like you to follow the guidelines...

Enrico: Can you please switch the package to use the standard scriptlets? 

Or if you like I can go ahead and make that change.

changing the scripts is not trivial and I am busy with more important tasks than to fix something which is not broken.

I will add the proprietary RH initscripts for F-14 but can not tell when I have time to implement them.

Thanks. 

Would you consider pushing this to other releases as the need for updates there happens?

As I said, converting LSB initscripts to RH ones is not a trivial task and might introduce regressions.  Because there are no issues with the LSB initscripts (except that they do not follow guidelines), I am not planning such a change.

I think perhaps you misunderstood. It's not that the scripts have LSB headers and so forth, which are optional by the guidelines as long as chkconfig can grok them. 

It's that you should not use chkconfig in your scriptlets to install/setup the init scripts, not remove_initd and install_initrd. You should use the scriptlets as stated in "Initscripts in spec file scriptlets" on the above link. 

This would remove the silly dep on redhat-lsb and make this package act/look like all the other packages in Fedora.

I do not understand why this is so urgent. Converting LSB initscripts to RH ones is not a trivial task and might introduce regressions.  Because there are no issues with the LSB initscripts (except that they do not follow guidelines), I am not planning such a change before F14.

So here's what fesco talked about:

Enrico - would you be cool w/someone from the provenpackager group taking a look at backporting the changes Kevin Fenzi was talking about for F11/F12?

I do not understand why this is so urgent. Initscripts must be rewritten which  is not a trivial task and might introduce regressions.  Because there are
no issues with the LSB initscripts (except that they do not follow guidelines),
I am not planning such a change before F14.

Yeah, I don't think this is any kind of critical urgency, but I do think it would be nice to fix in stable releases too:

1) people who newly install tor there will not have to deal with the redhat_lsb dependency nightmare. 
2) the package will look and behave much more like all the other packages in the collection. 

This is why I suggested pushing this change when there is some reason to update the stable releases next.

(In reply to comment #6)
> > fedora rpm refers to old tor.eff.org url
> 
> thanks; fixed

Actually, one instance of tor.eff.org remains. You should probably clean
that one up too.

> > fedora rpm doesn't set ulimit -n, so you can't run a fast relay
> > (this bug is not yet fixed. I need to look into how to do this in a
> > way that's compatible with before. Probably a /etc/sysconfig/tor
> > file)
> 
> I increased limit to 4096 in the upstart script; LSB users have to do
> it in /etc/sysconfig/tor as described by you

Fast Tor exit relays will easily exceed 4096 file descriptors. The debian
init script has a short shell script to decide how many to use:

if [ -r /proc/sys/fs/file-max ]; then
        system_max=`cat /proc/sys/fs/file-max`
        if [ "$system_max" -gt "80000" ] ; then
                MAX_FILEDESCRIPTORS=32768
        elif [ "$system_max" -gt "40000" ] ; then
                MAX_FILEDESCRIPTORS=16384
        elif [ "$system_max" -gt "10000" ] ; then
                MAX_FILEDESCRIPTORS=8192
        else
                MAX_FILEDESCRIPTORS=1024
                cat << EOF

> > fedora rpm fabricates its own geoip file?
> 
> it made it easy to use actual geoip data; by default the shipped data
> are used.  I thought it would be a good idea to allow updating of such
> very dynamic stuff instead of using information which are shipped
> every 6-9 months by a new tor release.
> 
> But due to your concern I removed the related code.

Great, thanks!

> > fedora rpm doesn't log by default?
> 
> WONTFIX:
> 
> * Sun Dec 17 2006 Enrico Scholz <enrico.scholz.de> -
> 0.1.1.26-1
> - do not turn on logging by default; it's easier to say "we do not log
>   anything" to the police instead of enumerating the logged event
>   classes and trying to explain that they do not contain any valuable
>   information

This part isn't cool. Why are you making different security decisions than
upstream?

We make sure that nothing logged at severity notice or higher is dangerous.
The logs are actually really useful for people when something is going wrong --
for example, many people try to run Tor relays or clients with a wrong clock,
and they need to know that it's not working.

Thanks,
--Roger (Tor upstream)

(In reply to comment #17)
> I do not understand why this is so urgent. Initscripts must be rewritten which 
> is not a trivial task and might introduce regressions.  Because there are
> no issues with the LSB initscripts (except that they do not follow guidelines),
> I am not planning such a change before F14.    

We would really like to see a F13 update as well, as we don't want new F13 users to get the large lsb dep and scriptlet output. Can you please do a F13 update? 

Thanks.

In fact, both upstream and I had perfectly fine working init scripts for tor that we can use. This is not rocket science that needs to wait until F-14.

Similarly, it takes 3 seconds to remove the cruft in %post. I've spend hours on this in total every 3 months when someone else reports this on the list, everyone agrees, and nothing happens.

FWIW: I'll note that now both f13/devel have the stupid output removed (as of yesterday).

yes; redhat-lsb/chkconfig have been fixed...

I'll close this now, though the filedescripts and ulimit issues are probably still there.