[Tor-BSD] Patched versions of the FreeBSD ports "security/tor" and "security/tor-devel"
george at ceetonetechnology.com
Wed Dec 23 09:09:07 EST 2015
> 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
>>>>>>> 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
>> 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:
> 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.
At this point I think creating the logfile with the correct
permissioning in the FreeBSD port is critical, if it hasn't been done
Not creating or designating syslog in the port means Tor doesn't start
without manual configuration, and is therefore broken IMHO.
OpenBSD dumps to syslog or /var/log/tor/notices.log by default, and I
don't believe it has to be configured manually.
I could be wrong... it's been a while since I did new installs of Tor on
either, and can't check right now.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the Tor-BSD