Re: [tor-bugs] #9683 [Tor]: circuit_unlink_all_from_channel() is a performance bottleneck?
#9683: circuit_unlink_all_from_channel() is a performance bottleneck?
+--
Reporter: arma| Owner:
Type: defect | Status: closed
Priority: major | Milestone: Tor: 0.2.5.x-final
Component: Tor |Version:
Resolution: fixed | Keywords: tor-relay, 024-backport, 025-triaged
Actual Points: | Parent ID:
Points: |
+--
Comment (by arma):
moria1's log is getting bombed with
{{{
Mar 26 02:05:02.940 [notice] List of 0 circuits was as expected.
Mar 26 02:05:02.942 [notice] List of 0 circuits was as expected.
Mar 26 02:05:02.944 [notice] List of 0 circuits was as expected.
Mar 26 02:05:02.946 [notice] List of 0 circuits was as expected.
Mar 26 02:05:02.948 [notice] List of 0 circuits was as expected.
Mar 26 02:05:02.950 [notice] List of 0 circuits was as expected.
Mar 26 02:05:02.952 [notice] List of 0 circuits was as expected.
Mar 26 02:05:02.955 [notice] List of 0 circuits was as expected.
...
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/9683#comment:32
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11315 [Tor]: Invalid write of size 8
#11315: Invalid write of size 8
+
Reporter: arma| Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.5.x-final
Component: Tor |Version:
Keywords: | Actual Points:
Parent ID: | Points:
+
on moria1, running nickm/bug11278, on exit:
{{{
==27246== Invalid write of size 8
==27246==at 0x52C8523: ??? (in /usr/lib/libevent-1.4.so.2.1.3)
==27246==by 0x52C8875: event_del (in /usr/lib/libevent-1.4.so.2.1.3)
==27246==by 0x517C08: tor_event_free (compat_libevent.c:151)
==27246==by 0x517C30: periodic_timer_free (compat_libevent.c:573)
==27246==by 0x42B080: tor_free_all (main.c:2554)
==27246==by 0x42B0C3: tor_cleanup (main.c:2591)
==27246==by 0x4F0CF2: hibernate_begin (hibernate.c:759)
==27246==by 0x42DDC1: process_signal (main.c:2070)
==27246==by 0x52C9343: event_base_loop (in
/usr/lib/libevent-1.4.so.2.1.3)
==27246==by 0x42C1A0: do_main_loop (main.c:2009)
==27246==by 0x42CF24: tor_main (main.c:2882)
==27246==by 0x5EFEC8C: (below main) (libc-start.c:228)
==27246== Address 0xae358e0 is not stack'd, malloc'd or (recently) free'd
}}}
How odd.
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11315
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11297 [BridgeDB]: 'No bridges currently available' if you want IPv6
#11297: 'No bridges currently available' if you want IPv6
--+-
Reporter: mttp | Owner:
Type: defect| Status: new
Priority: normal| Milestone:
Component: BridgeDB |Version:
Resolution:| Keywords:
Actual Points:| Parent ID:
Points:|
--+-
Comment (by isis):
Replying to [comment:1 mttp]:
You mean it looks like this:
[[Image(https://trac.torproject.org/projects/tor/raw-
attachment/ticket/11297/2014-03-26-061323_1073x698_scrot.png)]]
Because this is what I currently get, no matter where I try it from.
I'm not sure if you saw my IRC messages to you, but for posterity's sake:
{{{
22:37 isis ) mttp: i did see, i have not looked into it yet, but if
too many people
are requesting IPv6, then that is not a bug, that is
the correct
behaviour because it doesn't have enough bridges.
22:38 mikeperry ) how does bridgedb know how many users a bridge can
handle?
22:39 mikeperry ) (or when to stop handing it out)
22:40 isis ) it doesn't, it just knows how big IPv4 and IPv6 address
spaces are, and
it divides known bridges into the subhashrings
uniformly per address space
22:41 isis ) then a subhashring is created with the filters
pertaining to the client's
request (e.g. IPv6 + obfs3, etc.), and the client is
mapped to a position
within this second subhashring
22:43 mikeperry ) so requests may be ending up in a subhashing that is
empty in the first place?
22:44 isis ) if there are not bridges in a mapping close enough to
the client in the
second subhashring, or there are not enough bridges in
total for that
set of filters [1] then the client either gets less
bridges than the
normal number handed out... and in the worst case none
at all
22:46 isis ) [1] is a total crap algorithm with hardcoded constants
and no explanation
of why those constants were specifically chosen, nor
why they should be
better than anyone else's favourite integer for
determining the meaning
of not enough bridges
22:46 isis ) i believe the random integer in question was a 5
22:46 isis ) it would be funnier if it were a 4
22:47 isis ) or 42 or 23 or something that didn't make sense on a
programming level
but at least made sense on a geek level
22:47 isis ) mikeperry: did that answer your question? :)
22:50 mikeperry ) heh. I am still confused as to why no bridges would
come back. is it
because there are really less than 5 IPv6 bridges in
total?
22:51 mikeperry ) I am now beginning to doubt the entire hash ring idea
as being a sane one,
for sure. I am not sure if that counts as an answer,
but it does make me
feel bad for you for having to deal with it ;)
22:52oak ) Does that mean that the bridges are distributed
somewhat uniformly over
ipv6 space?
22:52 mikeperry ) it seems like we should not be spreading these things
so thin based on
source IP either, but perhaps by distributor type or
some other property.
22:53 mikeperry ) yeah, that's a big space
22:53 mikeperry ) and also it seems unlikely for it to be common for
censored users to be
able to use an alternate space outside of their region,
where as the
crawlers sure can
22:53oak ) And, unless it is too different from ipv4, subnets of
ipv6 are not
uniformily used
22:54oak ) For instance latam almost solely uses ipv4
22:55oak ) If most of that complaints are coming from a uniform
area, must be that
that area uses ipv6 more than the rest of the world
22:57 isis ) mikeperry: heh, no, there are other hardcoded
constants. somewhere there
is a line in this process of determining which says
only give the amount
of bridges we're supposed to if there are more than 200
in the second
subhashring
22:59 isis ) mikeperry:
https://gitweb.torproject.org/user/isis/bridgedb.git/blob/HEAD:/lib/bridgedb/Dist.py#l41
22:59 isis ) s/200/100/
23:01 isis ) and then the 5:
https://gitweb.torproject.org/user/isis/bridgedb.git/blob/HEAD:/lib/bridgedb/Dist.py#l152
23:02 isis ) oak: yes, the IPv6 bridges should be distributed evenly
over all of IPv6
space. :/
23:04 mikeperry ) that first function still shouldn't cause the bridges
left to be 0 by itself
23:05 isis ) mikeperry: yes, the bridges are assigned to their final
ring in roughly the
Re: [tor-bugs] #11297 [BridgeDB]: 'No bridges currently available' if you want IPv6
#11297: 'No bridges currently available' if you want IPv6 ---+ Reporter: mttp | Owner: isis Type: defect | Status: closed Priority: normal | Milestone: Component: BridgeDB |Version: Resolution: not a bug | Keywords: Actual Points: | Parent ID: Points: | ---+ Changes (by isis): * status: assigned = closed * resolution: = not a bug -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11297#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11297 [BridgeDB]: 'No bridges currently available' if you want IPv6
#11297: 'No bridges currently available' if you want IPv6 --+-- Reporter: mttp | Owner: isis Type: defect| Status: assigned Priority: normal| Milestone: Component: BridgeDB |Version: Resolution:| Keywords: Actual Points:| Parent ID: Points:| --+-- Changes (by isis): * status: new = assigned * owner: = isis -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11297#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11316 [Tor Sysadmin Team]: please make ldap account for yawning
#11316: please make ldap account for yawning
---+-
Reporter: arma | Owner:
Type: task | Status: new
Priority: normal | Milestone:
Component: Tor Sysadmin Team |Version:
Keywords: | Actual Points:
Parent ID: | Points:
---+-
{{{
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Yawning maintains obfsclient, a C++ port of obfsproxy, that we'd like
to put into Tor's git.
First name: Yawning
Last name: Angel
Desired uid: yawning
Forwarding address: yawn...@schwanenlied.me
$ gpg --fingerprint 9EB1A490C73CC5D44DFB3E47BFBD1C7B8A6EC81A
pub 16384R/8A6EC81A 2013-10-27
Key fingerprint = 9EB1 A490 C73C C5D4 4DFB 3E47 BFBD 1C7B 8A6E C81A
uid Yawning Angel yawn...@schwanenlied.me
sub 4096R/0807C068 2013-10-27 [expires: 2014-10-27]
sub 4096R/EDD2E2F4 2013-10-27 [expires: 2014-10-27]
sub 4096R/44299925 2013-10-27 [expires: 2014-10-27]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJTMnt0AAoJEMIYUlgZ94RRnkYP/0gp4qm/TmBrcE0WYw09l0ib
f9to7ZhFIkR10b1BqY7Tp8n2cYV2jwZpGsCII2iambR40sHSoiNy2raI1QA04vah
Wh+F3ukTQEAoubcb2XUQtWPofN6xUkohDIw5z7NuydieOCGgk82YKNaIh2Qzztjh
JPGg3+yE7vrZ0zZOrSF7wHVAeIixLT0jwpoo8d1HGHIWdfOfijiXxzlAa8ior0mZ
nl8qR2im42b8zcNCDTS+vI+nxq2qYOGsm+Gr9ZSKJdnQzOzNK2CZy3MIqcZE9Q1Y
JClp8/LsgC8pNwgbfI5khgh9V2qnUamFgB17AG7hE+JGPgOxz4FJ+mbP+ezlz0dC
v9EyCzleKkXiCgvqUb7HO0NONSFfBcK6I+R5JG9zoFdtZN3vLuW8zG0z86jBPAa5
k02wcP6FHaT4EL429K1vvX43YYAQ2q6//o+QbqGw5jIM+LqNgCtXghMZULVCQ7WQ
fKMrJue3cavTQR3GwZMEMMcC8dYnQZ//eYn9vPvfQZiR03IFVJ56mw+S/duyAsxJ
+/lPXVAIvXooVZVnymBRfTRAyvfHMyibMSC7z2B+4luImrlK0yL821PMjdm0Oo6d
VBuobGm9eHF8DeghnejEvEnnI7MQ4oBGd8W+6+i5rJ8o3oqrcY7GOSafK6pk5Iuh
7vV3bLLXB/rcTkO5I5Q/
=zSeT
-END PGP SIGNATURE-
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11316
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11316 [Tor Sysadmin Team]: please make ldap account for yawning
#11316: please make ldap account for yawning
---+-
Reporter: arma | Owner:
Type: task | Status: new
Priority: normal | Milestone:
Component: Tor Sysadmin Team |Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
---+-
Comment (by isis):
{{{
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I certify that the above information is correct, and that Yawning is an
awesome ship^Whuman and a wonderful addition to Tor's developers and
community.
-BEGIN PGP SIGNATURE-
iQMhBAEBCgELBQJTMn1rBYMB4TOAVhSAACUAKGlzaXMrc2lnbnN1YmtleUBw
YXR0ZXJuc2ludGhldm9pZC5uZXRGQzYzQUE1Q0QxOTM4NjlDMzIzNzE0NUE1QzE3
Nzc2RTI3RjdFODRESxSAABoAKGlzaXNAcGF0dGVybnNpbnRoZXZvaWQubmV0
MEE2QTU4QTE0QjU5NDZBQkRFMThFMjA3QTNBREI2N0EyQ0RCOEIzNS4aaHR0cHM6
Ly9ibG9nLnBhdHRlcm5zaW50aGV2b2lkLm5ldC9wb2xpY3kudHh0LJhodHRwczov
L2Jsb2cucGF0dGVybnNpbnRoZXZvaWQubmV0L2lzaXMudHh0AAoJEFwXd24n9+hN
/Q8P/1lt+HwFxZ/hOJ9xPXoIcN7L5QX2GOgz7VyYDBVLEN5G/0Lgq8I6ex6BRR+r
I5Kq/86BzPBb5/35IZTL3xoy3XT3NkN4fABbmejDpW6hMeObaeoGZLPEnZORO+6V
1CDFGOgDAoIPQFZV/sAeTdWcVZYmxlu5VhLjbmKY9EF1LcEHA6G98z4yJt6aN0X6
xL2VH2eQ3Du8S+SobGVyhdQ1Bf+czeRmmI8xvEM+KNsBg6IrfTPYhYGsqUQHnnKX
IUggdNatxg0OwFZOSe9wsP8PcS2oHrvrxw7FNDzTrWPGUCErUtKT+DPeoNmPwiV7
R3TTSvoaYP2kYrrm83BAlrTE56rCOTdPHv8RhnWwJzuxtAyO02f+uhSZdWySLVSY
uWxdZa+NdQ3ajkuWvQUY+xjWMJR4NIR72MYYZe3B9nFyKLz1Qpi4LuD1C0kOQR3b
BXu3dQDoDazbiXfI4twCxx4xI2+QdtrIzBhqkjdqWi54UejgJ17iJS1YLFp7yhN9
a3xcq1OchSMqt7jzaj+TmBCeqIz04ZWaaY/QUA/0IZFCDJIbnIiiJuTdcpCI5WlB
nQtvdxzWC9OCcshBZDQLpU7x4iqaYEhVVwEK9u8ghdGDYdOsga7REaxAl/yKJP4d
HHP0T6t0YfnknCw4Q9YImKz1mUbpulVcGQVprdE0DvvK8ex6
=bRBa
-END PGP SIGNATURE-
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11316#comment:1
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11291 [Tor]: Support group readable hidden service directories
#11291: Support group readable hidden service directories -+ Reporter: anon | Owner: Type: enhancement | Status: needs_review Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-hs Actual Points: | Parent ID: Points: | -+ Comment (by anon): Almost done with new test_checkdir.c to verify this and other options. (No prior test coverage for check_private_dir()) I still need to sync up with ioerror and confirm this fixes his gstreamer system Tor configuration. [or reproduce same myself, and confirm. TBD.] -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11291#comment:6 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11316 [Tor Sysadmin Team]: please make ldap account for yawning
#11316: please make ldap account for yawning ---+- Reporter: arma | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Tor Sysadmin Team |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | ---+- Changes (by yawning): * cc: yawning (added) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11316#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11317 [Tor]: 107.4.24.102:443 A0F54BE1BFFC6090223FB5925FE74FE80FBA389A
#11317: 107.4.24.102:443 A0F54BE1BFFC6090223FB5925FE74FE80FBA389A -+- Reporter: skylane2013 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Tor |Version: Keywords: | Actual Points: Parent ID: | Points: -+- [Wed Mar 26 00:13:23 2014] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: assign_onionskin_to_cpuworker(): Bug: cpuworker.c:680: assign_onionskin_to_cpuworker: Assertion cpuworker failed; aborting. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11317 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11318 [Vidalia]: Tor should not forget proxy settings when deactivated
#11318: Tor should not forget proxy settings when deactivated -+- Reporter: madosch | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: Vidalia |Version: Keywords: proxy, settings, forget | Actual Points: Parent ID: | Points: -+- Hello there, It's a very small request and there's no bug at all. But I have continuously to change my proxy settings when I'm at work/elsewhere. Every time I uncheck the proxy use at Vidalia, it forgets my proxy settings. Is there a way to keep the settings here? Kind regards, Markus W. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11318 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9701 [Firefox Patch Issues]: Prevent TorBrowser from creating clipboardcache turds
#9701: Prevent TorBrowser from creating clipboardcache turds -+- Reporter: cypherpunks | Owner: mikeperry Type: defect | Status: new Priority: normal | Milestone: Component: Firefox Patch|Version: Issues | Keywords: tbb-disk-leak, Resolution: | interview Actual Points: | Parent ID: Points: | -+- Changes (by gk): * cc: gk (added) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9701#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #3246 [Firefox Patch Issues]: Apply third party cookie patch
#3246: Apply third party cookie patch -+- Reporter: mikeperry| Owner: mikeperry Type: enhancement | Status: new Priority: major| Milestone: Component: Firefox Patch|Version: Issues | Keywords: backport-to-mozilla, Resolution: | tbb-linkability, tbb-usability- Actual Points: | website, tbb-bounty Points: | Parent ID: -+- Changes (by gk): * cc: g.koppen@… (removed) * cc: gk (added) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/3246#comment:16 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11303 [Tor bundles/installation]: TorBrowserBundle-3.5.3 no longer accepts any cookies or remembers any history
#11303: TorBrowserBundle-3.5.3 no longer accepts any cookies or remembers any history --+--- Reporter: jake | Owner: erinn Type: defect| Status: new Priority: normal| Milestone: Component: Tor bundles/installation |Version: Resolution:| Keywords: tbb-usability Actual Points:| Parent ID: Points:| --+--- Changes (by gk): * keywords: = tbb-usability * version: Tor: unspecified = Comment: Works for me. And no, there has been no flip in the privacy policy. How did you come to this conclusion? And why do you assume that it no longer accepts cookies (which it does on my machine)? Tested with a freshly downloaded en-US bundle on 10.6. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11303#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11303 [Tor bundles/installation]: TorBrowserBundle-3.5.3 no longer accepts any cookies or remembers any history
#11303: TorBrowserBundle-3.5.3 no longer accepts any cookies or remembers any history --+--- Reporter: jake | Owner: erinn Type: defect| Status: new Priority: normal| Milestone: Component: Tor bundles/installation |Version: Resolution:| Keywords: tbb-usability Actual Points:| Parent ID: Points:| --+--- Comment (by gk): To be clear on the privacy policy part: we are using the Private Browsing Mode by default which should result in a Never remember history in the Tor Browser settings. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11303#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9889 [Atlas]: Add Tshirt: yes/no to Atlas and Globe
#9889: Add Tshirt: yes/no to Atlas and Globe -+ Reporter: arma | Owner: hellais Type: enhancement | Status: needs_revision Priority: normal | Milestone: Component: Atlas|Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | -+ Comment (by karsten): Regarding your questions, the evaluation in `print_debug_info` looks fine, and storing fetched documents locally doesn't seem necessary at this point. Your updated branch looks good! I made a few more fixes here: https://gitweb.torproject.org/karsten/metrics- tasks.git/shortlog/refs/heads/task-9889. If you like them, I'll push this branch to the official metrics-tasks.git. Thanks! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9889#comment:10 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11314 [Service - git]: Let nickhopper push to anonbib git repo
#11314: Let nickhopper push to anonbib git repo -+- Reporter: arma | Owner: erinn, nickm, Sebastian, weasel Type: task | Status: closed Priority: normal | Milestone: Component: Service -|Version: git| Keywords: Resolution: fixed| Parent ID: Actual Points: | Points: | -+- Changes (by Sebastian): * status: new = closed * resolution: = fixed Comment: [x] -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11314#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #10697 [Tor Weather]: Fetch hourly lists from Onionoo with relay status
#10697: Fetch hourly lists from Onionoo with relay status -+- Reporter: baumanno | Owner: baumanno Type: task | Status: assigned Priority: normal | Milestone: Component: Tor Weather |Version: Resolution: | Keywords: weather-rewrite, hourly Actual Points: | Parent ID: Points: | -+- Comment (by Falken): Was reviewing the code for the hourly script with the idea that I would tackle the daily one, also was reading up on Karstens t-shirt script and think that all of them (and more) could be helped of the caching mechanism that baumanno has included in the hourly script. I would suggest that we break that code out into a separate module to avoid duplication of code and have all of the weather scripts benifit from faster caching mechanism. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/10697#comment:7 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11078 [TorBrowserButton]: TBB Doesn't Respond to Programmatic Maximize Request
#11078: TBB Doesn't Respond to Programmatic Maximize Request --+--- Reporter: cypherpunks | Owner: mikeperry Type: defect| Status: new Priority: normal| Milestone: Component: TorBrowserButton |Version: Resolution:| Keywords: tbb-usability Actual Points:| Parent ID: Points:| --+--- Changes (by CRhode): * cc: CRhode@… (added) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11078#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9683 [Tor]: circuit_unlink_all_from_channel() is a performance bottleneck?
#9683: circuit_unlink_all_from_channel() is a performance bottleneck? +-- Reporter: arma| Owner: Type: defect | Status: closed Priority: major | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: fixed | Keywords: tor-relay, 024-backport, 025-triaged Actual Points: | Parent ID: Points: | +-- Comment (by nickm): whoops. That testing code isn't supposed to still be on. Fixed in 6da2544 -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9683#comment:33 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11317 [Tor]: assign_onionskin_to_cpuworker: Assertion cpuworker failed; aborting (was: 107.4.24.102:443 A0F54BE1BFFC6090223FB5925FE74FE80FBA389A)
#11317: assign_onionskin_to_cpuworker: Assertion cpuworker failed; aborting -+- Reporter: skylane2013 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Tor |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | -+- Comment (by nickm): What version of Tor are you using, on what operating system? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11317#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11317 [Tor]: assign_onionskin_to_cpuworker: Assertion cpuworker failed; aborting
#11317: assign_onionskin_to_cpuworker: Assertion cpuworker failed; aborting -+ Reporter: skylane2013 | Owner: Type: defect | Status: needs_information Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | -+ Changes (by nickm): * status: new = needs_information * milestone: = Tor: 0.2.5.x-final -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11317#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11312 [Tor]: reuse introduction circuit as rendezvous circuit
#11312: reuse introduction circuit as rendezvous circuit -+ Reporter: dave2008 | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Tor: 0.2.??? Component: Tor |Version: Resolution: | Keywords: needs-proposal Actual Points: | Parent ID: Points: | -+ Changes (by nickm): * keywords: = needs-proposal * milestone: = Tor: 0.2.??? Comment: The other issue would be that an introduction point could link the rendezvous circuit with the introduction circtuit, which previously they would not have been able to do. I haven't analyzed the security implications of that, though. It probably needs a proposal -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11312#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11319 [TorBrowserButton]: TBB Automatically Chooses an Inappropriate Size for Its Main Window
#11319: TBB Automatically Chooses an Inappropriate Size for Its Main Window --+-- Reporter: CRhode| Owner: mikeperry Type: defect| Status: new Priority: normal| Milestone: Component: TorBrowserButton |Version: Tor: unspecified Keywords: tbb-usability | Actual Points: Parent ID:| Points: --+-- TBB opens with the bottom edge of its frame beyond the lower limit of the screen in Gnome3. This is a follow-on to Bug #11078 and is motivated by a request for additional information there. TBB attempts to choose window dimensions from a small set so any particular user is likely to fall into the same category with many others and therefore be less identifiable. It should pick a window size that fits completely within the screen size on the user's terminal. Here is a case where it doesn't. When the User hovers the cursor over a link, Firefox shows a pop-up box (toaster) in the lower left containing the link's URL. In the attached screen shot, only the top few pixels of that toaster are visible. Maximizing the TBB window brings it all back into view but impacts anonymity because Firefox reports the new window size in response to server inquiries. The full-screen window size may be more or less unique to the User. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11319 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11078 [TorBrowserButton]: TBB Doesn't Respond to Programmatic Maximize Request
#11078: TBB Doesn't Respond to Programmatic Maximize Request --+--- Reporter: cypherpunks | Owner: mikeperry Type: defect| Status: new Priority: normal| Milestone: Component: TorBrowserButton |Version: Resolution:| Keywords: tbb-usability Actual Points:| Parent ID: Points:| --+--- Comment (by CRhode): Replying to [comment:1 gk]: The TBB default window size does not fit entirely on my screen. In particular the URL Status line is off the bottom of the screen. Not sure what you mean but that might be a different bug. Could you file one and attach a screenshot showing the problem? Sure. Here is Bug #11319: TBB Automatically Chooses an Inappropriate Size for Its Main Window -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11078#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11319 [TorBrowserButton]: TBB Automatically Chooses an Inappropriate Size for Its Main Window
#11319: TBB Automatically Chooses an Inappropriate Size for Its Main Window --+--- Reporter: CRhode| Owner: mikeperry Type: defect| Status: needs_information Priority: normal| Milestone: Component: TorBrowserButton |Version: Tor: unspecified Resolution:| Keywords: tbb-usability Actual Points:| Parent ID: Points:| --+--- Changes (by gk): * status: new = needs_information Comment: What is the relation of this bug to #11078? They seem to be about different things or am I missing something? Does your window get correctly rounded to a multiple of 200x100, though? Do you have a taskbar that could play a role here (see the issues in #9268)? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11319#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11320 [Tor Sysadmin Team]: integrate torproject.fr into our dns
#11320: integrate torproject.fr into our dns ---+- Reporter: phobos | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Tor Sysadmin Team |Version: Keywords: | Actual Points: Parent ID: | Points: ---+- A helpful volunteer registered torproject.fr for us. It requires an EU address to keep the registration, so they are willing to leave it at their address. We just need to update dns to accept it. We can treat it like we treat torproject.se -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11320 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11320 [Tor Sysadmin Team]: integrate torproject.fr into our dns
#11320: integrate torproject.fr into our dns ---+- Reporter: phobos | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Tor Sysadmin Team |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | ---+- Changes (by phobos): * cc: phobos (added) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11320#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11300 [Tor Sysadmin Team]: Find a secure signing machine for TBB signing
#11300: Find a secure signing machine for TBB signing ---+ Reporter: mikeperry | Owner: phobos Type: task | Status: new Priority: normal | Milestone: Component: Tor Sysadmin Team |Version: Resolution: | Keywords: Actual Points: | Parent ID: #11299 Points: | ---+ Comment (by phobos): Why is this assigned to me? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11300#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #4232 [Website]: download-easy should autodetect users' processor architecture if possible
#4232: download-easy should autodetect users' processor architecture if possible -+-- Reporter: rransom | Owner: Type: enhancement | Status: assigned Priority: normal | Milestone: Component: Website |Version: Resolution: | Keywords: www-team Actual Points: | Parent ID: Points: | -+-- Changes (by phobos): * status: new = assigned * owner: phobos = -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/4232#comment:8 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #10548 [Tor Sysadmin Team]: [hw14] finalize hardware configuration
#10548: [hw14] finalize hardware configuration -+- Reporter: phobos | Owner: Type: task | Status: closed Priority: normal | Milestone: Upgrade Tor's VM Infrastructure Component: Tor |Version: Sysadmin Team | Keywords: sysadmin sysupgrade Resolution: fixed| Parent ID: #10338 Actual Points: | Points: | -+- Changes (by phobos): * status: new = closed * resolution: = fixed Comment: resource config sent to provider. Systems finalized and created. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/10548#comment:10 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11312 [Tor]: reuse introduction circuit as rendezvous circuit
#11312: reuse introduction circuit as rendezvous circuit -+ Reporter: dave2008 | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Tor: 0.2.??? Component: Tor |Version: Resolution: | Keywords: needs-proposal Actual Points: | Parent ID: Points: | -+ Comment (by dave2008): Hm.. good point. That's the case when IP is malicious while HS is not. I would like to first hack up a demo and do some profiling before sending out a formal proposal. Just to get a rough idea of the performance gain. Then we can discuss on the trade-off between security and speed. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11312#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11319 [TorBrowserButton]: TBB Automatically Chooses an Inappropriate Size for Its Main Window
#11319: TBB Automatically Chooses an Inappropriate Size for Its Main Window --+--- Reporter: CRhode| Owner: mikeperry Type: defect| Status: needs_information Priority: normal| Milestone: Component: TorBrowserButton |Version: Tor: unspecified Resolution:| Keywords: tbb-usability Actual Points:| Parent ID: Points:| --+--- Comment (by gk): Okay, scratch my first two questions :) (the other two remain) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11319#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11319 [TorBrowserButton]: TBB Automatically Chooses an Inappropriate Size for Its Main Window
#11319: TBB Automatically Chooses an Inappropriate Size for Its Main Window --+--- Reporter: CRhode| Owner: mikeperry Type: defect| Status: needs_information Priority: normal| Milestone: Component: TorBrowserButton |Version: Tor: unspecified Resolution:| Keywords: tbb-usability Actual Points:| Parent ID: Points:| --+--- Comment (by CRhode): Replying to [comment:1 gk]: Do you have a taskbar that could play a role here (see the issues in #9268)? Ah, yes, ... and I haven't mentioned before that I do run the PrefBar extension ... so this looks like its related to Bug #9268. What is the relation of this bug to #11078? They seem to be about different things or am I missing something? ... completely (well ... not completely) different! My big hangup is still Bug #11078. I don't seem to be able to specify a long enough delay in Devilspie for TBB to quiesce and accept a resize maximize request. If TBB calculated the total space required, including all the toolbars, and kept the extremities of its main window within the confines of the physical screen, then I might learn to live with it and take it out from under Devilspie's control. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11319#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11319 [TorBrowserButton]: TBB Automatically Chooses an Inappropriate Size for Its Main Window
#11319: TBB Automatically Chooses an Inappropriate Size for Its Main Window --+--- Reporter: CRhode| Owner: mikeperry Type: defect| Status: needs_information Priority: normal| Milestone: Component: TorBrowserButton |Version: Tor: unspecified Resolution:| Keywords: tbb-usability Actual Points:| Parent ID: Points:| --+--- Comment (by CRhode): ... and I know I'm not supposed to do that (run extensions like PrefBar), but I'm constantly fiddling with the four switches it gives me: Colors, Images, Font -, and Font +. I wish TBB did that. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11319#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11321 [Tor]: We stopped being able to build torify.1, and stopped trying to build it.
#11321: We stopped being able to build torify.1, and stopped trying to build it. ---+ Reporter: nickm | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor|Version: Tor: 0.2.5.1-alpha Keywords: tor-doc build | Actual Points: Parent ID: | Points: ---+ When we merged f8c45339f72525c6826d6db6a5e2acc4d7475952 to stop preprocessing the torify script, we broke the ability to preprocess the torify manpage... or indeed to build it at all. We also stopped trying to build it unless building tor-fw-helper. Silly us. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11321 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11321 [Tor]: We stopped being able to build torify.1, and stopped trying to build it.
#11321: We stopped being able to build torify.1, and stopped trying to build it. + Reporter: nickm | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.5.1-alpha Resolution: | Keywords: tor-doc build Actual Points: | Parent ID: Points: | + Changes (by nickm): * status: new = needs_review * cc: hiviah (added) Comment: That wasn't so hard to fix: see branch build_torrify_manpage_again in my public repository. Does it work for you? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11321#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11296 [Tor]: Missing include breaks build of tor-fw-helper in 0.2.5.3
#11296: Missing include breaks build of tor-fw-helper in 0.2.5.3 + Reporter: hiviah | Owner: Type: defect | Status: closed Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.5.3-alpha Resolution: fixed | Keywords: tor-client Actual Points: | Parent ID: Points: | + Changes (by nickm): * status: needs_review = closed * resolution: = fixed Comment: I've merged bug11296, and opened #11321 to track the other issue. I have a fix for that too. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11296#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #8405 [Tor]: Provide a control port command to query the circuit used for SOCKS u+p
#8405: Provide a control port command to query the circuit used for SOCKS u+p -+ Reporter: mikeperry| Owner: mikeperry Type: enhancement | Status: assigned Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: tor-client, mike-0.2.5 Actual Points: | Parent ID: #5752 Points: | -+ Comment (by mikeperry): Another way to do this might be to provide a query to ask Tor which circuit was used for a given SOCKS source port. There would be no ambiguity for such a query (unlike querying for SOCKS u+p, which may have ended up spanning several circuits if there were weird failures or odd ports). -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/8405#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11323 [EFF-HTTPS Everywhere]: Using small icons in the toolbar make the counter and the icon overlap
#11323: Using small icons in the toolbar make the counter and the icon overlap --+-- Reporter: bastik| Owner: pde Type: defect| Status: new Priority: normal| Milestone: HTTPS-E 4 stable Component: EFF-HTTPS Everywhere |Version: Keywords:| Actual Points: Parent ID:| Points: --+-- I like to use small icons and previously hadn't had the HTTPS-E icon in the toolbar so I can't tell if this is something that was always the case or it is some thing that broke along the way. If I use small icons in Firefox 28 the counter and the icon overlap each other. Best you look at the screen shot. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11323 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9599 [EFF-HTTPS Everywhere]: HTTPS Everywhere builds should be deterministic
#9599: HTTPS Everywhere builds should be deterministic --+-- Reporter: micahlee | Owner: micahlee Type: task | Status: assigned Priority: normal| Milestone: Component: EFF-HTTPS Everywhere |Version: Resolution:| Keywords: Actual Points:| Parent ID: Points:| --+-- Comment (by bastik): Is there a reason why this ticket is still open? (Found while looking for tickets about the add-on before creating new tickets) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9599#comment:6 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11322 [EFF-HTTPS Everywhere]: Add option to disable counter on toolbar icon
#11322: Add option to disable counter on toolbar icon --+-- Reporter: bastik| Owner: pde Type: enhancement | Status: new Priority: normal| Milestone: HTTPS-E 4 stable Component: EFF-HTTPS Everywhere |Version: Keywords:| Actual Points: Parent ID:| Points: --+-- I'd like to be able to disable the counter, which gets shown in the toolbar icon. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11322 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9599 [EFF-HTTPS Everywhere]: HTTPS Everywhere builds should be deterministic
#9599: HTTPS Everywhere builds should be deterministic --+-- Reporter: micahlee | Owner: micahlee Type: task | Status: assigned Priority: normal| Milestone: Component: EFF-HTTPS Everywhere |Version: Resolution:| Keywords: Actual Points:| Parent ID: Points:| --+-- Comment (by zyan): The build scripts on master and stable are deterministic now, but there was some confusion over whether the build scripts in the release repository were also deterministic. Looking into it now. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9599#comment:7 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #8402 [Tor]: Tor should help its transport proxy use a proxy, if needed.
#8402: Tor should help its transport proxy use a proxy, if needed. +-- Reporter: asn | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-bridge pt flashproxy Actual Points: | Parent ID: Points: | +-- Comment (by asn): This LGTM now. I need to test it too. I will do it tonight. Thanks! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/8402#comment:19 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11324 [Tor Sysadmin Team]: IP Allocations
#11324: IP Allocations -+- Reporter: phobos | Owner: Type: task | Status: new Priority: normal | Milestone: Upgrade Tor's VM Infrastructure Component: Tor |Version: Sysadmin Team | Actual Points: Keywords: sysadmin | Points: sysupgrade | Parent ID: #10338 | -+- Our list of current and planned IP allocations. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11324 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11325 [Tor]: RFE: Adhere to XDB base directory specification
#11325: RFE: Adhere to XDB base directory specification +-- Reporter: jamielinux | Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: Tor |Version: Tor: unspecified Keywords: | Actual Points: Parent ID: | Points: +-- As noted by a Fedora user [1], when running Tor as a regular user it creates $HOME/.tor instead of $XDG_CACHE_HOME/.tor, which is advised by the XDG specification [2] for user-specific non-essential (cached) data. Would you consider adhering to this specification? [1] https://bugzilla.redhat.com/show_bug.cgi?id=968163 [2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11325 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #8966 [Tor]: contrib/ directory should be cleaned up
#8966: contrib/ directory should be cleaned up -+ Reporter: rransom | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | -+ Comment (by nickm): I fixed the redox script a little. Also, peter and Karsten say they aren't using the directory-archive scripts. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/8966#comment:8 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11325 [Tor]: RFE: Adhere to XDB base directory specification
#11325: RFE: Adhere to XDB base directory specification +--- Reporter: jamielinux | Owner: Type: defect | Status: new Priority: minor | Milestone: Tor: unspecified Component: Tor |Version: Tor: unspecified Resolution: | Keywords: tor-client xdg-compliance Actual Points: | Parent ID: Points: | +--- Changes (by nickm): * priority: trivial = minor * keywords: = tor-client xdg-compliance * milestone: = Tor: unspecified Comment: What would be the benefit of users to adopting this standard? What operating systems support it? I'm not categorically opposed to adhering to this specification, but I'd like to know a bit more about what the point is supposed to be. (XDG_CACHE_HOME would not be appropriate -- only some of the files are cache files. The state file, for example, is not cached information, and treating it as safe-to-delete would degrade security. The keys subdirectory may contain sensitive private keys, and the lock file goes wherever locks go.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11325#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11325 [Tor]: RFE: Adhere to XDB base directory specification
#11325: RFE: Adhere to XDB base directory specification +--- Reporter: jamielinux | Owner: Type: defect | Status: new Priority: minor | Milestone: Tor: unspecified Component: Tor |Version: Tor: unspecified Resolution: | Keywords: tor-client xdg-compliance Actual Points: | Parent ID: Points: | +--- Comment (by jamielinux): Replying to [comment:1 nickm]: What would be the benefit of users to adopting this standard? What operating systems support it? I believe all modern Linux distributions support use of this standard, but support is more application specific not operating system specific. Many software packages on Fedora read the XDG_* variables if they are available, while others ignore them completely. I'm personally not all that fussed about this. The Fedora package is usually run as root anyway, in which case these data files are stored in /var/lib/tor. The benefits usually expressed include: - more organized home directory - more predictable locations for user-specific application files - more flexibility for changing these locations (eg, the user can set custom XDG_* variables) (XDG_CACHE_HOME would not be appropriate -- only some of the files are cache files. The state file, for example, is not cached information, and treating it as safe-to-delete would degrade security. The keys subdirectory may contain sensitive private keys, and the lock file goes wherever locks go.) Hmm agreed. XDG_DATA_HOME I would guess to be a more appropriate place for all of the files. (One might consider splitting files between different XDG directories according to their nature, but this would actually make things more confusing rather than providing any benefit.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11325#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11242 [Tor Launcher]: If you upgrade TBB by overwriting an old one, it reads the old extensions.torbutton.updateNeeded
#11242: If you upgrade TBB by overwriting an old one, it reads the old extensions.torbutton.updateNeeded --+-- Reporter: anon | Owner: brade Type: defect| Status: needs_review Priority: major | Milestone: Component: Tor Launcher |Version: Resolution:| Keywords: MikePerry201403R Actual Points:| Parent ID: Points:| --+-- Changes (by brade): * keywords: = MikePerry201403R * status: new = needs_review Comment: Here is a fix: https://gitweb.torproject.org/user/brade/torbutton.git/commit/b9fb03cd4ff8ac8c23a10831b11c7e50275ea6bf Mike, please review. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11242#comment:8 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11325 [Tor]: RFE: Adhere to XDB base directory specification
#11325: RFE: Adhere to XDB base directory specification +--- Reporter: jamielinux | Owner: Type: defect | Status: new Priority: minor | Milestone: Tor: unspecified Component: Tor |Version: Tor: unspecified Resolution: | Keywords: tor-client xdg-compliance Actual Points: | Parent ID: Points: | +--- Comment (by jamielinux): (Just to clarify. When I said The Fedora package is usually run as root anyway, what I really meant was started by root user through systemctl start tor.service and tor then runs as a non-privileged user that owns /var/lib/tor.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11325#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9229 [Tor]: While bootstrapping, Tor clients stall for 60s when obfsproxy bridges are used.
#9229: While bootstrapping, Tor clients stall for 60s when obfsproxy bridges are used. -+- Reporter: phw | Owner: asn Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: 60s, consensus, stall, obfsproxy, Actual Points: | flashproxy, tbb-needs 024-backport 025-triaged Points: | Parent ID: -+- Comment (by arma): Replying to [comment:23 nickm]: Branch bug9229_024 in my public repository has an alleged fix suitable for merge into 0.2.4 IMO, assuming it tests out okay. (It works for me.) Are we sure we don't want an update_all_descriptor_downloads() call too? I'm thinking of a case where we have an adequate cached consensus, and fetching the bridge descriptor should trigger us to fetch our microdescriptors now. (That said, I think your fix is an improvement over the current 0.2.4 situation, so it depends how far we want to go.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9229#comment:25 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #7646 [Tor]: fix/enhance getinfo ns/id/* commands
#7646: fix/enhance getinfo ns/id/* commands +--- Reporter: mr-4| Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.4.7-alpha Resolution: | Keywords: tor-client controller Actual Points: | Parent ID: Points: | +--- Comment (by nickm): Actually... ug. If I'm analyzing this right, the current behavior is just plain ugly. It takes the router status information, not from the node_t (where our current opinion about the router should be), but from the networkstatus_t (the thing we downloaded, which used to get modified with our opinions of node status, but which now is treated as immutable since we did the node_t refactor). And then it writes it in the old, pre-microdescriptor format...whether it's microdescriptor data or not, so the microdescriptor digest. Yuck yuck yuck. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/7646#comment:11 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11325 [Tor]: RFE: Adhere to XDB base directory specification
#11325: RFE: Adhere to XDB base directory specification +--- Reporter: jamielinux | Owner: Type: defect | Status: new Priority: minor | Milestone: Tor: unspecified Component: Tor |Version: Tor: unspecified Resolution: | Keywords: tor-client xdg-compliance Actual Points: | Parent ID: Points: | +--- Comment (by nickm): Hm. I think this is going to remain in the current milestone, to indicate its nice to have but not urgent status, unless it actually is urgent or important for some reason not yet apparent. If somebody does want to go and implement it, make sure that there's a migration path for users who put files at the old locations. Ideally, write the migration/interop plan first for review. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11325#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11326 [Service - git]: Let dgoulet push to torsocks git, and also archive the old one first
#11326: Let dgoulet push to torsocks git, and also archive the old one first -+- Reporter: arma | Owner: erinn, nickm, Sebastian, weasel Type: task | Status: new Priority: normal | Milestone: Component: Service -|Version: git| Actual Points: Keywords: | Points: Parent ID: | -+- https://gitweb.torproject.org/ has a torsocks git repo, which as I understand it is the old legacy torsocks. We should move that to an attic, and maybe rename it to torsocks-legacy for clarity. Then we should let dgoulet import his new improved torsocks and have it be our torsocks git repo. Thanks! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11326 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #10007 [Torsocks]: Code review of torsocks 2.x
#10007: Code review of torsocks 2.x -+- Reporter: dgoulet | Owner: ioerror Type: enhancement | Status: new Priority: normal | Milestone: Component: Torsocks |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | -+- Comment (by arma): So apparently this ticket is blocking moving the new torsocks code onto gitweb.torproject.org. I think it should not block this step (or at least, not any longer). I have opened #11326 as the other ticket. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/10007#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11326 [Service - git]: Let dgoulet push to torsocks git, and also archive the old one first
#11326: Let dgoulet push to torsocks git, and also archive the old one first -+- Reporter: arma | Owner: erinn, nickm, Sebastian, weasel Type: task | Status: new Priority: normal | Milestone: Component: Service -|Version: git| Keywords: Resolution: | Parent ID: Actual Points: | Points: | -+- Comment (by dgoulet): Small clarification, I based my code on top of the current upstream master so theoretically, I can push the new code on top without a problem. That would keep all the tags and history which is usually good. The only thing I would suggest is to remove the current branches that are quite old/broken/irrelevant/development/bugs. Those shouldn't be public in the main repository in the first place imo and wont be useful with the new code. In a nutshell, let the repository as is and simply delete the branches *except* master. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11326#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #8402 [Tor]: Tor should help its transport proxy use a proxy, if needed.
#8402: Tor should help its transport proxy use a proxy, if needed. +-- Reporter: asn | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-bridge pt flashproxy Actual Points: | Parent ID: Points: | +-- Comment (by asn): This worked fine in my tests. I tested obfsproxy in managed-mode with the proper tor/obfsproxy/pyptlib branches. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/8402#comment:20 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11327 [Tor]: Dir auths should choose Fast and Guard flags by consensus weight if they don't measure
#11327: Dir auths should choose Fast and Guard flags by consensus weight if they
don't measure
--+
Reporter: arma | Owner:
Type: defect| Status: new
Priority: normal| Milestone: Tor: 0.2.6.x-final
Component: Tor |Version:
Keywords: tor-auth | Actual Points:
Parent ID:| Points:
--+
In #8435 we made directory-authorities-that-run-bwauths stop voting Fast
or Guard for relays they hadn't measured yet.
But as I pointed out in
https://trac.torproject.org/projects/tor/ticket/8435#comment:13, since
only a minority of dir auths run bwauths, the majority of dir auths are
still voting Fast and Guard based on descriptor bandwidths.
So while the title of ticket #8435 says Ignore advertised bandwidths for
flags once we have enough measured bandwidths, the ChangeLog entry is
more accurate:
{{{
- Directory authorities that have more than a threshold number
of relays with measured bandwidths now treat relays with unmeasured
bandwidths as having bandwidth 0. Resolves ticket 8435.
}}}
We should at some point actually do the original goal, which is to give
Fast to the 7/8s of relays whose consensus weights are highest, and Guard
to the 1/2 of relays whose consensus weights are highest and who match the
other guard constraints.
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11327
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11327 [Tor]: Dir auths should choose Fast and Guard flags by consensus weight if they don't measure
#11327: Dir auths should choose Fast and Guard flags by consensus weight if they don't measure + Reporter: arma| Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-auth Actual Points: | Parent ID: Points: | + Comment (by arma): One suggestion is to look at the previous consensus, and use the number out of it, if we don't have a measurement of our own. There are two versions of that idea: one is that we use the consensus weight iff we don't run a bwauth, and the other is that we use the consensus weight if we don't run a bwauth or if we do but haven't measured that relay yet. I'm ok with either, but the former sounds a bit cleaner. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11327#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #8966 [Tor]: contrib/ directory should be cleaned up
#8966: contrib/ directory should be cleaned up
-+
Reporter: rransom | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.5.x-final
Component: Tor |Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
-+
Comment (by rl1987):
{{{
# XXX Does anybody use this?
# STET contrib/rc.subr
}}}
This seems to be a script for running Tor daemon on FreeBSD system, added
in 2006 and last changed in 2009. I believe it safe to remove it.
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/8966#comment:9
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11328 [Tor]: Dir auths should compute Guard WFU using the consensus, not private history
#11328: Dir auths should compute Guard WFU using the consensus, not private history --+ Reporter: arma | Owner: Type: defect| Status: new Priority: normal| Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Keywords: tor-auth | Actual Points: Parent ID:| Points: --+ Currently directory authorities track the presence of each relay and keep notes about their view locally. Then when it comes time to vote about Guard, they look at their notes and decide what fraction of the past interval the relay was up for. But it doesn't matter anymore to clients whether the directory authority could reach the relay for that time. The question as of the v3 directory design is whether the relay was in the consensus. So it seems like the directory authorities should be basing their measurements off is it in the consensus this hour. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11328 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11326 [Service - git]: Let dgoulet push to torsocks git, and also archive the old one first
#11326: Let dgoulet push to torsocks git, and also archive the old one first -+- Reporter: arma | Owner: erinn, nickm, Sebastian, weasel Type: task | Status: new Priority: normal | Milestone: Component: Service -|Version: git| Keywords: Resolution: | Parent ID: Actual Points: | Points: | -+- Comment (by Sebastian): I gave dgoulet access, I'd like the current owners to consent before deleting branches. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11326#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #8966 [Tor]: contrib/ directory should be cleaned up
#8966: contrib/ directory should be cleaned up -+ Reporter: rransom | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | -+ Comment (by rl1987): I made changes to script you have generated. I'm still not sure what to do about OS-specific scripts. Should we delete SuSE, Red Hat et. al. related files? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/8966#comment:10 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11329 [Obfsproxy]: struct.unpack() bug in socks5.py:get_uint16()
#11329: struct.unpack() bug in socks5.py:get_uint16()
---+-
Reporter: asn| Owner: asn
Type: defect | Status: new
Priority: normal | Milestone:
Component: Obfsproxy |Version:
Keywords: | Actual Points:
Parent ID: | Points:
---+-
Apparently we are passing a bytearray to struct.unpack() and it doesn't
like it. I got stuff like:
{{{
File /usr/local/lib/python2.7/dist-packages/obfsproxy-0.2.7_dirty-
py2.7.egg/obfsproxy/network/socks5.py, line 319, in processNoAuthRequired
self.processRequest()
File /usr/local/lib/python2.7/dist-packages/obfsproxy-0.2.7_dirty-
py2.7.egg/obfsproxy/network/socks5.py, line 377, in processRequest
port = msg.get_uint16(True)
File /usr/local/lib/python2.7/dist-packages/obfsproxy-0.2.7_dirty-
py2.7.egg/obfsproxy/network/socks5.py, line 503, in get_uint16
ret = struct.unpack(!H, self[0:2])[0]
struct.error: unpack requires a string argument of length 2
}}}
I then checked the length of `self[0:2]` and indeed it was `2`. Then I
checked it's type and it was a `bytearray`. I casted the `bytearray` to a
`str` before passing it to `struct.unpack` and it seemed to fix the
problem.
I'm not sure why we didn't trigger this bug in the past.
The bug is included in the latest `obfsproxy-0.2.7` release, I think.
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11329
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11139 [BridgeDB]: BridgeDB's email whitelist should include @riseup.net
#11139: BridgeDB's email whitelist should include @riseup.net
--+---
Reporter: isis | Owner: isis
Type: defect| Status: new
Priority: normal| Milestone:
Component: BridgeDB |Version:
Resolution:| Keywords: bridgedb-email,bridgedb-0.1.x
Actual Points:| Parent ID:
Points:|
--+---
Comment (by mikeperry):
I think this is a good idea, but if we're going to change the Tor Launcher
strings, we should try to future proof it, especially if stuff like #11140
is on the table (though I would prefer limiting the yahoo bridge pool
instead of completely removing it), or we want to add new providers later.
Here's the two entities I think we should use instead of the current
single entity:
{{{
!ENTITY torsettings.bridgeHelp3.emailDesc Send email to
brid...@torproject.org with the line 'get bridges' by itself in the body
of the message.#160; However, to make it harder for an attacker to learn
a lot of bridge addresses, you must send this request from one of the
following email address providers (listed in order of preference):
!ENTITY torsettings.bridgeHelp3.emailList https://www.riseup.net,
https://mail.google.com, or https://mail.yahoo.com;
}}}
This will produce:
{{{
Send email to brid...@torproject.org with the line 'get bridges' by itself
in the body of the message. However, to make it harder for an attacker to
learn a lot of bridge addresses, you must send this request from one of
the following email address providers (listed in order of preference):
https://mail.riseup.net, https://mail.google.com, or
https://mail.yahoo.com
}}}
How is that? Can we make the differing expense of crawling these three any
more clear with different (yet concise) text?
While we're at it, does the email interface allow the user to specify a
pluggable transport type? Does it give the user any additional
instructions about this, or should we also add that text to the Tor
Launcher UI?
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/11139#comment:6
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11330 [BridgeDB]: Create a Hash Ring For Each Allowed Domain in the Email Distributor
#11330: Create a Hash Ring For Each Allowed Domain in the Email Distributor -+- Reporter: sysrqb | Owner: Type: enhancement | Status: new Priority: major| Milestone: Component: BridgeDB |Version: Keywords: | Actual Points: Parent ID: | Points: -+- This will isolate the bridges such that if one provider is subverted it will not have the ability to obtain all bridges assigned to the distributor. The first easy way to do this is to change the EMAIL_DOMAINS config option to accept (domain, proportion) pairs instead of only the the domain name. Adding a new config option specifically for this will also work, but initially it seems unnecessary. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11330 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11139 [BridgeDB]: BridgeDB's email whitelist should include @riseup.net
#11139: BridgeDB's email whitelist should include @riseup.net --+--- Reporter: isis | Owner: isis Type: defect| Status: new Priority: normal| Milestone: Component: BridgeDB |Version: Resolution:| Keywords: bridgedb-email,bridgedb-0.1.x Actual Points:| Parent ID: Points:| --+--- Comment (by arma): That tiny little or you stuck in there makes the second one need to be translated. If you remove the or, will we be happier campers longterm? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11139#comment:7 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11139 [BridgeDB]: BridgeDB's email whitelist should include @riseup.net
#11139: BridgeDB's email whitelist should include @riseup.net --+--- Reporter: isis | Owner: isis Type: defect| Status: new Priority: normal| Milestone: Component: BridgeDB |Version: Resolution:| Keywords: bridgedb-email,bridgedb-0.1.x Actual Points:| Parent ID: Points:| --+--- Comment (by arma): Replying to [comment:4 arma]: I like the idea in theory. How hard is it to put riseup into a different bridge ring? That is, so riseup gets a few bridges that aren't accessible to somebody who is good at making gmail accounts? I'm still hoping for an answer to this one too. It seems like a bad design to continue to grow the set of domains that we accept, where the weakest domain in the set dictates how easy it is to learn all the bridges in the email bucket. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11139#comment:8 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11139 [BridgeDB]: BridgeDB's email whitelist should include @riseup.net
#11139: BridgeDB's email whitelist should include @riseup.net --+--- Reporter: isis | Owner: isis Type: defect| Status: new Priority: normal| Milestone: Component: BridgeDB |Version: Resolution:| Keywords: bridgedb-email,bridgedb-0.1.x Actual Points:| Parent ID: Points:| --+--- Comment (by mikeperry): Replying to [comment:7 arma]: That tiny little or you stuck in there makes the second one need to be translated. If you remove the or, will we be happier campers longterm? I think we actually want to encourage translation of this string. In RTL languages, leaving the string as-is will effectively make its ordering backwards, and those users will think that we're recommending that yahoo is the best email address to have. Without the or, translators might not immediately notice this reversal (due to the strings being split in the transifex UI). Of course, this ordering might end up lost in translation either way we go with the current phrasing, hence my request for better ways to convey that there is actually a difference in your ability to get working bridges from these three addresses. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11139#comment:9 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #8897 [Tor]: Faster curve25519 implementation for ntor
#8897: Faster curve25519 implementation for ntor -+ Reporter: nickm| Owner: nickm Type: enhancement | Status: needs_review Priority: major| Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-relay performance ntor Actual Points: | Parent ID: #9662 Points: | -+ Changes (by nickm): * milestone: Tor: 0.2.5.x-final = Tor: 0.2.6.x-final -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/8897#comment:11 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9663 [Tor]: Table-based basepoint multiply optimizations for ntor handshake
#9663: Table-based basepoint multiply optimizations for ntor handshake -+ Reporter: nickm| Owner: Type: enhancement | Status: needs_review Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-relay performance ntor Actual Points: | Parent ID: #9662 Points: | -+ Changes (by nickm): * milestone: Tor: 0.2.5.x-final = Tor: 0.2.6.x-final Comment: Too big for 0.2.5.x at this point IMO. Andrea concurs. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9663#comment:6 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11291 [Tor]: Support group readable hidden service directories
#11291: Support group readable hidden service directories -+ Reporter: anon | Owner: Type: enhancement | Status: needs_review Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-hs Actual Points: | Parent ID: Points: | -+ Comment (by nickm): (r, sorry, I meant early in 0.2.6.x. I hope that won't be too long now.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11291#comment:7 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9682 [Tor]: Better work queue implementation for cpuworkers
#9682: Better work queue implementation for cpuworkers -+- Reporter: nickm| Owner: Type: enhancement | Status: needs_review Priority: major| Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-relay performance cpuworker Actual Points: | Parent ID: Points: | -+- Changes (by nickm): * priority: normal = major * milestone: Tor: 0.2.5.x-final = Tor: 0.2.6.x-final -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9682#comment:14 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #7164 [Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1
#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still
referenced
1 node(s); held_by_nodes == 1
+-
Reporter: jaj123 | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.5.x-final
Component: Tor |Version: Tor: 0.2.4.19
Resolution: | Keywords: tor-client 024-backport
Actual Points: | Parent ID:
Points: |
+-
Comment (by andrea):
Replying to [comment:30 nickm]:
The line number suggests that this is happening in
microdesc_cache_clean():
{{{
for (mdp = HT_START(microdesc_map, cache-map); mdp != NULL; ) {
if ((*mdp)-last_listed cutoff) {
++dropped;
victim = *mdp;
mdp = HT_NEXT_RMV(microdesc_map, cache-map, mdp);
victim-held_in_map = 0;
bytes_dropped += victim-bodylen;
microdesc_free(victim);
} else {
++kept;
mdp = HT_NEXT(microdesc_map, cache-map, mdp);
}
}
}}}
So, there's a microdesc that is (probably) held by a node, but its last-
listed is more than one week ago. Interesting!
In theory:
* A node should not exist unless it has a routerstatus or a
routerinfo.
* A node should not have a microdescriptor unless it has a
routerstatus.
* Whenever a networkstatus is loaded, we should be updating the
last_seen field of the microdescriptors.
So something has gone wrong with the theory.
I'm not too sure what -- if somebody has ideas, that would be great.
I've tried to write an improved diagnostic branch. Please review
bug7164_diagnose_harder in my public repository. It's more logs, not a
fix.
Doesn't this also change the behavior as well?
{{{
-if ((*mdp)-last_listed cutoff) {
+const int is_old = (*mdp)-last_listed cutoff;
+const unsigned held_by_nodes = (*mdp)-held_by_nodes;
+if (is_old !held_by_nodes) {
}}}
The test that would match the old behavior would be just if (is_old),
surely?
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/7164#comment:33
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #7164 [Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1
#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1 +- Reporter: jaj123 | Owner: Type: defect | Status: needs_review Priority: major | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.4.19 Resolution: | Keywords: tor-client 024-backport Actual Points: | Parent ID: Points: | +- Comment (by andrea): Also, the wording of the log messages (Microdescriptor seemed very old (last listed %d hours ago vs %d hour cutoff), but is still marked as being held by %d node(s). I found %d node(s) holding it.) suggests you only want to emit for old microdescriptors, but the enclosing test is just if (held_by_nodes) rather than if (is_old held_by_nodes). Am I missing something here? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/7164#comment:34 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #7164 [Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1
#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1 +- Reporter: jaj123 | Owner: Type: defect | Status: needs_review Priority: major | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.4.19 Resolution: | Keywords: tor-client 024-backport Actual Points: | Parent ID: Points: | +- Comment (by andrea): I think the actual logging code is okay as long as we're sure the tests are right; making them over-eager means a lot of searching the whole list of nodes in nodelist_find_nodes_with_microdesc() whenever we run microdesc_cache_clean() -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/7164#comment:35 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #7164 [Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1
#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1 +- Reporter: jaj123 | Owner: Type: defect | Status: needs_review Priority: major | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.4.19 Resolution: | Keywords: tor-client 024-backport Actual Points: | Parent ID: Points: | +- Comment (by nickm): The test that would match the old behavior would be just if (is_old), surely? The old behavior was to call microdesc_free() if the microdescriptor was old... and then the warning would be produced because held_by_nodes was nonzero, and we wouldn't free the thing. The change here has the old behavior in the non-warning case, and the new behavior in the case where we would have given a warning. Also, the wording of the log messages (Microdescriptor seemed very old (last listed %d hours ago vs %d hour cutoff), but is still marked as being held by %d node(s). I found %d node(s) holding it.) suggests you only want to emit for old microdescriptors, but the enclosing test is just if (held_by_nodes) rather than if (is_old held_by_nodes). Am I missing something here? Oops. Yeah, adding a fixup commit. Better now? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/7164#comment:36 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #7164 [Tor]: microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1
#7164: microdesc.c:378: Bug: microdesc_free() called, but md was still
referenced
1 node(s); held_by_nodes == 1
+-
Reporter: jaj123 | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.5.x-final
Component: Tor |Version: Tor: 0.2.4.19
Resolution: | Keywords: tor-client 024-backport 025-triaged
Actual Points: | Parent ID:
Points: |
+-
Changes (by nickm):
* keywords: tor-client 024-backport = tor-client 024-backport 025-triaged
Comment:
{{{
22:12 nickm athena: okay to merge now IYO?
22:12 athena yeah
}}}
I shoudl squash and merge rsn then.
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/7164#comment:37
Tor Bug Tracker Wiki https://trac.torproject.org/
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] #11302 [Tor]: connection_handle_write_impl() should handle orconns properly if getsockopt() fails
#11302: connection_handle_write_impl() should handle orconns properly if getsockopt() fails + Reporter: andrea | Owner: andrea Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Tor: 0.2.5.3-alpha Resolution: | Keywords: Actual Points: | Parent ID: Points: | + Changes (by nickm): * milestone: Tor: 0.2.5.x-final = Tor: 0.2.6.x-final -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11302#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11329 [Obfsproxy]: struct.unpack() bug in socks5.py:get_uint16()
#11329: struct.unpack() bug in socks5.py:get_uint16() ---+- Reporter: asn| Owner: asn Type: defect | Status: new Priority: normal | Milestone: Component: Obfsproxy |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | ---+- Comment (by yawning): This is dependent on the version of python: http://bugs.python.org/issue10212 I did all the development with 2.7.6 so I didn't hit it. Casting is the correct thing to do, want me to fix this in a branch? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11329#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11304 [Tor]: connection_write_to_buf_impl_() might incorrectly call connection_mark_for_close() on an orconn
#11304: connection_write_to_buf_impl_() might incorrectly call connection_mark_for_close() on an orconn +--- Reporter: andrea | Owner: andrea Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.5.3-alpha Resolution: | Keywords: tor-relay 025-triaged Actual Points: | Parent ID: Points: | +--- Changes (by nickm): * keywords: = tor-relay 025-triaged -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11304#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11306 [Tor]: connection_mark_all_noncontrol_connections() handles orconns wrongly
#11306: connection_mark_all_noncontrol_connections() handles orconns wrongly + Reporter: andrea | Owner: andrea Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.5.3-alpha Resolution: | Keywords: tor-client 025-triaged Actual Points: | Parent ID: Points: | + Changes (by nickm): * keywords: = tor-client 025-triaged -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11306#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9708 [Tor]: Clarify please raise ulimit -n message
#9708: Clarify please raise ulimit -n message -+- Reporter: philip | Owner: Type: | Status: new enhancement| Milestone: Tor: 0.2.5.x-final Priority: minor|Version: Tor: 0.2.4.16-rc Component: Tor | Keywords: tor-relay 024-backport log, ulimit, Resolution: | limits 025-triaged 025-deferrable Actual Points: | Parent ID: Points: | -+- Changes (by nickm): * keywords: tor-relay 024-backport log, ulimit, limits = tor-relay 024-backport log, ulimit, limits 025-triaged 025-deferrable Comment: Triage: this is just changing a warning and adding a manpage section. If somebody composes the manpage section, I'm happy to put it in the manpage and change the warning to tell people to look at it. But if the manpage section doesn't get written, we should defer. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9708#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11150 [Tor]: Remove client code for connecting to and using 0.2.2 servers
#11150: Remove client code for connecting to and using 0.2.2 servers + Reporter: nickm | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.6.x-final Component: Tor |Version: Resolution: | Keywords: tor-client Actual Points: | Parent ID: #9476 Points: | + Changes (by nickm): * milestone: Tor: 0.2.5.x-final = Tor: 0.2.6.x-final -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11150#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #10817 [Tor]: Write instructions for using valgrind with the debian tor
#10817: Write instructions for using valgrind with the debian tor -+- Reporter: arma | Owner: Type: task | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: tor-relay 025-triaged Actual Points: | 025-deferrable lorax Points: | Parent ID: -+- Changes (by nickm): * keywords: tor-relay = tor-relay 025-triaged 025-deferrable lorax Comment: Nice to have if somebody writes it, but okay to defer. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/10817#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #10432 [Tor]: Sudden spike in memory consumption
#10432: Sudden spike in memory consumption +--- Reporter: ln5 | Owner: Type: defect | Status: needs_information Priority: normal | Milestone: Tor: 0.2.??? Component: Tor |Version: Resolution: | Keywords: tor-auth mem Actual Points: | Parent ID: Points: | +--- Changes (by nickm): * status: new = needs_information * milestone: Tor: 0.2.5.x-final = Tor: 0.2.??? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/10432#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #8793 [Tor]: Resolve clang scan-build issues
#8793: Resolve clang scan-build issues + Reporter: nickm | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: tor-client 025-triaged Actual Points: | Parent ID: Points: | + Changes (by nickm): * keywords: tor-client = tor-client 025-triaged Comment: The false positive rate is too high here to make fix all the issues sensible. Somebody besides me should just confirm my impression that all the positives _are_ false positives, and then we should close the ticket. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/8793#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #7727 [Tor]: Simplify some costly Tor functions (by profile)
#7727: Simplify some costly Tor functions (by profile) -+ Reporter: nickm| Owner: Type: defect | Status: closed Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: 0.2.4.6-alpha Resolution: implemented | Keywords: tor-relay Actual Points: | Parent ID: Points: | -+ Changes (by nickm): * status: new = closed * resolution: = implemented Comment: Closing as no longer relevant, though see #9683 and #9841; adding a new ticket to get a newer profile. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/7727#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11331 [Tor]: rewrite tor in rust-lang
#11331: rewrite tor in rust-lang -+- Reporter: cypherpunks | Owner: Type: project | Status: new Priority: normal | Milestone: Component: Tor |Version: Keywords: | Actual Points: Parent ID: | Points: -+- Rust provides many features that would benefit Tor like memory safety, etc. Writing C code that is safe is super hard (even for exeperienced Tor devs). -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11331 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11332 [Tor]: Get a fresh set of relay/exit profiles on 0.2.5.4-alpha or later; optimize accordingly.
#11332: Get a fresh set of relay/exit profiles on 0.2.5.4-alpha or later; optimize accordingly. ---+ Reporter: nickm | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor|Version: Keywords: tor-relay performance | Actual Points: Parent ID: | Points: ---+ On #7727 we had some profile results that we used to identify bottleneck functions in Tor to optimize. We should get some fresh profiles on 0.2.5.4-alpha once it's out (assuming we merge #9841), and then see which of ''those'' bottlenecks need the most attention. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11332 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11332 [Tor]: Get a fresh set of relay/exit profiles on 0.2.5.4-alpha or later; optimize accordingly.
#11332: Get a fresh set of relay/exit profiles on 0.2.5.4-alpha or later; optimize accordingly. +--- Reporter: nickm | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: tor-relay performance 025-triaged Actual Points: | Parent ID: Points: | +--- Changes (by nickm): * keywords: tor-relay performance = tor-relay performance 025-triaged Comment: One thought I had about that last profile, though: SHA1 was at the top of the list. OpenSSL's PRNG uses a bunch of SHA1, and is ridiculously slow for a userspace PRNG. If SHA1 turns up at the top of the list again, we should investigate whether it's our protocols' uses of SHA1, TLS's uses of SHA1, or OpenSSL's PRNG's uses of SHA1 that are most to blame. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11332#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #7555 [Tor]: MapAddress from FQDN to .onion fails because resolve requests for hidden services are not allowed.
#7555: MapAddress from FQDN to .onion fails because resolve requests for hidden services are not allowed. + Reporter: aagbsn | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: unspecified Resolution: | Keywords: tor-client 025-triaged Actual Points: | Parent ID: Points: | + Changes (by nickm): * keywords: tor-client = tor-client 025-triaged -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/7555#comment:16 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11317 [Tor]: assign_onionskin_to_cpuworker: Assertion cpuworker failed; aborting
#11317: assign_onionskin_to_cpuworker: Assertion cpuworker failed; aborting -+ Reporter: skylane2013 | Owner: Type: defect | Status: needs_information Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: 025-triaged 025-deferrable Actual Points: | Parent ID: Points: | -+ Changes (by nickm): * keywords: = 025-triaged 025-deferrable -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11317#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11329 [Obfsproxy]: struct.unpack() bug in socks5.py:get_uint16()
#11329: struct.unpack() bug in socks5.py:get_uint16() ---+-- Reporter: asn| Owner: asn Type: defect | Status: needs_review Priority: normal | Milestone: Component: Obfsproxy |Version: Resolution: | Keywords: Actual Points: | Parent ID: Points: | ---+-- Changes (by yawning): * status: new = needs_review Comment: https://github.com/Yawning/obfsproxy/tree/bug_11329 -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11329#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #4580 [Tor]: Some Tor clients go nuts requesting the consensus if there is no recent enough consensus
#4580: Some Tor clients go nuts requesting the consensus if there is no recent enough consensus +- Reporter: arma| Owner: Type: defect | Status: new Priority: major | Milestone: Tor: 0.2.??? Component: Tor |Version: Tor: unspecified Resolution: | Keywords: tor-client 024-backport Actual Points: | Parent ID: Points: | +- Changes (by nickm): * milestone: Tor: 0.2.5.x-final = Tor: 0.2.??? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/4580#comment:15 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9635 [Tor]: Tor clients warn when they use the wrong ntor onion key
#9635: Tor clients warn when they use the wrong ntor onion key +- Reporter: bastik | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Tor: unspecified Resolution: | Keywords: tor-bridge 024-backport 025-triaged Actual Points: | Parent ID: Points: | +- Changes (by nickm): * keywords: tor-bridge 024-backport = tor-bridge 024-backport 025-triaged Comment: I think at this point the right choice for 0.2.5 is a better log message. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9635#comment:9 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #11315 [Tor]: Invalid write of size 8
#11315: Invalid write of size 8 -+- Reporter: arma | Owner: Type: defect | Status: needs_information Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: tor-relay valgrind 025-triaged Actual Points: | 025-deferrable Points: | Parent ID: -+- Changes (by nickm): * keywords: = tor-relay valgrind 025-triaged 025-deferrable * status: new = needs_information Comment: we're not going to figure that one out unless libevent-1.4 debug symbols get installed. And it could just as easily be a libevent 1.4 bug -- there are lots of those, libevent 1.4 is old. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/11315#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #9773 [Tor]: [warn] tor_timegm(): Bug: Out-of-range argument to tor_timegm
#9773: [warn] tor_timegm(): Bug: Out-of-range argument to tor_timegm +-- Reporter: arma| Owner: Type: defect | Status: new Priority: minor | Milestone: Tor: 0.2.??? Component: Tor |Version: Resolution: | Keywords: tor-auth Actual Points: | Parent ID: Points: | +-- Changes (by nickm): * milestone: Tor: 0.2.5.x-final = Tor: 0.2.??? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/9773#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ 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] #10481 [Tor]: connection_mark_unattached_ap_: checking always true edge_has_sent_end
#10481: connection_mark_unattached_ap_: checking always true edge_has_sent_end -+ Reporter: cypherpunks | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.5.x-final Component: Tor |Version: Resolution: | Keywords: tor-client 025-triaged Actual Points: | Parent ID: Points: | -+ Changes (by nickm): * keywords: tor-client = tor-client 025-triaged -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/10481#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
