Re: [tor-bugs] #24862 [Metrics/Consensus Health]: Add per-relay descriptor timestamps to the consensus health detailed page

[Tor Bug Tracker & Wiki]

#24862: Add per-relay descriptor timestamps to the consensus health detailed 
page
--+---
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by tom):

 I take it back. I deployed this and noticed quite a few instances of this
 pseudoflag; so it does seem to turn up cases where the consensus timestamp
 doesn't match the vote timestamp.

--
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] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-

Comment (by catalyst):

 I just noticed that there might be a race condition if the time of day
 changes its seconds value between the calls to `tor_gettimeofday()` and
 `getinfo_helper_current_time()`.  Maybe this happens rarely enough in
 practice that it won't be a problem.

 If it is a problem, mocking `tor_gettimeofday()` to return a fixed value
 might be the best solution.

--
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] #25581 [Core Tor/Tor]: Inconsistent underscore config options (for vanguard options)

[Tor Bug Tracker & Wiki]

#25581: Inconsistent underscore config options (for vanguard options)
-+-
 Reporter:  atagar   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  regression, 033-must,|  Actual Points:
  033-triage-20180326, 033-included-20180326 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by mikeperry):

 At the roadmap meeting in Rome, we agreed to proceed with Story 2 for
 0.3.4.

--
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] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---

Comment (by pospeselr):

 As mentioned by cypherpunks, the issue here only occurs on the main thread
 which you can verify with a little spelunking through the glibc source.
 The relevant query APIs work expected on non-main threads since pthreads
 populates the required info in memory.

 Verifying a patch now on TreeHerder that fixes this issue by reading the
 __libc_stack_end symbol (glibc sets this void* to the first stack frame
 during program init).  Solution suggested by mozilla's jld, and the folks
 in #jsapi (those paying attention at least) didn't seem offended at the
 idea of doing so for the main thread.

--
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] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
-+-
 Reporter:  isis |  Owner:
 |  ffmancera
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-32, review-group-34, |
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

 * status:  reopened => needs_review


Comment:

 Okay, this part is done in my `bug24658-rand`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug24658-rand
 branch] ([https://travis-ci.org/isislovecruft/tor/builds/363342259 Travis
 passes]).

--
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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by uzi):

 * Attachment "Step2.png" added.

 Un-stalled again

--
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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by uzi):

 * Attachment "Step1.png" added.

 Stalled browser loading Facebook

--
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] #25735 [Applications/Tor Browser]: Tor Browser stalls while loading Facebook login page (Waiting for static.xx.fbcdn.net)

[Tor Bug Tracker & Wiki]

#25735: Tor Browser stalls while loading Facebook login page (Waiting for
static.xx.fbcdn.net)
--+--
 Reporter:  uzi   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Problem:
 After opening the Tor Browser and typing in facebook.com, page loading
 hangs, status bar showing "Waiting for static.xx.fbcdn.net"

 HTTP GET requests for small images from static.xx.fbcdn.net stall in the
 "Blocked" state for minutes - viewed in Developer tools / Network /
 request / Timing (see attached screenshot Step2.png).

 When a different website is opened in a new tab, HTTP requests continue
 loading successfully - seems to be some livelock within the browser.

 This is **not a network issue**, connectivity in the browser works fine,
 also verifed without a SOCKS proxy (direct connection without Tor).

 Reproducibility: nearly 100%

 Environment:
 - Windows 10 Pro, 64bit
 - Tor Browser 7.5.3 for Windows, english
 - Tor Browser 8.0a5 for Windows, english

--
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] #25400 [Core Tor/Tor]: CIRC_BW event miscounts, should count all circ data

[Tor Bug Tracker & Wiki]

#25400: CIRC_BW event miscounts, should count all circ data
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-stats, review-group-34, 034  |  Actual Points:
  -roadmap-subtask, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25546   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:9 dgoulet]:
 > Good stuff Mike. I want to ask and clarify couple of things here.
 >
 > 1. Why not put this counting in `command_process_relay_cell()`? I'm
 asking because that function, before calling
 `circuit_receive_relay_cell()` can close the circuit because of invalid
 `RELAY_EARLY` cell or too many of them or if cells are received but the
 circuit state doesn't allow it. Don't you want to catch those also in your
 calculation? Looking at this comment, it seems you might?

 Actually, yes, let's move this block up towards the top of
 circuit_receive_relay_cell(). I had put it below since those violations
 closed the circuit, but you're right, let's count them too. Thanks!

 
https://oniongit.eu/mikeperry/tor/commit/4371b54854545a3962f9455fe318711dc7b799f9

 > {{{
 > +  /* Count all circuit bytes here for control port accuracy. We want
 > +   * to count even invalid/dropped relay cells, hence counting
 > +   * before the recognized check and the connection_edge_process_relay
 > +   * cell checks.
 > }}}
 >
 > 2. The `CELL_PAYLOAD_SIZE`, as you stated in your previous comment,
 doesn't take into account the header size but that header _can_ bring the
 cell size up to 514 bytes (`CELL_MAX_NETWORK_SIZE`). I'm not sure I
 understand the reasoning behind not counting the header. You mention that
 the controller application should subtract the header size but it really
 shouldn't if tor is not counting them in the first place? Actually, the
 cell size can vary depending on the use of "wide circ ids" so shouldn't
 `get_cell_network_size(chan->wide_circ_ids)` be used instead of
 `CELL_PAYLOAD_SIZE`?

 I'm using the definition of "total bandwidth carried by the circuit". This
 means that the payload size is the natural value here. For purposes of the
 payload carried, it does not matter if the *circuit* headers are different
 sizes. My earlier comment was about *relay* headers, which are part of the
 (encrypted) circuit payload, and I think should be counted in this stat.

 > 3. The counting bytes code for read/written is really the same so I
 would be much happier with a function that does that and could take a
 pointer to `n_read_circ_bw` or `n_written_circ_bw` for the calculation (or
 not a pointer, just return the new value). Seems to me will be easier to
 unit test but also better code semantic as well.

 Good point. I made this u32 overflow add into a util.c helper, since it is
 a common pattern, independent of this circuit accounting:

 
https://oniongit.eu/mikeperry/tor/commit/b9f28f475ecc546503bd85d1d4a0564f09b638a3
 (impl + tests)
 
https://oniongit.eu/mikeperry/tor/commit/4e86178122c7aa20af91838c59ee5dd6fe6bb7d5
 (use)

--
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] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---

Comment (by yawning):

 Replying to [comment:16 cypherpunks]:
 > I suspect that glibc relies on /proc only for the initial thread.

 Yes.

 > it is possible that
 >
 > {{{
 > ucontext_t uc;
 > void *base;
 > size_t size;
 >
 > if (getcontext() == -1)
 >   err(1, "getcontext");
 > base = uc.uc_stack.ss_sp;
 > size = uc.uc_stack.ss_size;
 > }}}
 >
 > will recover the stack base address and size that you want.

 99% sure this does not work without /proc mounted.

--
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] #25731 [Applications/Tor Browser]: windows hidden service bug

[Tor Bug Tracker & Wiki]

#25731: windows hidden service bug
--+--
 Reporter:  Ga15  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Ga15):

 Replying to [comment:2 arma]:
 > Did a previous Tor Browser work for this situation? With exactly the
 same paths?
 Yes
 > Do your xxx or yyy have any weird characters in them? (spaces, utf-8
 characters, umlauts, etc)
 It had but I have tried one without them.
 > Did anything change in your antivirus or firewall settings? Have you
 tried turning those off?
 No as I know.
 Replying to [comment:3 teor]:
 > What was the last working Tor Browser version?
 Sorry I use the hidden service for p2p chat and now I wasn't online for
 something like month so I don't remember the version.

 Can somebody confirm bug? If it is just me I will take deeper look on what
 changed and then give reply when I found what it was.

--
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] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.

[Tor Bug Tracker & Wiki]

#20283: Tor Browser should run without a `/proc` filesystem.
--+---
 Reporter:  yawning   |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #20773| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 From conversation with pospeselr:

 I suspect that glibc relies on /proc only for the initial thread.  It is
 possible that for the initial thread you can get the stack base address
 and size using getcontext(2).  In particular, if pthread_getattr_np fails
 or pthread_attr_getstack returns null, and the thread in question is the
 process's initial thread, then it is possible that

 {{{
 ucontext_t uc;
 void *base;
 size_t size;

 if (getcontext() == -1)
 err(1, "getcontext");
 base = uc.uc_stack.ss_sp;
 size = uc.uc_stack.ss_size;
 }}}

 will recover the stack base address and size that you want.

--
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] #25734 [- Select a component]: фен

[Tor Bug Tracker & Wiki]

#25734: фен
--+
 Reporter:  Alexey*ka07   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   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] #25705 [Core Tor/Tor]: Refactor circuit_build_failed to separate build vs path failures

[Tor Bug Tracker & Wiki]

#25705: Refactor circuit_build_failed to separate build vs path failures
--+--
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25546| Points:
 Reviewer:|Sponsor:  SponsorV-can
--+--

Comment (by mikeperry):

 How about a log_fn_ratelim(LOG_NOTICE/LOG_WARN) here instead of the info
 log, then? This is not something that should happen unless the user is
 doing something crazy in torrc, or there is another bug (such as not
 having enough mds and never getting more). In each case they/we want to
 know that it happened, and I also think that not giving up in these cases
 is a good move, even if it costs a bit of spinning.

--
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] #25733 [Core Tor/Tor]: Bug: Could not determine largest build time (0). Xm is 3925ms and we've abandoned 999 out of 1000 circuits.

[Tor Bug Tracker & Wiki]

#25733: Bug: Could not determine largest build time (0). Xm is 3925ms and we've
abandoned 999 out of 1000 circuits.
--+---
 Reporter:  cstest|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.10
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Server running couple of hundred HS domains. Tor crashed. One spammer is
 trying simple DDoS.



 Apr 06 20:36:28.000 [notice] Received reload signal (hup). Reloading
 config and resetting internal state.
 Apr 06 20:36:28.000 [notice] Read configuration file
 "---".
 Apr 06 20:36:28.000 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) opening
 log file.
 Apr 06 20:36:42.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Apr 06 20:36:42.000 [warn] Error launching circuit to node
 $F0F5074A6DADD3DC22E1FAA18FD6D89C at - for service
 ---.
 Apr 06 20:36:56.000 [warn] Your Guard remedy
 ($3FEBFB6A491D30CACC2C2995EDB41717A6F94E95) is failing a very large amount
 of circuits. Most likely this means the Tor network is overloaded, but it
 could$
 Apr 06 20:36:59.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Apr 06 20:37:26.000 [warn] Your Guard AlienZone
 ($80392DC1522E647C56457CEBA58DD84CC56AEC44) is failing a very large amount
 of circuits. Most likely this means the Tor network is overloaded, but it
 co$
 Apr 06 20:37:29.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Apr 06 20:37:29.000 [warn] Error launching circuit to node
 $9AEF164F5BE5618509C9E60--- at  for service
 ---.
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 996
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 997
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 998
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 3925ms and we've abandoned 999
 out of 1000 circuits. (on Tor 0.3.2.10 )
 Apr 06 20:37:49.000 [warn] circuit_build_times_update_alpha(): Bug: Could
 not determine largest build time (0). Xm is 

Re: [tor-bugs] #25511 [Core Tor/Tor]: Expose TZ info on control port for better debugging of time errors

[Tor Bug Tracker & Wiki]

#25511: Expose TZ info on control port for better debugging of time errors
-+-
 Reporter:  nickm|  Owner:  neel
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  roadmap, controller, 034-roadmap-|  Actual Points:
  master, 034-triage-20180328,   |
  034-included-20180328, s8-errors   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8
-+-

Comment (by catalyst):

 On Linux, Tor Browser "7.5a8 (based on Mozilla Firefox 52.5.0) (64-bit)"
 with a custom config to log to a file on disk, the log file shows local
 time stamps but the "Copy Tor Log To Clipboard" button shows UTC time
 stamps.  The disk files have log levels in lowercase, while the clipboard
 logs have them in uppercase.  These imply that Tor Launcher might be
 postprocessing logs a little, or might be using control channel events to
 get log messages.

--
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] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:7 arma]:
 > I think three steps remain here:
 >
 > (1) David and Arlo should each confirm

 Done

 > (2) Build a plan for how we want to handle website content

 Also done: Arlo's got one already.

 > (3) Actually pick the content

 I'll let you two take it from here. Feel free to close the ticket when
 you've got a website up. Or note any further problems 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] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:9 arlolra]:
 > There's https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy/static

 Well awesome.

 The way I do it with research-web is that I do a git clone in my homedir
 on staticiforme and then I do a git pull and cp stuff manually into /srv/

 Ya'll're welcome to do it that way too, or you could come up with some
 slightly more automated approach like a script that takes a git checkout
 as input and arranges stuff into /srv/ the way you like.

--
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] #21777 [Applications/Tor Browser]: Investigate cross-compiling Tor Browser for Windows with clang-cl

[Tor Bug Tracker & Wiki]

#21777: Investigate cross-compiling Tor Browser for Windows with clang-cl
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201803, GeorgKoppen201804|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * cc: dcf (added)


Comment:

 Copying myself because we're likely to want to use this clang-cl for
 cross-compiling libwebrtc too, in #25483.

--
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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  sbs
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328 034-included-20180402 034  |
  -roadmap-subtask   |
Parent ID:  #25510   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 Replying to [comment:21 nickm]:
 >   * Does "make distcheck" still work?  (It does without Rust.  But with
 Rust, "make distcheck" appears to be broken in master already without this
 patch. Fixing.)

 Did that part in #25732

--
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] #25732 [Core Tor/Tor]: Rust files not all included with Tor.

[Tor Bug Tracker & Wiki]

#25732: Rust files not all included with Tor.
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  033-must fast-fix  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Fixed in 2fac948158f50ed062a059def81da632b1d8ce18 and
 306563ac68250872791350bda1ba7a7acff5eb63

--
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] #25732 [Core Tor/Tor]: Rust files not all included with Tor.

[Tor Bug Tracker & Wiki]

#25732: Rust files not all included with Tor.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  033-must fast-fix
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We broke our "make dist" when we added strings.rs, and it remains broken
 now.  We need to include all of our .rs files in our tarball, or we can't
 build.

--
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] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Replying to [comment:8 arma]:
 > Replying to [comment:7 arma]:
 > > (1) David and Arlo should each confirm that they are able to edit the
 current website.

 Thanks for the instructions. It worked for me. ❄️

 > Oh, and if while doing it you find bugs with the help.tpo tsa pages,
 here's the place to fix them:
 > https://gitweb.torproject.org/project/help/wiki.git/tree/tsa/doc

 I hit one little snag. I wanted to check the fingerprint of staticiforme.
 But ssh shows a hash of the public key and
 https://db.torproject.org/machines.cgi?host=staticiforme shows the
 unhashed key:
 {{{
 The authenticity of host 'staticiforme.torproject.org ()' can't be established.
 ED25519 key fingerprint is
 SHA256:Zey+40am+p8jbz6QMUkVNzpxvSkGGGKE8EB5Oxqiw1w.
 }}}
 {{{
 ssh-ed25519
 C3NzaC1lZDI1NTE5INaYC2kGzFeqQtmZp7UGYjqxcymHn9ujYlKBbf1x6pnF
 root@staticiforme
 }}}
 There is probably some `ssh` option or subcommand I could have used, but
 it turns out that hashing it manually works.
 {{{
 >>>
 
hashlib.sha256("C3NzaC1lZDI1NTE5INaYC2kGzFeqQtmZp7UGYjqxcymHn9ujYlKBbf1x6pnF".decode("base64")).digest().encode("base64")
 'Zey+40am+p8jbz6QMUkVNzpxvSkGGGKE8EB5Oxqiw1w=\n'
 }}}

--
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] #23846 [Core Tor/Tor]: Use libtool for building shared library

[Tor Bug Tracker & Wiki]

#23846: Use libtool for building shared library
-+-
 Reporter:  hellais  |  Owner:  sbs
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328 034-included-20180402 034  |
  -roadmap-subtask   |
Parent ID:  #25510   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 So, I've looked over the codebase and made a couple of changes in a branch
 called "libtool_hack", including a workaround for the Rust warning issue.
 (It's only a plausible legitimate workaround if Rust builds with -fPIC
 though -- does it?)

 Here are the open issues I want to check, if we can:
   * Does this work on windows? (Only the Makefile.am build is supported)
   * Does "make distcheck" still work?  (It does without Rust.  But with
 Rust, "make distcheck" appears to be broken in master already without this
 patch. Fixing.)
   * How horrible is the above Rust hack?

 One other issue here is that since none of the library are installed, no
 real shared libraries are actually built.   (You can verify this yourself
 by noticing that no .so files are created anywhere.)  I'm _thinking_ that
 this is intentional, but I'm

--
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] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arlolra):

 > (1) David and Arlo should each confirm that they are able to edit the
 current website.

 Works for me.

 > (2) Build a plan for how we want to handle website content. Do we want
 it in revision control?

 There's https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy/static

--
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] #25731 [Applications/Tor Browser]: windows hidden service bug

[Tor Bug Tracker & Wiki]

#25731: windows hidden service bug
--+--
 Reporter:  Ga15  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * owner:  (none) => tbb-team
 * version:  Tor: unspecified =>
 * component:  - Select a component => Applications/Tor Browser
 * milestone:  Tor: unspecified =>


Comment:

 What was the last working Tor Browser version?

--
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] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 |  ffmancera
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debt, tor-dirauth, pending-disaster, review-   |
  group-32, review-group-34, |
  034-triage-20180328|
Parent ID:   | Points:  small
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Maybe we should just rely on comments here?
 Or, as an alternative, when we create our C-Rust coupled tool, let's make
 it do C-C coupled warnings 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] #24853 [Core Tor/Tor]: backport the new authority and fallback file formats

[Tor Bug Tracker & Wiki]

#24853: backport the new authority and fallback file formats
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, 029-backport, |  Actual Points:
  031-backport, 032-backport, 033-backport,  |
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24818   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 torspec, tor-auth, 029-backport, 030-backport-maybe, 031-backport,
 032-backport, 034-triage-20180328, 034-removed-20180328
 =>
 torspec, tor-auth, 029-backport, 031-backport, 032-backport,
 033-backport, 034-triage-20180328, 034-removed-20180328


Old description:

> * create an authority file in the new format
> * make tor include that file
> * create a fallback file in the new format
> * backport them to all supported tor releases:
>   * authorities: ~~0.2.5 (EOL 1 May 2018),~~ 0.2.9, 0.3.0 (EOL 1 Feb
> 2018), 0.3.1, 0.3.2
>   * fallbacks: 0.2.9, 0.3.0 (EOL 1 Feb 2018), 0.3.1, 0.3.2
> * make sure all supported tor releases parse the files correctly (unit
> tests)

New description:

 After doing #24851 and #24852.
 * backport them to all supported tor releases:
   * authorities: ~~0.2.5 (EOL 1 May 2018),~~ 0.2.9, ~~0.3.0 (EOL 1 Feb
 2018),~~ 0.3.1, 0.3.2, 0.3.3
   * fallbacks: 0.2.9, ~~0.3.0 (EOL 1 Feb 2018),~~ 0.3.1, 0.3.2, 0.3.3
 * make sure all supported tor releases parse the files correctly (unit
 tests)

--

Comment:

 This ticket depends on #24851 and #24852.

--
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] #24854 [Core Tor/Tor]: Extract the authority list from config.c

[Tor Bug Tracker & Wiki]

#24854: Extract the authority list from config.c
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-dirauth, 029-backport,  |  Actual Points:
  031-backport, 032-backport, 033-backport,  |
  review-group-32, review-group-33, review-  |
  group-34, 034-triage-20180328  |
Parent ID:  #24818   | Points:  0.2
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by teor):

 * keywords:
 torspec, tor-dirauth, 029-backport, 031-backport, 032-backport,
 review-group-32, review-group-33, review-group-34, 034-triage-20180328
 =>
 torspec, tor-dirauth, 029-backport, 031-backport, 032-backport,
 033-backport, review-group-32, review-group-33, review-group-34,
 034-triage-20180328
 * status:  merge_ready => needs_revision


Comment:

 Oh, this branch needs to be based on 0.2.9, because it will be backported
 to 0.2.9, 0.3.1, 0.3.2, and 0.3.3.

--
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] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability

[Tor Bug Tracker & Wiki]

#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs prop224 034-roadmap-proposed  |  Actual Points:
Parent ID:   | Points:  4
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:4 arma]:
 > Replying to [ticket:25552 asn]:
 > > b) In the far future, when all HSDirs have upgraded to (a), rip out
 the rev counter code from onion services.
 >
 > As I understand it, HSDirs learned how to handle v3 descriptors in
 0.3.0.1-alpha, as part of #17238.
 >
 > According to
 >
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Listofreleases
 > Tor 0.3.0 is already dead. And importantly, the feature isn't in our
 long-term-stable 0.2.9.
 >
 > So as long as we get the new functionality into HSDirs before the next
 long-term-stable, the "far future" will just be a matter of waiting some
 months for intermediate stable versions to die out.

 But hang on, do clients require descriptors to have revision counters?
 If so, we can't rip out revision counters on services for a long time.

 But we can make HSDirs and clients ignore 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] #25731 [- Select a component]: windows hidden service bug

[Tor Bug Tracker & Wiki]

#25731: windows hidden service bug
--+--
 Reporter:  Ga15  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * priority:  High => Medium
 * severity:  Major => Normal


Comment:

 Did a previous Tor Browser work for this situation? With exactly the same
 paths?

 Do your xxx or yyy have any weird characters in them? (spaces, utf-8
 characters, umlauts, etc)

 Did anything change in your antivirus or firewall settings? Have you tried
 turning those off?

--
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] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:7 arma]:
 > (1) David and Arlo should each confirm that they are able to edit the
 current website. I am able to, so it's just a matter of making sure
 they're in the right groups and have the right permissions and so on. I'll
 post instructions for that shortly.

 Here's what I did, using https://help.torproject.org/tsa/doc/static-sites/
 as my cheat-sheet:

 (0) Have an ssh key set up for my Tor ldap account. Hopefully you have
 both done this already for other reasons.

 (1) ssh staticiforme.torproject.org, using cupani.torproject.org as my
 jump host:
 https://help.torproject.org/tsa/doc/ssh-jump-host/

 (2) cd /srv/snowflake.torproject.org/htdocs/ and edit index.html to say
 "Hi mom" or whatever you want for your test.

 (3) Run "static-update-component snowflake.torproject.org" and wait for it
 to complete.

 (4) Go to https://snowflake.torproject.org/ and see if your next text is
 there.

 These steps are all easy (ok, other than step 0), so if any of them turns
 out to be super complicated, it's probably because something is broken on
 the back-end that we should fix.

 Oh, and if while doing it you find bugs with the help.tpo tsa pages,
 here's the place to fix them:
 https://gitweb.torproject.org/project/help/wiki.git/tree/tsa/doc

--
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] #25731 [- Select a component]: windows hidden service bug

[Tor Bug Tracker & Wiki]

#25731: windows hidden service bug
--+--
 Reporter:  Ga15  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Ga15):

 Replying to [ticket:25731 Ga15]:
 Tested on win10 and win srv 2016

--
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] #25731 [- Select a component]: windows hidden service bug

[Tor Bug Tracker & Wiki]

#25731: windows hidden service bug
--+--
 Reporter:  Ga15  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 After updating to 7.5.3 tor fails on starting when HiddenServiceDir
 "C:\xxx\\" and HiddenServicePort 80 127.0.0.1:8080 is added to torrc.
 Log doesn't contain anything.

--
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] #23947 [Obfuscation/Snowflake]: Move Snowflake proxy page somewhere devs can write

[Tor Bug Tracker & Wiki]

#23947: Move Snowflake proxy page somewhere devs can write
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Ok, #25724 is complete. I was about to open a new ticket, "Populate
 https://snowflake.torproject.org/; but then I realized we can just
 continue on this ticket. Please feel free to make new ticket(s) if at any
 point you realize doing it all on one ticket has become crazy. :)

 I think three steps remain here:

 (1) David and Arlo should each confirm that they are able to edit the
 current website. I am able to, so it's just a matter of making sure
 they're in the right groups and have the right permissions and so on. I'll
 post instructions for that shortly.

 (2) Build a plan for how we want to handle website content. Do we want it
 in revision control? For example, we could make a snowflake-web git repo,
 kind of like the research-web git repo:
 https://gitweb.torproject.org/research-web.git/tree/
 and then we'd have some history to it, some visibility to others when
 changes get made, the ability to separate "can edit website content" from
 "can push changes to the actual website", etc. If we decide on this
 option, I'm happy to make the ticket to get the new git repo on its way to
 existing. If we decide on another option, that's cool too.

 (3) Actually pick the content, e.g. by migrating something over from
 previous pages. I plan to leave this one to Arlo and David for now. :)

--
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] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  regression, 0.3.4-must  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+

Comment (by cypherpunks):

 I've seen this one.

 {{{
 [WARN] Bug: /usr/bin/tor(_start+0x2a) [0x55a3a8ce609a] (on Tor
 0.3.3.4-alpha )
 [WARN] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)
 [0x7f558cd8c2b1] (on Tor 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(main+0x19) [0x55a3a8ce6049] (on Tor
 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(tor_main+0x3a) [0x55a3a8ce62da] (on Tor
 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(tor_run_main+0x275) [0x55a3a8cece95] (on Tor
 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(do_main_loop+0x2bc) [0x55a3a8ceb78c] (on Tor
 0.3.3.4-alpha )
 [WARN] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f558e7b85a0] (on Tor
 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(+0x53c78) [0x55a3a8ceac78] (on Tor
 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(circuit_build_needed_circs+0x3c8)
 [0x55a3a8d83e28] (on Tor 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(circuit_launch_by_extend_info+0x7d)
 [0x55a3a8d8369d] (on Tor 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(circuit_establish_circuit+0xa22)
 [0x55a3a8d70832] (on Tor 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55a3a8e3b989] (on
 Tor 0.3.3.4-alpha )
 [WARN] Bug: /usr/bin/tor(log_backtrace+0x44) [0x55a3a8e20154] (on Tor
 0.3.3.4-alpha )
 [WARN] Bug: Non-fatal assertion !(exit_ei == NULL) failed in
 onion_pick_cpath_exit at ../src/or/circuitbuild.c:2390. Stack trace: (on
 Tor 0.3.3.4-alpha )
 [WARN] tor_bug_occurred_(): Bug: ../src/or/circuitbuild.c:2390:
 onion_pick_cpath_exit: Non-fatal assertion !(exit_ei == NULL) failed. (on
 Tor 0.3.3.4-alpha )
 }}}

 It seems to be reproducible when your client has a newer consensus and the
 bridge lacks the descriptor to extend the circuit.

--
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] #24454 [Core Tor/Tor]: sandbox failure on arm64

[Tor Bug Tracker & Wiki]

#24454: sandbox failure on arm64
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  033-must, crash, sandbox,|  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by ahf):

 OK with me.

--
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] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 |  ffmancera
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debt, tor-dirauth, pending-disaster, review-   |
  group-32, review-group-34, |
  034-triage-20180328|
Parent ID:   | Points:  small
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Okay; sorry for all of the back-and-forth on this one.

 I've had another look at the code here, and talked it over with dgoulet,
 and we think that as it stands, this patch does not actually make the
 pattern here  less error-prone than it was before.  Previously, we had to
 be careful every time we added a new flag that would be cleared. With this
 patch, we must be careful every time we add a new field that would _not_
 be cleared.  The unit tests don't help us with the problem here, because
 they have no way to check for correct behavior of '''new fields''' in
 routerstatus_t.

 Most of the patterns that we thought of to try to improve the tests in
 this regard seem like they would cause other problems in the code (like
 forcing us to rewrite everything that uses the routerstatus_t flags).

 I'm putting this ticket into needs_revision, but it might need insight or
 a different approach entirely.  Even just some comments and might be an
 improvement.

--
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] #24465 [Applications/Tor Browser]: Snowflake broken if no libatomic on host

[Tor Bug Tracker & Wiki]

#24465: Snowflake broken if no libatomic on host
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, snowflake,  |  Actual Points:
  TorBrowserTeam201804, tbb-rbm  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:8 gk]:
 > boklm: Could you test (using steps in #25087) whether the GCC update in
 #25304 solves this issue?

 After the gcc update, `snowflake-client` is still linked to
 `libatomic.so.1`, so it seems it didn't solve the issue.

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

Re: [tor-bugs] #24454 [Core Tor/Tor]: sandbox failure on arm64

[Tor Bug Tracker & Wiki]

#24454: sandbox failure on arm64
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  033-must, crash, sandbox,|  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by nickm):

 Hmm.  I am thinking about deferring this to 0.3.4, since it is apparently
 not _our_ regression, and since it's probably going to take a bunch of
 fiddly cross-platform testing.

 Any objections?

--
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] #24465 [Applications/Tor Browser]: Snowflake broken if no libatomic on host

[Tor Bug Tracker & Wiki]

#24465: Snowflake broken if no libatomic on host
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, snowflake,  |  Actual Points:
  TorBrowserTeam201804, tbb-rbm  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: boklm (added)


--
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] #24465 [Applications/Tor Browser]: Snowflake broken if no libatomic on host

[Tor Bug Tracker & Wiki]

#24465: Snowflake broken if no libatomic on host
-+-
 Reporter:  isabela  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, snowflake,  |  Actual Points:
  TorBrowserTeam201804, tbb-rbm  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ux-team, snowflake, TorBrowserTeam201803 => ux-team,
 snowflake, TorBrowserTeam201804, tbb-rbm
 * status:  assigned => needs_information
 * parent:  #24371 =>


Comment:

 boklm: Could you test (using steps in #25087) whether the GCC update in
 #25304 solves this issue?

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

Re: [tor-bugs] #25332 [Metrics/Onionoo]: Change the exit_addresses field to not exclude current OR addresses anymore

[Tor Bug Tracker & Wiki]

#25332: Change the exit_addresses field to not exclude current OR addresses 
anymore
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Onionoo 1.13.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by iwakeh):

 * milestone:  Onionoo 2.0.0 => Onionoo 1.13.0


--
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] #25332 [Metrics/Onionoo]: Change the exit_addresses field to not exclude current OR addresses anymore

[Tor Bug Tracker & Wiki]

#25332: Change the exit_addresses field to not exclude current OR addresses 
anymore
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Onionoo 2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---
Changes (by iwakeh):

 * milestone:  Onionoo 1.12.0 => Onionoo 2.0.0


--
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] #25711 [Metrics/Onionoo]: Put out Onionoo 5.2-1.12.0

[Tor Bug Tracker & Wiki]

#25711: Put out Onionoo 5.2-1.12.0
-+
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by iwakeh):

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


Comment:

 Deployed, running fine, and [https://lists.torproject.org/pipermail/tor-
 dev/2018-April/013054.html announced].

--
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] #25304 [Applications/Tor Browser]: Update gcc to 6.4.0 (Linux)

[Tor Bug Tracker & Wiki]

#25304: Update gcc to 6.4.0 (Linux)
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201804R,  |  Actual Points:
  boklm201804|
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good. Applied to `master` (commit
 049196094eeb5a64b6504defaf12e1ab3e2546c3).

--
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] #24454 [Core Tor/Tor]: sandbox failure on arm64

[Tor Bug Tracker & Wiki]

#24454: sandbox failure on arm64
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  033-must, crash, sandbox,|  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by ahf):

 The glibc implementation of the `rename()` wrapper is:

 {{{
 /* Rename the file OLD to NEW.  */
 int
 rename (const char *old, const char *new)
 {
 #if defined (__NR_rename)
   return INLINE_SYSCALL_CALL (rename, old, new);
 #elif defined (__NR_renameat)
   return INLINE_SYSCALL_CALL (renameat, AT_FDCWD, old, AT_FDCWD, new);
 #else
   return INLINE_SYSCALL_CALL (renameat2, AT_FDCWD, old, AT_FDCWD, new, 0);
 #endif
 }
 }}}

--
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] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

[Tor Bug Tracker & Wiki]

#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  modularization, 034-roadmap- |  Actual Points:
  subtask, tor-dirauth, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #25494   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by dgoulet):

 Replying to [comment:6 chelseakomlo]:
  > One note about heavy refactoring- having sufficient tests in place is
 really helpful before splitting apart large pieces of functionality and
 refactoring. As part of this plan, maybe add a goal to audit existing
 tests/write any more necessary tests ideally as one of the first steps to
 help when touching particularly old/convoluted parts of the code.

 Indeed. That part of the code does have many tests but not in majority I
 think. Fortunately, for now we are just moving code around, no code
 behavior change. And ideally we keep it that way for the most part. I
 expect that it won't be true for some parts as we are still discovering
 those tricky them. For sure at that point, testing is needed.

 However, being able to test the entry points to the dirauth subsystem when
 it is *disable* would be desirable so we make sure that tor still works
 properly. Again, we are lucky in some ways with this subsystem because
 most of the entry point are guarded with "Am I a dirauth" so this part we
 can hard assert that if the module is disabled, it can NOT send back true.

--
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] #24454 [Core Tor/Tor]: sandbox failure on arm64

[Tor Bug Tracker & Wiki]

#24454: sandbox failure on arm64
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  033-must, crash, sandbox,|  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by ahf):

 The kernel version is:

 {{{
 Linux rpi3 4.15.0-2-arm64 #1 SMP Debian 4.15.11-1 (2018-03-20) aarch64
 GNU/Linux
 }}}

--
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] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Thanks ahf. Love it. Sorry about the nitpick!

 lgtm;

--
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] #24454 [Core Tor/Tor]: sandbox failure on arm64

[Tor Bug Tracker & Wiki]

#24454: sandbox failure on arm64
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  033-must, crash, sandbox,|  Actual Points:
  033-triage-20180320, 033-included-20180320 |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by nickm):

 ooh, ENOSYS.  That means that the syscall actually doesn't exist.  Huh!
 If we're not using syscall wrong, that means that the rename() syscall
 doesn't actually exist in this kernel, and renameat() is being used
 because it's the only choice.

--
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] #25730 [Webpages/Website]: The Tor website's bridges page has old Tor Browser screenshots

[Tor Bug Tracker & Wiki]

#25730: The Tor website's bridges page has old Tor Browser screenshots
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 This page as well https://www.torproject.org/projects/torbrowser.html.en

 I think I already reported this but I can't find the ticket.

--
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] #25711 [Metrics/Onionoo]: Put out Onionoo 5.2-1.12.0

[Tor Bug Tracker & Wiki]

#25711: Put out Onionoo 5.2-1.12.0
-+
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by iwakeh):

 Replying to [comment:4 karsten]:
 > tarball on dist.tp.o: https://dist.torproject.org/onionoo/5.2-1.12.0/

 Looks fine and is signed properly.

--
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] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+

Comment (by karsten):

 Replying to [comment:37 iwakeh]:
 > I'm not concerned about NPEs, but the string "null" appearing somewhere,
 where it shouldn't be.

 Ah, Gson simply leaves out fields with null values, unless told otherwise.

--
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] #25730 [Webpages/Website]: The Tor website's bridges page has old Tor Browser screenshots

[Tor Bug Tracker & Wiki]

#25730: The Tor website's bridges page has old Tor Browser screenshots
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should update them:
 https://www.torproject.org/docs/bridges

--
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] #25729 [Core Tor/Tor]: UTF8 encoded TORRC does NOT parse non-Latin paths

[Tor Bug Tracker & Wiki]

#25729: UTF8 encoded TORRC does NOT parse non-Latin paths
+--
 Reporter:  Fleming |  Owner:  (none)
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:   => needs-proposal


Comment:

 This has potential backwards compatibility and security implications, so
 it needs a proposal.

--
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] #25729 [Core Tor/Tor]: UTF8 encoded TORRC does NOT parse non-Latin paths

[Tor Bug Tracker & Wiki]

#25729: UTF8 encoded TORRC does NOT parse non-Latin paths
--+--
 Reporter:  Fleming   |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Fleming):

 * keywords:  needs-proposal =>


Comment:

 Am not a developer, but my user’s experience says that DataDirectory path
 is a string, right? Check its existence on disk as ANSI first, then
 internally convert that string to UTF8 and check again.

--
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] #25729 [Core Tor/Tor]: UTF8 encoded TORRC does NOT parse non-Latin paths

[Tor Bug Tracker & Wiki]

#25729: UTF8 encoded TORRC does NOT parse non-Latin paths
+--
 Reporter:  Fleming |  Owner:  (none)
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:   => needs-proposal
 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 If anyone wants to have a go, here is a reference:
 https://stackoverflow.com/questions/2050973/what-encoding-are-filenames-
 in-ntfs-stored-as

--
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] #25729 [Core Tor/Tor]: UTF8 encoded TORRC does NOT parse non-Latin paths

[Tor Bug Tracker & Wiki]

#25729: UTF8 encoded TORRC does NOT parse non-Latin paths
--+--
 Reporter:  Fleming   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Fleming):

 Win1252? ANSI codepage which was used is Win1251.
 Also I have tried setting “chcp 65001” before running UTF8 encoded torrc,
 didn’t help.
 Let other developers take a peek, why the rush?

--
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] #25725 [Internal Services/Tor Sysadmin Team]: Please add irl to the collector, onionoo, metrics, and exonerator groups

[Tor Bug Tracker & Wiki]

#25725: Please add irl to the collector, onionoo, metrics, and exonerator groups
-+
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


--
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] #25724 [Internal Services/Tor Sysadmin Team]: Please make new snowflake.torproject.org static website

[Tor Bug Tracker & Wiki]

#25724: Please make new snowflake.torproject.org static website
-+
 Reporter:  arma |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


--
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] #25729 [Core Tor/Tor]: UTF8 encoded TORRC does NOT parse non-Latin paths

[Tor Bug Tracker & Wiki]

#25729: UTF8 encoded TORRC does NOT parse non-Latin paths
--+--
 Reporter:  Fleming   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * status:  new => closed
 * resolution:   => wontfix
 * version:  Tor: 0.3.2.10 => Tor: unspecified
 * component:  - Select a component => Core Tor/Tor
 * milestone:   => Tor: unspecified


Comment:

 The Windows fopen() implementation assumes that file paths are in the
 default system encoding, which is win-1252 on the system that created this
 archive.

 Windows does not support UTF-8 as a default system encoding, because its
 system encodings are limited to two bytes per character.

 To support UTF-8 on Windows, tor would need to rewrite all our filesystem
 code to use the Windows unicode filesystem APIs. This would be a breaking
 change for existing configs, and a lot of work for us.

 As a workaround, please save your torrc file in your Windows system
 encoding.

--
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] #25590 [Internal Services/Tor Sysadmin Team]: Add a configuration line to the consensus-health Apache config

[Tor Bug Tracker & Wiki]

#25590: Add a configuration line to the consensus-health Apache config
-+
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #25588   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


--
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] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+

Comment (by iwakeh):

 Replying to [comment:36 karsten]:
 > Replying to [comment:35 iwakeh]:
 > > Ready for merge, if you confirm that version status cannot be null in
 the line added to DetailsDocumentWriter.
 >
 > I had that same thought after seeing both changes in that commit (which
 I found and fixed separately). Actually the version status there ''can''
 be null, but that's okay, because we're not invoking a method on it.
 Alright, merging to master and re-closing. Thanks!

 I'm not concerned about NPEs, but the string "null" appearing somewhere,
 where it shouldn't be.

--
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] #25729 [- Select a component]: UTF8 encoded TORRC does NOT parse non-Latin paths

[Tor Bug Tracker & Wiki]

#25729: UTF8 encoded TORRC does NOT parse non-Latin paths
--+---
 Reporter:  Fleming   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.2.10
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Unpack [https://linx.li/selif/tor-utf8-fails.7z this Tor archive] to C:\

 It will create the following hierarchy:
 ''C:\Проверка\Tor'' (for executables, libraries and torrc)
 ''C:\Проверка\Tor\Data'' (for data and geoip)

 Configuration file, torrc, is encoded UTF8.
 It has this line: ''DataDirectory C:\Проверка\Tor\Data''

 If I run tor.exe -f torrc, the output as follows
 ''[warn] Error creating directory C:\Проверка\Tor\Data: No such file or
 directory
 [warn] Failed to parse/validate config: Couldn't create private data
 directory "C:\Проверка\Tor\Data"''

 Now let’s replace UTF8 encoded torrc with [https://linx.li/selif/torrc-
 ansi.7z ANSI encoded torrc] and Tor works as expected.

--
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] #25728 [Metrics/Onionoo]: No build revision available when building the .war file before .jar files

[Tor Bug Tracker & Wiki]

#25728: No build revision available when building the .war file before .jar 
files
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 When I run `ant clean war` and start the resulting .war file, I get the
 following message:

 {{{
 2018-04-06 10:29:06,264 WARN o.t.o.s.ResponseBuilder:48 No build revision
 available.
 }}}

 Also, responses are missing the "build_revision" field.

 When I run `ant clean jar war`, everything's fine.

 I only tried this out with Onionoo, but maybe other components are
 affected, too.

 Sounds like an easy fix to the dependencies/calls in `build.xml` for
 somebody who is better at doing Ant things than I.

--
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] #25711 [Metrics/Onionoo]: Put out Onionoo 5.2-1.12.0

[Tor Bug Tracker & Wiki]

#25711: Put out Onionoo 5.2-1.12.0
-+
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 tarball on dist.tp.o: https://dist.torproject.org/onionoo/5.2-1.12.0/

--
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] #25711 [Metrics/Onionoo]: Put out Onionoo 5.2-1.12.0

[Tor Bug Tracker & Wiki]

#25711: Put out Onionoo 5.2-1.12.0
-+
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * status:  needs_review => accepted
 * owner:  metrics-team => karsten


Comment:

 Thanks! I'll merge the Onionoo changes and put the tarball on dist.tp.o.
 But I'll wait with the metrics-web change until after deployment and
 announcement. Leaving this ticket open until everything's done. ttyl

--
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] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Replying to [comment:35 iwakeh]:
 > Ready for merge, if you confirm that version status cannot be null in
 the line added to DetailsDocumentWriter.

 I had that same thought after seeing both changes in that commit (which I
 found and fixed separately). Actually the version status there ''can'' be
 null, but that's okay, because we're not invoking a method on it. Alright,
 merging to master and re-closing. Thanks!

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

Re: [tor-bugs] #25711 [Metrics/Onionoo]: Put out Onionoo 5.2-1.12.0

[Tor Bug Tracker & Wiki]

#25711: Put out Onionoo 5.2-1.12.0
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by iwakeh):

 Pre-release looks fine.
 ttyl

--
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] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+

Comment (by iwakeh):

 Ready for merge, if you confirm that version status cannot be null in the
 line added to DetailsDocumentWriter.

--
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] #25711 [Metrics/Onionoo]: Put out Onionoo 5.2-1.12.0

[Tor Bug Tracker & Wiki]

#25711: Put out Onionoo 5.2-1.12.0
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Alright, after discussing this yesterday, let's do it.

 Onionoo branch (including the yet unreviewed fix for #24256):
 https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-25711

 metrics-web branch: https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=task-25711

 Pre-release tarball:
 https://people.torproject.org/~karsten/volatile/onionoo-5.2-1.12.0-pre0.tar.gz

--
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] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by karsten):

 * status:  reopened => needs_review


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

Re: [tor-bugs] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+
 Reporter:  arma |  Owner:  karsten
 Type:  enhancement  | Status:  reopened
 Priority:  High |  Milestone:  Onionoo 1.12.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25199   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by karsten):

 * status:  closed => reopened
 * priority:  Medium => High
 * resolution:  fixed =>


Comment:

 Oops, I found two bugs while preparing the release that are both related
 to this enhancement. Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-24256=1ade07e315c9cb8ad6c432fae7907ee1af45b394
 commit 1ade07e in my task-24256 branch]. Setting priority to high, so that
 we can still put out the release today.

--
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