Re: [tor-bugs] #20269 [Core Tor/Tor]: bridge users ignore their cached consensus file on startup

[Tor Bug Tracker & Wiki]

#20269: bridge users ignore their cached consensus file on startup
-+-
 Reporter:  arma |  Owner:  arma
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-proposed, nickm- |  Actual Points:
  deferred-20161017, review-group-11 |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by arma):

 Replying to [comment:10 teor]:
 > Replying to [comment:9 nickm]:
 > > Okay, but what will actually happen if a new client (with this patch)
 tries to run with an 0.2.2.x bridge?  That will break, right?
 > >
 > > If so, are we okay with that breaking?
 >
 > Yes, but we should log a warning to the client saying the bridge is too
 old.
 > (We should reject the bridge's descriptor in 0.2.9 anyway, as it doesn't
 have an ntor key.)

 It's worse than that: Tor 0.3.0.0 doesn't finish its TLS handshake with
 the 0.2.2.x bridge.

 I ran an 0.2.2.39 bridge and an 0.3.0.0 client.

 Here's what my (modern) client says:
 {{{
 Nov 13 01:09:16.852 [warn] Problem bootstrapping. Stuck at 10%: Finishing
 handshake with directory server. (IOERROR; IOERROR; count 1;
 recommendation warn; host  at
 128.31.0.39:9005)
 Nov 13 01:09:16.852 [warn] 1 connections have failed:
 Nov 13 01:09:16.852 [warn]  1 connections died in state handshaking (Tor,
 v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
 Nov 13 01:09:17.398 [warn] Problem bootstrapping. Stuck at 10%: Finishing
 handshake with directory server. (IOERROR; IOERROR; count 2;
 recommendation warn; host  at
 128.31.0.39:9005)
 Nov 13 01:09:17.398 [warn] 2 connections have failed:
 Nov 13 01:09:17.398 [warn]  2 connections died in state handshaking (Tor,
 v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
 }}}

 And here's what the (ancient) bridge says:
 {{{
 Nov 13 01:09:17.362 [debug] tor_tls_handshake(): Completed V2 TLS
 handshake with client; waiting for renegotiation.
 Nov 13 01:09:17.362 [debug] connection_tls_continue_handshake(): Done with
 initial SSL handshake (server-side). Expecting renegotiation.
 Nov 13 01:09:17.386 [debug] conn_read_callback(): socket 121 wants to
 read.
 Nov 13 01:09:17.386 [debug] connection_read_to_buf(): 121: starting,
 inbuf_datalen 0 (0 pending in tls object). at_most 16384.
 Nov 13 01:09:17.386 [debug] connection_read_to_buf(): After TLS read of 9:
 510 read, 1179 written
 Nov 13 01:09:17.386 [info] connection_or_process_inbuf(): Accumulated too
 much data (9 bytes) on nonopen OR connection from a.b.c.d:43856 in state
 waiting for renegotiation (TLS); closing.
 Nov 13 01:09:17.386 [debug] conn_close_if_marked(): Cleaning up connection
 (fd 121).
 }}}

 So unless we want to put some energy into figuring out how to resume
 supporting 0.2.2.x bridges and relays (in which case we should open a
 separate ticket for that), I suggest we merge this one and call it done.

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

[tor-bugs] #20649 [Metrics/Atlas]: Atlas display for missing GeoIP info could be improved

[Tor Bug Tracker & Wiki]

#20649: Atlas display for missing GeoIP info could be improved
---+-
 Reporter:  teor   |  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 When atlas can't find a GeoIP entry, it displays "null" for the AS number
 and name, and https://atlas.torproject.org/img/cc/.png for the image
 (which does not exist).

 It would be better to use some sort of placeholder.

 An example of a relay with this issue, as of 2016-11-13:
 https://atlas.torproject.org/#details/8FDE6EC5BBB9C275A276D45C3CC93A4A305048FA

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  028-backport, easy,  |  Actual Points:
  TorCoreTeam201611  |
Parent ID:   | Points:
 Reviewer:  teor, arma   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:24 arma]:
 > Replying to [comment:23 teor]:
 > > Let's get this merged, then:
 >
 > One last question -- are we sure that 0.2.9.5-alpha has correct
 behavior? :)

 We tried to give it better behaviour - how can we test that #20499 is
 correct?
 And we should probably avoid releasing 0.3.0.1-alpha until we're sure it's
 correct, for the same reason.
 (If we're sure it works, but then we find out it doesn't, we can add more
 versions later, but that's not ideal.)

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

Re: [tor-bugs] #19974 [Core Tor/Tor]: Test failure for monotonic time on some machines (was: Test failure for monotonic time on slow machines)

[Tor Bug Tracker & Wiki]

#19974: Test failure for monotonic time on some machines
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #20501 [Core Tor/DocTor]: Scan 0.2.9.x relays to see if they're serving an out-of-date consensus?

[Tor Bug Tracker & Wiki]

#20501: Scan 0.2.9.x relays to see if they're serving an out-of-date consensus?
-+-
 Reporter:  arma |  Owner:  atagar
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 The fallback checks sound better. Scanning the whole network took over ten
 hours so not something we'd run on a daily basis. If it's sufficient to
 just check fallbacks that's a lot more targeted.

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

Re: [tor-bugs] #20647 [Core Tor/Tor]: Run chutney tests in Jenkins

[Tor Bug Tracker & Wiki]

#20647: Run chutney tests in Jenkins
--+-
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  weasel|Sponsor:
--+-
Changes (by chelseakomlo):

 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
-+-
 Reporter:  weasel   |  Owner:
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.6
 Severity:  Normal   | Resolution:
 Keywords:  regression 029-backport  |  Actual Points:
  028-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by viktorj):

 Replying to [comment:45 arma]:
 > In particular, does Tor 0.2.7.6 behave better in the case where your Tor
 client is asleep for only an hour? It's possible that this edge case was
 never handled well (and so isn't a regression).

 Tor 0.2.7.6 behaves much better in the sense that I never ran into the
 timeout in Thunderbird, although it usually takes a bit to connect to the
 mail servers. Here is a log from August when I compared different versions
 of Tor:

 {{{
 Aug 23 12:19:28.000 [notice] Your system clock just jumped 3622 seconds
 forward; assuming established circuits no longer work.
 Aug 23 12:19:42.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Aug 23 12:19:42.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 }}}

 During the last days I always opened Thunderbird immediately after leaving
 standby and tried to connect to different mail servers, and strangely I
 didn't run into the Thunderbird timeout sometimes. Here are two examples
 of that with the shortest and the longest time of standby mode:

 {{{
 Nov 12 17:35:29.000 [notice] Your system clock just jumped 2533 seconds
 forward; assuming established circuits no longer work.
 Nov 12 17:37:35.000 [notice] No circuits are opened. Relaxed timeout for
 circuit 85 (a General-purpose client 3-hop circuit in state doing
 handshakes with channel state open) to 125338ms. However, it appears the
 circuit has timed out anyway. 13 guards are live. [2 similar message(s)
 suppressed in last 3600 seconds]
 Nov 12 17:37:37.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Nov 12 17:37:37.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.

 Nov 11 18:11:32.000 [notice] Your system clock just jumped 26150 seconds
 forward; assuming established circuits no longer work.
 Nov 11 18:12:20.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Nov 11 18:12:20.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 }}}

 But I got the timeout with shorter times of standby and with times in
 between the two above. If you are interested in more logs, I can give them
 to you.

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  028-backport, easy,  |  Actual Points:
  TorCoreTeam201611  |
Parent ID:   | Points:
 Reviewer:  teor, arma   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:23 teor]:
 > Let's get this merged, then:

 One last question -- are we sure that 0.2.9.5-alpha has correct behavior?
 :)

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

Re: [tor-bugs] #20501 [Core Tor/DocTor]: Scan 0.2.9.x relays to see if they're serving an out-of-date consensus?

[Tor Bug Tracker & Wiki]

#20501: Scan 0.2.9.x relays to see if they're serving an out-of-date consensus?
-+-
 Reporter:  arma |  Owner:  atagar
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Can we get this check integrated into doctor, e.g. once a week or once a
 month?

 Or is the better plan to get teor to run it as part of his periodic
 fallbackdir checks?

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

[tor-bugs] #20648 [Internal Services/Service - trac]: Who is the right owner for the "Tor bundles" component?

[Tor Bug Tracker & Wiki]

#20648: Who is the right owner for the "Tor bundles" component?
--+-
 Reporter:  arma  |  Owner:  qbi
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I just gave #20645 a plausible component ("tor bundles"), and it turns out
 that Erinn is the default owner of that component still. I bet she isn't
 really going to tackle all of those tickets.

 Should the component go away? Should we give it somebody else, like
 somebody from the Tor Browser team?

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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
-+-
 Reporter:  weasel   |  Owner:
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.6
 Severity:  Normal   | Resolution:
 Keywords:  regression 029-backport  |  Actual Points:
  028-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by viktorj):

 Replying to [comment:43 arma]:
 > viktorj: can you tell us about the state of your network connection
 during those 12 minutes after your PC left standby? Like, do you think you
 had a good internet connection immediately, or did it take 5 minutes?

 I think my internet connection was good because I started the Tor Browser
 during these 12 minutes (maybe 1 minute after starting Thunderbird), it
 had no problems to connect to the network immediately and I could browse
 as usual.

 I use wifi and have cable internet (~ max. 36 MBit) here in Germany. Today
 I looked at the connection speed while watching a video in Firefox after I
 left standby, and I reached about 36 MBit constantly during the background
 download of the video. I never had problems like slow internet, either it
 works fast or it doesn't work at all (sometimes for whatever reason, but
 this doesn't matter here).

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

Re: [tor-bugs] #20645 [Applications/Tor bundles/installation]: No command line ouptut under Windows 7, hence cannot get my hashed password

[Tor Bug Tracker & Wiki]

#20645: No command line ouptut under Windows 7, hence cannot get my hashed 
password
-+-
 Reporter:  sly1 |  Owner:  erinn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:  Tor:
  bundles/installation   |  0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  hashed password  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * owner:   => erinn
 * component:  - Select a component => Applications/Tor bundles/installation
 * milestone:  Tor: 0.2.8.x-final =>


Comment:

 I think on Windows you want the tor.exe from the "expert bundle" -- it is
 built to give you a window when it runs.

 That said, maybe it (the tor from the expert bundle) gives you that
 window, but the window disappears when it finishes running? I would not be
 surprised.

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

Re: [tor-bugs] #19974 [Core Tor/Tor]: Test failure for monotonic time on slow machines

[Tor Bug Tracker & Wiki]

#19974: Test failure for monotonic time on slow machines
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by s7r):

 Are we sure it occurs as described on slow machines only? Because the
 machine under my control which experienced this isn't old and shouldn't be
 so slow at all.

 I have tried with Tor process off and absolutely nothing else running on
 the machine, got two times in a row:

 {{{
 util/monotonic_time:
   FAIL src/test/test_util.c:5536: assert(usecc1 OP_LE nsecc1 / 1000 + 10):
 10601698 vs 10601677
   [monotonic_time FAILED]
 }}}

 {{{
 util/monotonic_time:
   FAIL src/test/test_util.c:5536: assert(usecc1 OP_LE nsecc1 / 1000 + 10):
 7245695 vs 7245672
   [monotonic_time FAILED]
 }}}

 3rd time it reported OK without restarting the server or any process.
 After 3 minutes 4th time again fails:
 {{{
 util/monotonic_time:
   FAIL src/test/test_util.c:5534: assert(usec1 OP_LE nsec1 / 1000 +10):
 13577362 vs 13577356
   [monotonic_time FAILED]
 }}}

 {{{
 util/monotonic_time:
   FAIL src/test/test_util.c:5534: assert(usec1 OP_LE nsec1 / 1000 +10):
 7813125 vs 7813119
   [monotonic_time FAILED]
 }}}
 Before and after each failed test I've checked the date on the machine
 against a time server and it was synced exactly.

 I think we can eliminate the variant that the Tor process hangs, as
 described in
 https://trac.torproject.org/projects/tor/ticket/20423#comment:21 because
 as we see it happens even when Tor isn't actually running as a process on
 the server. Tried several times on another machine running Debian but got
 OK result every time.

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

Re: [tor-bugs] #16706 [Core Tor/Tor]: Too many connection_edge_process_relay_cell warnings

[Tor Bug Tracker & Wiki]

#16706: Too many connection_edge_process_relay_cell warnings
-+-
 Reporter:  s7r  |  Owner:  arma
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.10
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 026-backport, nickm- |  Actual Points:
  deferred-20161017  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by s7r):

 Yes, this is true and confirmed (comment 3 on this ticket). What I think
 we should do is discover why this log message is printed when the
 described event occurs and see if it causes any load over the Tor process.
 Requests on non-configured virtual ports should be discarded in a way that
 spends the lowest amount of resources possible.

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

Re: [tor-bugs] #20647 [- Select a component]: Run chutney tests in Jenkins

[Tor Bug Tracker & Wiki]

#20647: Run chutney tests in Jenkins
--+-
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  weasel|Sponsor:
--+-

Comment (by chelseakomlo):

 After a short chat with weasel, we talked about:

 1. Docker doesn't fit into our current setup but the ideas from the docker
 file should translate well
 2. Chutney tests should be their own task
 3. Ideally we will use the tor binary that has already been built in prior
 tasks
 For 3, it looks like the location of the tor binary needs to be set by the
 environment variable CHUTNEY_TOR

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

Re: [tor-bugs] #20539 [Core Tor/Tor]: Make sure fallback directories aren't running buggy versions / can deliver a recent consensus

[Tor Bug Tracker & Wiki]

#20539: Make sure fallback directories aren't running buggy versions / can 
deliver
a recent consensus
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:  #18828| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 #20501 has a listing of relays with this issue and a small script to check
 if relays are serving a stale consensus or not. If you wrap that check
 into your fallback selection script ya should be good to go.

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

Re: [tor-bugs] #20501 [Core Tor/DocTor]: Scan 0.2.9.x relays to see if they're serving an out-of-date consensus?

[Tor Bug Tracker & Wiki]

#20501: Scan 0.2.9.x relays to see if they're serving an out-of-date consensus?
-+-
 Reporter:  arma |  Owner:  atagar
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by atagar):

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


Comment:

 Gonna resolve this. Feel free to reopen if you need anything else.

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

Re: [tor-bugs] #13386 [Core Tor/Tor]: "opening new log file" line goes to err-logfile despite being at loglevel notice

[Tor Bug Tracker & Wiki]

#13386: "opening new log file" line goes to err-logfile despite being at 
loglevel
notice
--+--
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 I'm not a fan of changing the log line format but I'm not coming up with a
 better option. Making these lines special is a minor headache for parsers
 and things like the following...

 {{{
 % cut -d ' ' -f 4 ~/.tor/log | sort | uniq -c | sort -nr
   20803 [warn]
   13692 [notice]
7832 [debug]
 135 [info]
  33 [err]
   2 /lib/i386-linux-
 gnu/libcrypto.so.1.0.0(OPENSSL_cleanse+0x32)[0xb723a5b2]
   2
   1 tor(+0x14826e)[0xb760b26e]
   1 died:
 }}}

 From the above we evidently already have multi-line log entries so kinda
 already crossed that bridge...

 {{{
 Jul 09 08:28:28.000 [notice] No circuits are opened. Relaxed timeout for
 circuit 4708 (a Testing circuit 3-hop circuit in state doing handshakes
 with channel state open) to 6ms. However, it appears the circuit has
 timed out anyway. 2 guards are live. [23 similar message(s) suppressed in
 last 3600 seconds]

  T= 1468078946
 Tor 0.2.9.0-alpha-dev (git-44ea3dc3311564a9) died: Caught signal 11
 tor(+0x14826e)[0xb760b26e]
 /lib/i386-linux-gnu/libcrypto.so.1.0.0(OPENSSL_cleanse+0x32)[0xb723a5b2]
 /lib/i386-linux-gnu/libcrypto.so.1.0.0(OPENSSL_cleanse+0x32)[0xb723a5b2]
 }}}

 Options that have come up thus far seem to be...

 * Drop these lines. This is a no-go because we need some sentinel to
 indicate when logging starts for a new tor instance.
 * Change these lines to [err] (or whatever the log has). This doesn't make
 sense. For instance, if I have "Log bw file /var/log/tor/bw.log" would we
 log these as bandwidth events?
 * Use special lines as suggested above. Not great, but livable.
 * Leave this unfixed, sending the notice to all log files.

 Other ideas welcome but of the above either the special lines or leaving
 this unfixed have my vote. As sucky as these are the other options are
 even worse.

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

Re: [tor-bugs] #20647 [- Select a component]: Run chutney tests in Jenkins

[Tor Bug Tracker & Wiki]

#20647: Run chutney tests in Jenkins
--+-
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  weasel|Sponsor:
--+-

Comment (by chelseakomlo):

 If we wanted to use docker for this, I did a proof of concept here:
 `g...@github.com:chelseakomlo/tor-integration-ci.git`, master branch

 We can also test using different OS/versions as we do with unit tests.

 This runs both stem and chutney tests, but I see that we already have a
 stem task in jenkins, so I can change this to run only chutney tests if we
 want to keep them separate.

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

Re: [tor-bugs] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

[Tor Bug Tracker & Wiki]

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by chelseakomlo):

 Replying to [comment:3 cypherpunks]:
 > Replying to [ticket:20458 chelseakomlo]:
 > > 2. Adding a make task that runs all necessary tasks before
 contributing new code
 > `make check` is the default target for running tests so I'd move every
 test under this target. This will also make the jenkins builds run these
 tests automatically, making catching issues easier.

 I think the issue with Jenkins running `make check` for the entire test
 suite is that chutney tests are currently non-deterministic. Until we feel
 confident in the output from chutney tests, we should keep running these
 as a seperate task so that we have confidence when the build passes or
 fails.

 Agreed that this should be the ultimate goal, but eliminating flakiness in
 chutney tests is currently a blocker.

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

Re: [tor-bugs] #20220 [Applications/Tor Browser]: TorBrowser cannot connect on Windows 10

[Tor Bug Tracker & Wiki]

#20220: TorBrowser cannot connect on Windows 10
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I don't think it's any anti-malware software since previous version work
 just fine.

 I was able to work around the issue by installing it on another machine
 and then copying that directory to the Windows 10 64-bit laptop.

 Is there something special or different about how tor starts up the first
 time?

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

[tor-bugs] #20647 [- Select a component]: Run chutney tests in Jenkins

[Tor Bug Tracker & Wiki]

#20647: Run chutney tests in Jenkins
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:  weasel
  Sponsor:|
--+
 It would be nice for chutney tests to be run on every build.

 However, because chutney tests cannot be entirely deterministic (although
 we can do more work to get them closer), this probably should not block
 the build if tests fail (at least for the short term & we eliminate as
 much flakiness as possible).

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

Re: [tor-bugs] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  028-backport, easy,  |  Actual Points:
  TorCoreTeam201611  |
Parent ID:   | Points:
 Reviewer:  teor, arma   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:22 arma]:
 > The ticket20509_029 branch seems to work as expected on moria1.

 I've tested `ticket20509_028`, `ticket20509_029`, and `ticket20509` on the
 test network and they all behave as expected.

 Let's get this merged, then:
 * `ticket20509_028` to 0.2.8
 * `ticket20509_029` to 0.2.9 and then merge 0.2.9 to master

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

[tor-bugs] #20646 [Core Tor/Tor]: finish_writing_to_file_impl() should remove temporary file if replacing an existing one failed

[Tor Bug Tracker & Wiki]

#20646: finish_writing_to_file_impl() should remove temporary file if replacing 
an
existing one failed
--+
 Reporter:  fk|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.5-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Functions like start_writing_to_file() rely on
 finish_writing_to_file_impl() to remove the temporary
 file if replacing an already existing one failed.

 Currently this doesn't happen. The attached patch fixes this.

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

[tor-bugs] #20645 [- Select a component]: No command line ouptut under Windows 7, hence cannot get my hashed password

[Tor Bug Tracker & Wiki]

#20645: No command line ouptut under Windows 7, hence cannot get my hashed 
password
--+
 Reporter:  sly1  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  - Select a component  |Version:  Tor: 0.2.8.7
 Severity:  Normal|   Keywords:  hashed password
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tried
 > tor --hash-password "my_password"
 and got no ouput whatsoever. Also this is the case with
 > tor -h
 and any other command, for that matter. Tor was bundled with last "tor
 browser bundle", Version 6.0.5 (2016-09-16) for Windows 10, 8, 7, Vista,
 and XP.
 Log file says it's Tor 0.2.8.7
 Running as administrator.

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

Re: [tor-bugs] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

[Tor Bug Tracker & Wiki]

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by chelseakomlo):

 Great, thanks! Will do.

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

Re: [tor-bugs] #19898 [Applications/Tor Browser]: Use default search in about:tor in our alpha builds

[Tor Bug Tracker & Wiki]

#19898: Use default search in about:tor in our alpha builds
--+--
 Reporter:  f451022   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201611  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Note: make sure this works with JS disabled as well.

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

Re: [tor-bugs] #20414 [Applications/Tor Browser]: Donation banner on about:tor page for 2016 campaign

[Tor Bug Tracker & Wiki]

#20414: Donation banner on about:tor page for 2016 campaign
-+
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201611R, crowdfunding  |  Actual Points:
Parent ID:  #20413   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by gk):

 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Fixed with 2f8570e04f2465710b02abaf1e0cfd3059580134 (master) and
 1a79b90c4cf41558d2b637b6314e0c64338d158d (maint-1.9.5).

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

[tor-bugs] #20644 [Applications/TorBirdy]: torbirdy/thunderbird opens html-attachment in thunderbird and loads content from the internet

[Tor Bug Tracker & Wiki]

#20644: torbirdy/thunderbird opens html-attachment in thunderbird and loads 
content
from the internet
---+--
 Reporter:  cypherpunks|  Owner:  sukhbir
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/TorBirdy  |Version:  Tor: unspecified
 Severity:  Critical   |   Keywords:  HTML,
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I tried to send a news-message from an rss-feed by e-mail, so I put the
 rss-feed-message into the attachment area and than clicked on the
 attachment (mail wasn't send yet) (the rss-feed is displayed as plain
 text) but if I click on the the attachment it's opened as html like in a
 browser (but in Thunderbird) and even the images are loaded and displayed.

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

Re: [tor-bugs] #20643 [Internal Services/Service - deb.tpo]: make and maintain a registry of what debs are on deb.tp.o and why

[Tor Bug Tracker & Wiki]

#20643: make and maintain a registry of what debs are on deb.tp.o and why
-+-
 Reporter:  arma |  Owner:  hiro
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Oh, and for extra credit, we could figure out what our current policy is
 for adding new ones (I suspect it is "badger weasel until he says it's ok,
 and then later when you don't maintain your debs he regrets it"), and
 figure out an improved policy (like, something about having a sponsor who
 is a core tor contributor), and write it down for people.

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

Re: [tor-bugs] #20643 [Internal Services/Service - deb.tpo]: make and maintain a registry of what debs are on deb.tp.o and why

[Tor Bug Tracker & Wiki]

#20643: make and maintain a registry of what debs are on deb.tp.o and why
-+-
 Reporter:  arma |  Owner:  hiro
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * owner:  weasel => hiro
 * status:  new => assigned


Comment:

 I'm giving this one to hiro since I bet weasel is unexcited to do it.

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

[tor-bugs] #20643 [Internal Services/Service - deb.tpo]: make and maintain a registry of what debs are on deb.tp.o and why

[Tor Bug Tracker & Wiki]

#20643: make and maintain a registry of what debs are on deb.tp.o and why
-+
 Reporter:  arma |  Owner:  weasel
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 We've accumulated a variety of debs on deb.tp.o, with a variety of
 maintainers. I think the knowledge of who these people are is not recorded
 well.

 Step one, we should figure out who is in charge of each of the debs that's
 there. For example, is the pyptlib deb there because of one of the obfs
 debs? Or is it leftover from something and nobody needs it anymore?
 Similarly, is tor-arm there because it got brought in as a dependency
 to...something else that's there?

 Then step two, we should write all of that in one place (a page on this
 wiki? a text file in the deb.tp.o root? someway else?), and make sure that
 those people know that they have the responsibility to keep their debs up
 to date, or to decide to take them down when they're no longer needed.

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

Re: [tor-bugs] #20642 [Internal Services/Service - trac]: rename "Internal Services" trac component to "Infrastructure"?

[Tor Bug Tracker & Wiki]

#20642: rename "Internal Services" trac component to "Infrastructure"?
--+-
 Reporter:  arma  |  Owner:  qbi
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 weasel points out that this ticket "will involve modifying all the
 tickets", "probably using database magic".

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

Re: [tor-bugs] #20642 [Internal Services/Service - trac]: rename "Internal Services" trac component to "Infrastructure"?

[Tor Bug Tracker & Wiki]

#20642: rename "Internal Services" trac component to "Infrastructure"?
--+-
 Reporter:  arma  |  Owner:  qbi
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Oh, I should say that this ticket came about because weasel hates the name
 Internal Services, and he admitted to me that Infrastructure sounded
 better.

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

[tor-bugs] #20642 [Internal Services/Service - trac]: rename "Internal Services" trac component to "Infrastructure"?

[Tor Bug Tracker & Wiki]

#20642: rename "Internal Services" trac component to "Infrastructure"?
--+-
 Reporter:  arma  |  Owner:  qbi
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 It is weird that trac and deb.tpo and so on are labelled Internal. They're
 outside-facing, just for a different audience.

 What would happen if we named the top level component Infrastructure
 instead?

 I cc Isabela since she was involved in the last big renaming, and I cc
 hiro because I should just start doing that for all the tickets like this.
 :)

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

[tor-bugs] #20641 [Internal Services/Service - deb.tpo]: Remove obsolete polipo and vidalia debs from deb.tp.o

[Tor Bug Tracker & Wiki]

#20641: Remove obsolete polipo and vidalia debs from deb.tp.o
-+--
 Reporter:  arma |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 http://deb.torproject.org/torproject.org/pool/main/p/polipo/
 and
 http://deb.torproject.org/torproject.org/pool/main/v/vidalia/
 are still served from our deb.p.o, but nobody should be using those.

 We should remove them.

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

Re: [tor-bugs] #20616 [Internal Services/Service - deb.tpo]: obfs4proxy package on deb.tp.o is out of date?

[Tor Bug Tracker & Wiki]

#20616: obfs4proxy package on deb.tp.o is out of date?
-+-
 Reporter:  arma |  Owner:  lunar
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * component:  Obfuscation/Obfsproxy => Internal Services/Service - deb.tpo


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

Re: [tor-bugs] #20616 [Obfuscation/Obfsproxy]: obfs4proxy package on deb.tp.o is out of date?

[Tor Bug Tracker & Wiki]

#20616: obfs4proxy package on deb.tp.o is out of date?
---+--
 Reporter:  arma   |  Owner:  lunar
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Also, when we figure out the answer for obfs4proxy, I'll be asking the
 same question about the obfsproxy package there. :)

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

Re: [tor-bugs] #20616 [Obfuscation/Obfsproxy]: obfs4proxy package on deb.tp.o is out of date?

[Tor Bug Tracker & Wiki]

#20616: obfs4proxy package on deb.tp.o is out of date?
---+--
 Reporter:  arma   |  Owner:  lunar
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * owner:  asn => lunar
 * status:  new => assigned


Comment:

 
http://deb.torproject.org/torproject.org/pool/main/o/obfs4proxy/obfs4proxy_0.0.4-1~tpo1.dsc
 makes me think that Lunar might be the right person to ask.

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

[tor-bugs] #20640 [- Select a component]: PROBLÈME CONNEXION

[Tor Bug Tracker & Wiki]

#20640: PROBLÈME CONNEXION
--+-
 Reporter:  jamesr10100   |  Owner:
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 JE NE PEUX PLUS ME CONNECTER AU RÉSEAU TOR MESSAGE AFFICHÉ "LA MISE À JOUR
 À ECHOUÉE DES PROBLÈMES ONT ÉTÉ RENCONTRÉS LORS DE LA
 VÉRIFICATON,TÉLÉCHARGEMENT,OU DE L'INSTALLATION DE CETTE MISE À JOUR.TOR
 N'A PU ÊTRE MISE À JOUR SUITE A:FICHIER XML DE MISE À JOUR MAL FORMÉ
 (200).

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