[Tor-BSD] Patched versions of the FreeBSD ports "security/tor" and "security/tor-devel"

[Fabian Keil]

Vinícius Zavam <egypcio at googlemail.com> wrote:

> 2015-12-22 14:26 GMT-03:00, Fabian Keil <freebsd-listen at fabiankeil.de>:
> > Vinícius Zavam <egypcio at googlemail.com> wrote:
> >  
> >> 2015-11-17 15:31 GMT-03:00, N.J. Thomas <njt at ayvali.org>:  
> >> > * Vin??cius Zavam <egypcio at googlemail.com> [2015-11-17 14:10:53-0300]:
> >> >  
> >> >> > If you are using FreeBSD to run a Tor Relay, it would be sweet to
> >> >> > get
> >> >> > more
> >> >> > feedbacks about the patches I reported to the FreeBSD Bugzilla  
> >> >>
> >> >> I just changed a bit the patches; please check if everything still
> >> >> works for you and ping me back if needed.  
> >> >
> >> > Just applied your second set of patches and I'm up and running on a
> >> > FreeBSD 10.2-p7 amd64 box.
> >> >
> >> > Will let you know if I run into problems.  
> >  
> >> Yesterday a "bump" just hit the FreeBSD's ports tree to update
> >> security/tor-devel; today it was security/tor's turn. Both were
> >> updated because of "maintainer's timeout".
> >>
> >> IMHO, all work done in PR 203014 (that started this thread) was just
> >> left behind. You can take a look at
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205252 and see I
> >> wrote some considerations and asked for feedback about it. "203014"
> >> was/is also updated to provide tor-2.7.6 (stable/lastest release).
> >>
> >> I also would like to 'hear' opinions and feedbacks from you guys.  
> >
> > It's not uncommon for a committer to close one PR without
> > being aware of related PRs.
> >  
> >> PS: should it be forwarded/cc to freebsd-ports@? write on bugzilla is
> >> not enough?  
> >
> > The patch you submitted in 203014 was already rejected by the maintainer
> > so forwarding the PR without responding to the objection is unlikely to
> > help:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203014#c23  
> 
> I just did not see the status update rejecting it. That's why I got "confused".
> 
> > It's not obvious to me if Brendan objects to the whole tor_prestart(),
> > or just the first part (which I don't like either), but you could
> > request a clarification and update the patch accordingly.  
> 
> The main considerations bf@ wrote about the patch regards some topics
> we discussed here (backing up old log files/contents). Correct me if I
> am wrong, but you was one of the guys sugesting that the rc script
> should handle logs/keys/backups.

I was one of the guys who suggested that the rc script should
automatically create the directories required to run tor. In your patch:
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163356&action=diff
this is done between line 71 and 82.

By "first part of tor_prestart()" I was referring to lines 56 to 68.

The code looks fragile and racy to me, it's not obvious to me that it's
useful and I don't think it should be done by default and without an option
to disable it.

When I wrote (Message-ID: <20151118160118.22e032b9 at fabiankeil.de>):

| I don't consider backing up relay keys a MUST. Having said that,
| I would not mind if the port would make this (and thus migrating
| relays) more convenient.

I was thinking about additional rc script commands (like backup and restore)
that would tar/untar the essential files to run the relay. I don't consider
the log files essential and don't think they should be included in the backup
by default.

> > If a ports PR with a patch gets ignored for more than 14 days you can
> > request a maintainer timeout on freebsd-ports@, but once the maintainer
> > responds by rejecting a patch it's too late (for the rejected patch).

> One more question: what about the other updates and changes? // old
> patch removal from "files/" directory, new transport option, use of
> openssl from ports to FreeBSD 9.x, options helpers, ...

What about them? If you put them in a new patch that does not contain
parts that have already been rejected, the maintainer might approve
(or reject) it and if you don't get a response in time you could
request a maintainer timeout again.

If I were the maintainer, I'd probably reject the new transport option,
but the rest of the changes you list look like uncontroversial improvements
to me.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20151223/8ab4a0ad/attachment.bin>