Compiling Tor with bufferevents enabled causes issues [1]. Furthermore, the options: * tor2web breaks functionality * instrument-downloads is no longer supported in 0.2.9 [2] [1] https://trac.torproject.org/projects/tor/ticket/7734 [2] https://trac.torproject.org/projects/tor/ticket/19035
BTW, instrument-downloads essentially does nothing useful.
These changes were suggested by the Tor upstream.
Created attachment 171578 [details] Proposed patch
Maintainer reset.
CC new maintainer
OP, are you sure this is FreeBSD port problem, and not an upstream problem?
These options will no longer be available in next releases of Tor. Furthermore, setting these options on previous versions of Tor breaks functionalities or causes issues. See my first comment for more information. The patch I have submitted proposes to make the port Makefile coherent with the Tor compilation options.
U+039b, bufferevents option: From reading tor bug#7734 I see that the "ease of turning it on FreeBSD" is a problem. It seems to me it is broken upstream. Am I making a wrong conclusion? Yuri
Yuri, It's broken upstream in the stable release because the option exists. The next upstream release fixes it by removing the option and code. U+039b
We will disable instrument-downloads when the release where it is disabled comes to port.
Ok, so we will remove both options when upstream release doesn't contain them any more. FreeBSD ports only reflect upstream options, we don't modify them.
amdmi3@FreeBSD.org, You should assign to maintainer, not CC to him. This bug should be rejected.
(In reply to yuri from comment #12) > You should assign to maintainer, not CC to him. PRs are not assigned to non-committers. > FreeBSD ports only reflect upstream options, we don't modify them. > This bug should be rejected. Broken and useless options should not be reflected in ports. Not sure for other options, but upstream cleanly states that bufferevents is broken, so at least it should be removed right away. Regarding other options, I agree that the fact the option is going to be removed in the next release is not a good reason to remove it now. If there's more evidence other options are broken, they could be removed too.
(In reply to Dmitry Marakasov from comment #13) > PRs are not assigned to non-committers. FYI: System automatically assigns bugs to port maintainers, committers or not.
(In reply to Dmitry Marakasov from comment #13) > Broken and useless options should not be reflected in ports. Not sure for other options, but upstream cleanly states that bufferevents is broken, so at least it should be removed right away. bufferevents has been known to be broken for 4 years. There were many Tor releases during this time, obviously Tor team didn't consider the brokenness of bufferevents important enough to remove it, and kept moving the deadline instead. And the instrumentation option is just a stray, unused option that somebody happened to notice. I don't see where the sudden urgency for FreeBSD port is coming from.
(In reply to yuri from comment #15) > bufferevents has been known to be broken for 4 years. There were many Tor > releases during this time, obviously Tor team didn't consider the brokenness > of bufferevents important enough to remove it, and kept moving the deadline > instead. And the instrumentation option is just a stray, unused option that > somebody happened to notice. So these really need to be removed. What's with tor2web?
A commit references this bug: Author: amdmi3 Date: Wed Sep 7 11:46:02 UTC 2016 New revision: 421493 URL: https://svnweb.freebsd.org/changeset/ports/421493 Log: - Update to 0.2.8.7 [1] - Remove broken BUFFEREVENTS and INSTR_DOWNLOADS options [2] - Switch to USES=ssl PR: 212124 [1], 210389 [2] Submitted by: neel@neelc.org [1], U+039b@0x39b.fr [2] Approved by: yuri@rawbw.com (maintainer) Changes: head/security/tor/Makefile head/security/tor/distinfo
A commit references this bug: Author: amdmi3 Date: Wed Sep 7 11:46:54 UTC 2016 New revision: 421494 URL: https://svnweb.freebsd.org/changeset/ports/421494 Log: - Update to 0.2.9.2-alpha [1] - Remove unsupported BUFFEREVENTS and INSTR_DOWNLOADS options [2] - Switch to USES=ssl PR: 212124 [1], 210389 [2] Submitted by: neel@neelc.org [1], U+039b@0x39b.fr [2] Approved by: yuri@rawbw.com (maintainer) Changes: head/security/tor-devel/Makefile head/security/tor-devel/distinfo
bufferevents and instr_downloads removed. U+039b, could you please clarify how exactly "tor2web breaks functionality"?
Hi, I'm Sebastian from upstream. U+039b has been kind enough to bring this to my attention. There are very few systems in the world that want to set the tor2web mode, and it completely removes all client functionality from a Tor instance compiled that way - you cannot use it for regular traffic, only for non-anonymous hidden service traffic. The description provided to users is "Faster but non-anonymous hidden services", which to me is a big oversimplification of the ramifications of setting that option. Additionally, we don't test the option so it is liable to break frequently, as tor2web usage styles aren't a big priority for us. We intentionally hid the functionality behind a configure switch and additionally require users to set the tor2web mode torrc option so that people will not accidentally enable this mode. When compiled with the tor2web configure switch, Tor will refuse to run without the tor2web torrc option also included. I hope this helps convince you that this really shouldn't be an option the Tor port offers all its users without at least a lot more scary warnings.
So tor2web doesn't really break functionality, instead it is an expert option that should just not be chosen lightly. The corresponding warning should be added.
I added the tor2web warning message in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212529
Seems like all issues were resolved.