Re: [tor-bugs] #24758 [Community/Outreach]: Wikipedia blocks edits from non-exit relays?

[Tor Bug Tracker & Wiki]

#24758: Wikipedia blocks edits from non-exit relays?
+
 Reporter:  arma|  Owner:  alison
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arma):

 * status:  reopened => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24758 [Community/Outreach]: Wikipedia blocks edits from non-exit relays?

[Tor Bug Tracker & Wiki]

#24758: Wikipedia blocks edits from non-exit relays?
+--
 Reporter:  arma|  Owner:  alison
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arma):

 * status:  closed => reopened
 * resolution:  invalid =>


Comment:

 Please don't close my ticket.

 I still think we should gather the data about how many non-exit relays are
 on wikipedia's blacklist, and if it's a lot, we should find out why, for
 those addresses in particular.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24759 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall socket)

[Tor Bug Tracker & Wiki]

#24759: (Sandbox) Caught a bad syscall attempt (syscall socket)
--+--
 Reporter:  mig5  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal|   Keywords:  sandbox
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Hi,

 With the following torrc I experience the subsequent trace:

 {{{
 Sandbox 1
 DataDirectory /tmp/tmp2z5k8mqz
 SocksPort 32609
 ControlSocket /tmp/tmp2z5k8mqz/control_socket
 CookieAuthentication 1
 CookieAuthFile /tmp/tmp2z5k8mqz/cookie
 AvoidDiskWrites 1
 Log notice stdout
 GeoIPFile /usr/share/tor/geoip
 GeoIPv6File /usr/share/tor/geoip6
 }}}

 {{{
 [user@host tmp2z5k8mqz]$ tor -f torrc
 Dec 29 10:24:05.125 [notice] Tor 0.3.1.9 (git-727d3f1b5e6eeda7) running on
 Linux with Libevent 2.0.22-stable, OpenSSL 1.1.0g-fips, Zlib 1.2.11,
 Liblzma N/A, and Libzstd N/A.
 Dec 29 10:24:05.125 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Dec 29 10:24:05.125 [notice] Read configuration file
 "/tmp/tmp2z5k8mqz/torrc".
 Dec 29 10:24:05.128 [notice] Opening Socks listener on 127.0.0.1:32609
 Dec 29 10:24:05.128 [notice] Opening Control listener on
 /tmp/tmp2z5k8mqz/control_socket
 Dec 29 10:24:05.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
 Dec 29 10:24:05.000 [notice] Parsing GEOIP IPv6 file
 /usr/share/tor/geoip6.
 Dec 29 10:24:05.000 [notice] Bootstrapped 0%: Starting
 Dec 29 10:24:06.000 [notice] Starting with guard context "default"
 Dec 29 10:24:06.000 [notice] Bootstrapped 5%: Connecting to directory
 server

  T= 1514503447
 (Sandbox) Caught a bad syscall attempt (syscall socket)
 tor(+0x1853fa)[0x56068ff303fa]
 /lib64/libc.so.6(socket+0x7)[0x7893d9664fb7]
 /lib64/libc.so.6(socket+0x7)[0x7893d9664fb7]
 /lib64/libc.so.6(+0x12e3fa)[0x7893d96813fa]
 /lib64/libc.so.6(+0x12e4f1)[0x7893d96814f1]
 /lib64/libc.so.6(getifaddrs+0x10)[0x7893d9682230]
 tor(get_interface_addresses_raw+0x3c)[0x56068ff13eec]
 tor(get_interface_address6_list+0x30)[0x56068ff14620]
 tor(get_interface_address6+0x45)[0x56068ff14875]
 tor(+0x109378)[0x56068feb4378]
 tor(connection_handle_write+0x2e)[0x56068feb44ae]
 tor(+0x4d5ce)[0x56068fdf85ce]
 /lib64/libevent-2.0.so.5(event_base_loop+0x7a9)[0x7893da6943f9]
 tor(do_main_loop+0x29d)[0x56068fdf978d]
 tor(tor_main+0xe25)[0x56068fdfc5a5]
 tor(main+0x19)[0x56068fdf5009]
 /lib64/libc.so.6(__libc_start_main+0xea)[0x7893d957388a]
 tor(_start+0x2a)[0x56068fdf505a]
 }}}

 It of course works with Sandbox 0.

 Is there something in my config that is incompatible with the Sandbox
 mode?

 Maybe related to 16579 except syslog is not the issue here.

 Thanks!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #9390 [Core Tor/Tor]: Warn if you're being a public relay but have too-low file descriptor limit

[Tor Bug Tracker & Wiki]

#9390: Warn if you're being a public relay but have too-low file descriptor 
limit
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay easy dos resources |  Actual Points:
  logging|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Please make a separate branch that only has the changes for this ticket on
 it,
 Please run "make check" on this branch before submitting it, and fix any
 errors.
 In particular, this branch does not pass "make check-spaces".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23946 [Applications/Tor Browser]: Tor Browser no longer shows the warning when maximizing the window in Ubuntu 17.10

[Tor Bug Tracker & Wiki]

#23946: Tor Browser no longer shows the warning when maximizing the window in
Ubuntu 17.10
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by vondjik):

 * status:  closed => reopened
 * resolution:  not a bug =>


Comment:

 Actually, at least for me, this seems to happen after a couple days of
 usage of a new fresh clean Tor Browser install. Is that expected or not?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24758 [Community/Outreach]: Wikipedia blocks edits from non-exit relays?

[Tor Bug Tracker & Wiki]

#24758: Wikipedia blocks edits from non-exit relays?
+-
 Reporter:  arma|  Owner:  alison
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:  invalid
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by vondjik):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 > It looks like just clicking on the 'edit' link on a random page is
 enough to tell?

 Yes (ignoring the tiny amount of IPv6 non-exits where it may work), but
 the other rule you miss: Edits from IPs from hosting providers are
 forbidden according to Jimbo's Pedia:

 {{{
 The IP address that you are currently using has been blocked because
 it is believed to be a web host provider. To prevent abuse, web hosts
 may be blocked from editing Wikipedia.
 }}}

 I may use some harsh words but I'd say just drop the entire thing with
 Wikipedia, they don't want to collaborate and they are actively cracking
 down on anything remotely associated with a proxy or hosting provider.
 Their foundation also asks far far money than they need to operate WP
 (search for a thread on that in news.ycombinator.com):

 > Dear Readers: We like money. We like money so much that we won't run
 advertisements, and would rather ask you in person to give us money. We,
 with open hearts, ask you to give us $15 for content generated for free
 (most of the time, those PR agents work extra around the holiday season!)
 from user input. Well, not YOUR user input, since you won't survive in an
 account for 15 minutes before one of our generous admins bans you from
 editing because you use Tor.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24757 [Community/Outreach]: collect blog posts (or tor-relays posts) from happy relay operators

[Tor Bug Tracker & Wiki]

#24757: collect blog posts (or tor-relays posts) from happy relay operators
+
 Reporter:  arma|  Owner:  alison
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 A todo item that came out of the 34c3 relay operators meetup: we should
 have a series of relay operators do blog posts (or just tor-relays posts)
 sharing happy stories. Right now the tiny minority of relay operators with
 sad stories is what everybody notices and thinks of, since they draw
 attention and since there aren't many counterexamples.

 We will want to think through what to focus on in these more happy stories
 -- historically the sad ones have all sorts of gory details, and the happy
 ones are one or two sentences ("I've run these four huge exit relays for
 the past three years and I only got one phone call"). My first thought is
 to leave that choice to the relay operators who are writing them -- they
 clearly are in this for a good reason, and this is their chance to explain
 it to the world, and to argue that running an exit is worth the trouble.

 We will also want to figure out some way to collect and keep them, so they
 don't just become old mailing lists posts or old blog posts lost in the
 wind. A trac page pointing to all of them? A twitter hashtag? Something
 else smart?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24758 [Community/Outreach]: Wikipedia blocks edits from non-exit relays?

[Tor Bug Tracker & Wiki]

#24758: Wikipedia blocks edits from non-exit relays?
+
 Reporter:  arma|  Owner:  alison
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 We heard a report in the 34c3 relay operator meetup that wikipedia is
 blocking edits from non-exit relays. If this is so, it's clearly an
 unnecessary step on their part -- and the wikipedia people in the room
 declared that they would want to fix it.

 One theory was that these non-exit relays had been exit relays for a
 little while in the distant past, and that was enough to get on a multi-
 year wikipedia blacklist.

 One way to move forward would be to gather anecdotal data from more non-
 exit relay operators. It looks like just clicking on the 'edit' link on a
 random page is enough to tell?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24756 [Applications/Tor Browser]: New default bridge: bridge-01.noisetor.net

[Tor Bug Tracker & Wiki]

#24756: New default bridge: bridge-01.noisetor.net
--+--
 Reporter:  patrickod |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-bridges   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by patrickod):

 Associated pull request to add bridge to OONI reachability test set -
 https://github.com/OpenObservatory/ooni-resources/pull/10

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24756 [Applications/Tor Browser]: New default bridge: bridge-01.noisetor.net

[Tor Bug Tracker & Wiki]

#24756: New default bridge: bridge-01.noisetor.net
--+--
 Reporter:  patrickod |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-bridges   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by patrickod):

 Derp that's meant to be 125MBit/sec.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24756 [Applications/Tor Browser]: New default bridge: bridge-01.noisetor.net

[Tor Bug Tracker & Wiki]

#24756: New default bridge: bridge-01.noisetor.net
--+-
 Reporter:  patrickod |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-bridges
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Capable of relaying 125MiB/sec at the moment with the option for expansion
 should it be utilized. Committed to at least 12 months of operation funded
 by Noisetor[0]

 `Bridge obfs4 216.252.162.21:46089
 0DB8799466902192B6C7576D58D4F7F714EC87C1
 cert=XPUwcQPxEXExHfJYX58gZXN7mYpos7VNAHbkgERNFg+FCVNzuYo1Wp+uMscl3aR9hO2DRQ
 iat-mode=0`

 [0] - http://tor.noisebridge.net

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24755 [Applications/Tor Browser]: Shell scripts refactoring and bash privacy leak. Heredoc should not be used in start-tor-browser script.

[Tor Bug Tracker & Wiki]

#24755: Shell scripts refactoring and bash privacy leak. Heredoc should not be 
used
in start-tor-browser script.
--+--
 Reporter:  asan  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In most of shells (including bash) heredoc, i.e. `<<` and `<<<`, is
 implemented through creation of temporary files in TMP. In the case of
 bash these are the files like `/tmp/sh-thd-1234567890`. This can be
 checked using the command [[https://unix.stackexchange.com/questions/21602
 /shell-programming-avoiding-tempfiles|[1]]]
 {{{
 sleep 3 <<<"here string" & lsof -p $! | grep 0r
 }}}
 Furthermore, these TMP files may remain if, e.g., shell script crashes.
 There were some complaints that these files are still accessible through
 file descriptors even after removal [[http://gnu-bash.2382.n7.nabble.com
 /bash-leaks-sh-np-NNN-files-and-pipes-in-tmp-when-command-substitution-is-
 used-td12719.html|[2]]],
 [[https://groups.google.com/forum/#!topic/gnu.bash.bug/qMjhPmg4OBw|[3]]].

 Since TBB and similar applications are intended to be portable, they
 should not leave traces outside of their portable directory. However, bash
 commands in scripts like `start-tor-browser` may run when separate TMP for
 TBB is not yet set, i.e. system TMP (/tmp), which is not always mounted in
 memory, may be used. It means that traces (that TBB was used) will be
 created outside of TBB directory. This is a minor leak in comparison to en
 elephant [[https://trac.torproject.org/projects/tor/ticket/7449|7449]]
 (yet unfixed), but it is still a leak.

 In general, if TMP for TBB is created before the use of heredoc command in
 script, it should be fine. However, as heredoc is potentially leaky and
 dangerous thing, it should be avoided in secure scripts. One could use
 simple `echo` command instead.

 Now `start-tor-browser` has at least one `cat 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #9390 [Core Tor/Tor]: Warn if you're being a public relay but have too-low file descriptor limit

[Tor Bug Tracker & Wiki]

#9390: Warn if you're being a public relay but have too-low file descriptor 
limit
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay easy dos resources |  Actual Points:
  logging|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by aruna1234):

 Hey, I have pushed it to my
 
branch:[https://github.com/ArunaMaurya221B/tor/commit/47b08bab6a548a70f5148e4a91cfaee52bebb391].

 Does this solve the issue?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #7590 [Core Tor/Tor]: [PATCH] New option LocalOutboundBindAddress

[Tor Bug Tracker & Wiki]

#7590: [PATCH] New option LocalOutboundBindAddress
-+-
 Reporter:  ac   |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-hs hs-integration |  Actual Points:
  hs-app-support |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Please revise the patch so it applies to master.
 If that's done early enough, it will go in a review queue before the 0.3.3
 freeze.

 If you don't have time to revise the patch, that's ok, but it might be a
 while before someone gets to it,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #7590 [Core Tor/Tor]: [PATCH] New option LocalOutboundBindAddress

[Tor Bug Tracker & Wiki]

#7590: [PATCH] New option LocalOutboundBindAddress
-+-
 Reporter:  ac   |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-hs hs-integration |  Actual Points:
  hs-app-support |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ac):

 The workarounds are insufficient because:

 1. `iptables`, while fully-functional, requires kernel access that is not
 always available.  (It is not available to me in an actual VM that I rent
 where I do, in fact, run `tor`.)

   I wouldn't be surprised if (e.g.) Windows didn't even have this
 capability exposed to users.

 2. Reconfiguring every single daemon to each individually work around the
 lack of functionality is inadequate and would require patching the code of
 some of those daemons.

   For example, I currently have hidden services `postfix`, `ssh`, and
 `apache`.  Apache runs several CGI type programs, for example the
 configuration interface for `cups`.

   `cups` and `postfix`, by default, grant privileged access to connections
 from IP `localhost`.  So you cannot expose them to tor connections through
 that address, without messing around with them.  `cups` is a reverse proxy
 to a `lighttpd` daemon so you can mess around with the `lighttpd`
 configuratoin file in addition to the `apache` one.  But what about
 `postfix`?  You can probably make it listen on random additional ports or
 addresses, but can you configure it so that it overrides the trust default
 based on its own *listening* address?  Such capability cannot be assumed
 to be present in most software, even if it is possible to do with
 `apache`.

   `ssh` does not grant privileged access to local connections by default,
 but I personally do not want anonymous connections from all-and-sundry
 showing up in output from `w` or in logs as `localhost` when they are
 fundamentally the polar opposite of that.  Again, you cannot hope to
 configure `ssh` to do this based on its own *listening* address or port.
 Even though ssh will listen on any number of addresses or ports, it does
 not let you change how it logs the remote IP conditional on its local
 address (why would it?).

   Even if all those daemons supported the necessary workarounds -- which
 they don't -- I would have to mess with 4 different configuration file
 formats (`lighttpd`, `postfix`, `apache`, `ssh`) trying to get them to
 behave the way I want conditional on something (the listening port) that
 normally isn't a condition of behavior, so it's a giant complicated mess.
 Better to use `iptables`, or patch `tor`.

   Certainly I wouldn't be trying to get the necessary patch into `postfix`
 or `ssh` to work around this, because such a patch would make no sense.
 Unlike this patch, which makes perfect sense and does a completely
 straightforward and sensible thing: sets the bind address on an outgoing
 connection to whatever the user specifies.

 It just makes sense.  You are making a connection, you have an opportunity
 to set the bind address, you give it to the user as a configuration
 option.  Simple, straightforward, sensible, standard practice, no reason
 to think twice.

 There's no reason this can't be done in 2 weeks, or 2 days, or 2 hours.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24754 [Core Tor/Tor]: Remove unnecessary heap allocations in Rust protover implementation.

[Tor Bug Tracker & Wiki]

#24754: Remove unnecessary heap allocations in Rust protover implementation.
--+--
 Reporter:  frewsxcv  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by frewsxcv):

 * status:  new => needs_review


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #24754 [Core Tor/Tor]: Remove unnecessary heap allocations in Rust protover implementation.

[Tor Bug Tracker & Wiki]

#24754: Remove unnecessary heap allocations in Rust protover implementation.
--+
 Reporter:  frewsxcv  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 https://github.com/frewsxcv/tor/compare/frewsxcv-protover-heap?expand=1

 This is my first Tor patch! 🎉

 I was working towards
 https://trac.torproject.org/projects/tor/ticket/24030 and noticed we do
 some unnecessary heap allocations via `collect`.

 Even though this is a small change I'm mostly opening to see what the
 review/merge process is like. Also curious if small patches like this
 should be folded into larger patches as separate commits, or if it's okay
 to open individual tickets for them. If there's anything I'm doing wrong,
 let me know – I've done virtually no open source work outside of GitHub
 and am new to this Trac-based workflow.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #7590 [Core Tor/Tor]: [PATCH] New option LocalOutboundBindAddress

[Tor Bug Tracker & Wiki]

#7590: [PATCH] New option LocalOutboundBindAddress
-+-
 Reporter:  ac   |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-hs hs-integration |  Actual Points:
  hs-app-support |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Sebastian):

 Maybe this has enough working alternatives that we don't need to change
 tor at all?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #7590 [Core Tor/Tor]: [PATCH] New option LocalOutboundBindAddress

[Tor Bug Tracker & Wiki]

#7590: [PATCH] New option LocalOutboundBindAddress
-+-
 Reporter:  ac   |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-hs hs-integration |  Actual Points:
  hs-app-support |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision
 * milestone:  Tor: unspecified => Tor: 0.3.4.x-final


Comment:

 alecmuffett does something similar to this in his hidden service setup, by
 making the *remote* side (web server) listen on a custom local subnet
 address, and then having Tor connect to that address. This workaround
 should not need any changes to Tor, or any iptables rules:

 https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-
 production-onion-server.md

 This patch needs revision, because we added OutboundBindAddressExit and OR
 since it was created.
 If you'd like, we can take a look at this in 0.3.4 (the code freeze for
 0.3.3 is only a few weeks away).

 I can't see any need for a unit test, I'm not sure we have any for the
 other OutboundBindAddress options.
 If we do, it should be a parse test, not a bind test.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs