Re: [tor-bugs] #32549 [Applications/Tor Browser]: NoScript makes requests to sync-messages.invalid

2020-01-22 Thread Tor Bug Tracker & Wiki
#32549: NoScript makes requests to sync-messages.invalid
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 You're gone from fixing TBB bugs ;) `sync-messages.invalid` was replaced
 by `255.255.255.255`. So, see comment:15.

--
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] #32549 [Applications/Tor Browser]: NoScript makes requests to sync-messages.invalid

2020-01-22 Thread Tor Bug Tracker & Wiki
#32549: NoScript makes requests to sync-messages.invalid
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:16 cypherpunks]:
 > gk has gone, the bug doesn't.

 I am not gone, no worries. That said, there is no code anymore in 11.0.13
 containing `sync-messages.invalid` and previously it got commented out.
 So, there seems to be no way to me that you can hit this with a recent
 NoScript.

 For the other case, see comment:14.

--
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] #32614 [Core Tor/Tor]: hs-v3: Consider flagging an intro point as bad if rendezvous fails multiple times

2020-01-22 Thread Tor Bug Tracker & Wiki
#32614: hs-v3: Consider flagging an intro point as bad if rendezvous fails 
multiple
times
-+--
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, tor-hs  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:  Sponsor27-can
-+--

Comment (by neel):

 New simplified PR: https://github.com/torproject/tor/pull/1682

 No tests, however.

--
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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

2020-01-22 Thread Tor Bug Tracker & Wiki
#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by Sebastian):

 Replying to [comment:8 teor]:
 > Replying to [comment:2 Sebastian]:
 > > I am not concerned about relays connecting from a wrong IP address. I
 basically feel like that shouldn't even be possible configuration-wise
 >
 > Relays can set different addresses in the Address and
 OutboundBindAddress options, and their inbound and outbound traffic will
 be on different addresses. Some operators use these options, others put
 their Address on a non-default route.
 >
 > So we do need to consider this case, particularly when relays are trying
 to discover their own IP address from an authority. But relays should fall
 back to discovering their address and getting a consensus from other
 relays, if all the authorities fail.
 >
 > So maybe it will work anyway? We should do a test to make sure.

 I know these kinds of configurations are possible, but why is that and why
 are we OK with it. That's my point here, we should IMO change your stance
 to this being not supported behaviour.

--
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] #19251 [Applications/Tor Browser]: TorBrowser might want to have an error page specific to when .onion links fail

2020-01-22 Thread Tor Bug Tracker & Wiki
#19251: TorBrowser might want to have an error page specific to when .onion 
links
fail
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  enhancement| Status:  assigned
 Priority:  Low|  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam202001  |  Actual Points:
Parent ID:  #30025 | Points:  6
 Reviewer: |Sponsor:
   |  Sponsor27-must
---+---

Comment (by mcs):

 Replying to [comment:20 brade]:
 > Did you decide against a vertical arrangement for the
 browser/network/onion service graphics?  (Maybe it's not workable)

 Antonela — in case it matters, Kathy and I think we have found a way to
 make a horizontal layout work within the existing about:netError page. I
 assume for a RTL locale we just want to reverse the order of the 3 images?

--
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] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

2020-01-22 Thread Tor Bug Tracker & Wiki
#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security 043-can  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by starlight):

 Instead of  writing pseudo code I implemented the algorithm described.
 Down to neatness-counts items, replacing hard-code constants with configs
 etc.  Busy at work and it might take a couple more weeks--can post current
 state if desired.

--
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] #33032 [Core Tor/Tor]: Private keys from Scallion vanity .onion not working

2020-01-22 Thread Tor Bug Tracker & Wiki
#33032: Private keys from Scallion vanity .onion not working
-+-
 Reporter:  larshilse|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Major| Resolution:
 Keywords:  Scallion, onion, private key,|  Actual Points:
  043-should 035-backport 041-backport   |
  042-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  Scallion, onion, private key, =>
 Scallion, onion, private key, 043-should 035-backport 041-backport
 042-backport
 * cc: dgoulet, asn (added)
 * milestone:   => Tor: 0.4.3.x-final


--
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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

2020-01-22 Thread Tor Bug Tracker & Wiki
#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:  network-health => network-health 043-should
 * milestone:   => Tor: 0.4.3.x-final


--
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] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths

2020-01-22 Thread Tor Bug Tracker & Wiki
#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth 043-should?  |  Actual Points:
Parent ID:  #33018   | Points:  0.4
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * keywords:  tor-dirauth => tor-dirauth 043-should?


--
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] #22331 [Core Tor/Tor]: Tor needs to stop trying to read directories before it changes users

2020-01-22 Thread Tor Bug Tracker & Wiki
#22331: Tor needs to stop trying to read directories before it changes users
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.7
 Severity:  Normal   | Resolution:
 Keywords:  032-unreached, apparmor usability|  Actual Points:
  042-proposed 044-should 043-backport?? |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * cc: asn (added)
 * keywords:  032-unreached, apparmor usability 042-proposed =>
 032-unreached, apparmor usability 042-proposed 044-should
 043-backport??
 * milestone:  Tor: unspecified => Tor: 0.4.4.x-final


--
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] #32549 [Applications/Tor Browser]: NoScript makes requests to sync-messages.invalid

2020-01-22 Thread Tor Bug Tracker & Wiki
#32549: NoScript makes requests to sync-messages.invalid
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 gk has gone, the bug doesn't.

--
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] #32536 [Applications/Tor Browser]: Security level set to "Safest" but JavaScript still Enabled.

2020-01-22 Thread Tor Bug Tracker & Wiki
#32536: Security level set to "Safest" but JavaScript still Enabled.
--+--
 Reporter:  tor70001  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Clean new `torbrowser-install-9.0.4_en-US.exe` and the same shit. Is
 somebody going to fix it?

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

Re: [tor-bugs] #30901 [Core Tor/Tor]: Add control port trace logging to tor

2020-01-22 Thread Tor Bug Tracker & Wiki
#30901: Add control port trace logging to tor
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, network-  |  Actual Points:  1.8
  team-roadmap-2020Q1 043-should |
Parent ID:  #29437   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * owner:  teor => nickm
 * keywords:  tor-ci-fail-sometimes, network-team-roadmap-2020Q1 => tor-ci-
 fail-sometimes, network-team-roadmap-2020Q1 043-should


--
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] #33032 [Core Tor/Tor]: Private keys from Scallion vanity .onion not working

2020-01-22 Thread Tor Bug Tracker & Wiki
#33032: Private keys from Scallion vanity .onion not working
---+--
 Reporter:  larshilse  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor/Tor
  Version:  Tor: 0.3.5.8   |   Severity:  Major
 Keywords:  Scallion, onion, private key,  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 After the upgrade to v 0.3.5.8 my onion wasn't available anymore.

 This is the info I get when attempting to start tor:

 Jan 23 00:29:34.000 [warn] Error decoding PEM wrapper while reading
 private key
 Jan 23 00:29:34.000 [warn] Unable to decode private key from file
 "/var/lib/tor/hidden_service//private_key"
 Jan 23 00:29:34.000 [err] Error loading private key.
 Jan 23 00:29:34.000 [warn] Error loading rendezvous service keys
 Jan 23 00:29:34.000 [err] set_options(): Bug: Acting on config options
 left us in a broken state. Dying. (on Tor 0.3.5.8 )
 Jan 23 00:29:34.000 [err] Reading config failed--see warnings above.

 More users are having the same issue, that their Scallion generated keys
 cannot be read by the most recent version of TOR.

 Any ideas?

--
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] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

2020-01-22 Thread Tor Bug Tracker & Wiki
#32794: improve OOS (out-of-sockets) handler victim selection and more
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:  security 043-can  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_information


--
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] #31482 [Core Tor/Tor]: Avoid possible overflow when converting between coarse stamp to approx ms

2020-01-22 Thread Tor Bug Tracker & Wiki
#31482: Avoid possible overflow when converting between coarse stamp to approx 
ms
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  043-should, 035-backport,|  Actual Points:  0.5
  040-backport, 041-backport, 042-backport,  |
  security? 043-should?  |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Someone else can do this in 0.4.3, or we can delay it to 0.4.4, and I'll
 have another look at it.

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

Re: [tor-bugs] #29546 [Core Tor/Tor]: Update Maintaining.md after new merge policy is final

2020-01-22 Thread Tor Bug Tracker & Wiki
#29546: Update Maintaining.md after new merge policy is final
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  policy, doc, 041-deferred-20190530,  |  Actual Points:
  043-should |
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  teor => (none)


Comment:

 The new merge policy still isn't final, but it also hasn't changed in a
 few months.

 Someone else can do this in 0.4.3, or we can delay it to 0.4.4, and I'll
 have another look at it.

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

Re: [tor-bugs] #29546 [Core Tor/Tor]: Update Maintaining.md after new merge policy is final

2020-01-22 Thread Tor Bug Tracker & Wiki
#29546: Update Maintaining.md after new merge policy is final
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  policy, doc, 041-deferred-20190530,  |  Actual Points:
  043-should |
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => new


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

Re: [tor-bugs] #30745 [Core Tor/Tor]: Document disabled CI

2020-01-22 Thread Tor Bug Tracker & Wiki
#30745: Document disabled CI
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  043-should process tor-ci doc  |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:  Sponsor31-can
---+---
Changes (by teor):

 * status:  assigned => new


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

Re: [tor-bugs] #30745 [Core Tor/Tor]: Document disabled CI

2020-01-22 Thread Tor Bug Tracker & Wiki
#30745: Document disabled CI
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  043-should process tor-ci doc  |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:  Sponsor31-can
---+---
Changes (by teor):

 * owner:  teor => (none)


Comment:

 Someone else can do this in 0.4.3, or we can delay it to 0.4.4, and I'll
 have another look at it.

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

Re: [tor-bugs] #32792 [Core Tor/Tor]: Copy chutney CI diagnostics to Tor's chutney job

2020-01-22 Thread Tor Bug Tracker & Wiki
#32792: Copy chutney CI diagnostics to Tor's chutney job
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  044-should, tor-ci, chutney  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  043-should, tor-ci, chutney => 044-should, tor-ci, chutney
 * milestone:  Tor: 0.4.3.x-final => Tor: 0.4.4.x-final


Comment:

 I can do this in 0.4.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] #31482 [Core Tor/Tor]: Avoid possible overflow when converting between coarse stamp to approx ms

2020-01-22 Thread Tor Bug Tracker & Wiki
#31482: Avoid possible overflow when converting between coarse stamp to approx 
ms
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  043-should, 035-backport,|  Actual Points:  0.5
  040-backport, 041-backport, 042-backport,  |
  security? 043-should?  |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * owner:  teor => (none)
 * status:  needs_revision => assigned


Comment:

 Here's what I've done so far:
 * 0.3.5: https://github.com/torproject/tor/pull/1435

 Here's the incomplete work:
 * Fix macOS unit test error
 * tests for monotime_coarse_stamp_units_to_approx_msec() and
 monotime_msec_to_approx_coarse_stamp_units()
   * more values
   * precise and approximate cases, and their boundary conditions
   * underflow and overflow (close to 2^30^ ?)

 Here's what still needs to be done:
 * do a GCD calculation on Windows init
 * refactor and extra tests for monotime_init_internal()
 * changes file

--
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] #31482 [Core Tor/Tor]: Avoid possible overflow when converting between coarse stamp to approx ms

2020-01-22 Thread Tor Bug Tracker & Wiki
#31482: Avoid possible overflow when converting between coarse stamp to approx 
ms
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  043-should, 035-backport,|  Actual Points:  0.5
  040-backport, 041-backport, 042-backport,  |
  security? 043-should?  |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_revision


--
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] #32588 [Core Tor/Tor]: Setting ORPort [ipv6]:auto mistakenly advertises port 94

2020-01-22 Thread Tor Bug Tracker & Wiki
#32588: Setting ORPort [ipv6]:auto mistakenly advertises port 94
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.9-alpha
 Severity:  Normal   | Resolution:
 Keywords:  043-should, ipv6, memory-safety, |  Actual Points:  0.8
  security-low, 035-backport, 040-backport,  |
  041-backport, 042-backport |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_revision


--
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] #30917 [Core Tor/Tor]: Add instructions for making a new maint branch to EndOfLifeTor.md, and rename the file

2020-01-22 Thread Tor Bug Tracker & Wiki
#30917: Add instructions for making a new maint branch to EndOfLifeTor.md, and
rename the file
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sponsor31-maybe, 043-should, |  Actual Points:
  postfreeze-ok  |
Parent ID:  #30839   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_revision


--
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] #32588 [Core Tor/Tor]: Setting ORPort [ipv6]:auto mistakenly advertises port 94

2020-01-22 Thread Tor Bug Tracker & Wiki
#32588: Setting ORPort [ipv6]:auto mistakenly advertises port 94
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.9-alpha
 Severity:  Normal   | Resolution:
 Keywords:  043-should, ipv6, memory-safety, |  Actual Points:  0.8
  security-low, 035-backport, 040-backport,  |
  041-backport, 042-backport |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  teor => (none)
 * status:  needs_revision => assigned


Comment:

 This fix should go in 0.4.3, someone just needs to write a unit test or a
 script test.

 Or we can decide that it's too hard to test, and the reviewer can just
 check it manually.

--
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] #30917 [Core Tor/Tor]: Add instructions for making a new maint branch to EndOfLifeTor.md, and rename the file

2020-01-22 Thread Tor Bug Tracker & Wiki
#30917: Add instructions for making a new maint branch to EndOfLifeTor.md, and
rename the file
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sponsor31-maybe, 043-should, |  Actual Points:
  postfreeze-ok  |
Parent ID:  #30839   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  teor => (none)
 * status:  needs_revision => assigned


Comment:

 Someone else can do this in 0.4.3, or we can delay it to 0.4.4, and I'll
 have another look at it.

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

Re: [tor-bugs] #5304 [Circumvention/Obfs4]: Obfsproxy should respect OutboundBindAddress in torrc

2020-01-22 Thread Tor Bug Tracker & Wiki
#5304: Obfsproxy should respect OutboundBindAddress in torrc
-+-
 Reporter:  korobkov |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-spec-change needs-tor-change,  |  Actual Points:  1.25
  network-team-roadmap-2020Q1, 043-should|
Parent ID:  #30471   | Points:  1
 Reviewer:  phw  |Sponsor:
 |  Sponsor28-must
-+-
Changes (by ahf):

 * keywords:  needs-spec-change needs-tor-change, network-team-roadmap-
 2020Q1 =>
 needs-spec-change needs-tor-change, network-team-roadmap-2020Q1,
 043-should


--
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] #31009 [Core Tor/Tor]: Tor lets transports advertise private IP addresses in descriptor

2020-01-22 Thread Tor Bug Tracker & Wiki
#31009: Tor lets transports advertise private IP addresses in descriptor
-+-
 Reporter:  phw  |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, tor-bridge, 035-backport,|  Actual Points:
  040-backport, 041-backport,|
  042-deferred-20190918, network-team-roadmap-   |
  2020Q1, 043-should |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-
Changes (by ahf):

 * keywords:
 tor-pt, tor-bridge, 035-backport, 040-backport, 041-backport,
 042-deferred-20190918, network-team-roadmap-2020Q1
 =>
 tor-pt, tor-bridge, 035-backport, 040-backport, 041-backport,
 042-deferred-20190918, network-team-roadmap-2020Q1, 043-should


--
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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

2020-01-22 Thread Tor Bug Tracker & Wiki
#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-health  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Some of these changes are significant, and they are going to have impacts
 across the network. But I understand that we need some of these fixes
 urgently.

 Can you please write proposals for the longer-term changes?
 And send a quick email to tor-dev about the urgent changes?

 I'm concerned that there may be design conflicts with some other work,
 particularly Sponsor 55. So we need to share these details with other tor
 developers. That way, we can make sure that the Sponsor 55 proposals are
 compatible with these fixes.

--
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] #33030 [Applications/rbm]: rust-android-x86 fails to build

2020-01-22 Thread Tor Bug Tracker & Wiki
#33030: rust-android-x86 fails to build
--+
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pospeselr):

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


Comment:

 FWIW it succeeded on a second attempt :shrug:

--
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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

2020-01-22 Thread Tor Bug Tracker & Wiki
#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-health  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Replying to [comment:5 arma]:
 > Possible next steps beyond the above branch which I think would be worth
 taking:
 >
 > 1. Whitelist (i.e. never send 503's) IP addresses of relays in the
 consensus too. Or maybe it's better to consider relays in our descriptor
 list (i.e. if we vote about it, whitelist it). I have a commented-out
 function conn_addr_is_relay() in the above branch which somebody would
 need to write, and it will need to be fast fast fast or the lookup won't
 be worth it. ahf sketched out that function as "if we extend routerlist_t
 to have a map from addr to a routerinfo_t and from the v6 address, then I
 think you can do it fast."

 It's better to consider the descriptor list, otherwise new relays have
 trouble joining the consensus. It's important to whitelist IPv4 and IPv6
 addresses, because Sponsor 55 will add IPv6 directory requests.

 > 2. Whitelist the IP address for the consensus health checker (I think
 that might be carinatum.tpo) so it stops yelling and thinking we're down.
 :)
 >
 > 3. Consider giving higher priority to microdesc-consensus and microdesc
 replies. That is, I would rather have relays successfully cache and mirror
 the microdesc flavored stuff, if I have to choose.
 >
 > 4. Make a change to the Tor code so relays remain on the client fetch
 schedule (i.e. fetch from relays and fallback dirs) until they publish
 their descriptor. That way we remove one variable from the mystery, i.e.
 "maybe these Tors that are mobbing me are all configured as relays but
 haven't found themselves reachable so that's why I don't know about them."
 (I recognize we'll need to wait some years until everybody has upgraded.
 No time like the present to get started then.)

 Relays which don't know their address will fetch from authorities, so they
 get their address from a trusted source. But address discovery only needs
 one successful fetch (or two, once relays are trying to guess their IPv6
 address). After that, relays can use the client fetch targets.

 The client schedule is a slightly different thing, it only affects fetch
 timing. It's ok for relays to use the client fetch timing, until they
 publish their descriptor. Relays on bad links might bootstrap a bit more
 slowly or unreliably, but those relays were never going to be good relays
 anyway.

 And then there's the client and relay fetch method. Should relays use
 ORPorts for fetches until they publish their descriptor? It probably
 wouldn't hurt, and it would make address detection more secure.

 > 5. Look for patterns in the non-relay IP addresses that are bombing us
 with consensus fetch attempts. How often do they come back asking for
 another one? Does that timing pattern make us think they are a well
 behaving Tor that somehow thinks the dir auths' dirports are the best
 places to ask?

 We should also check the HTTP headers sent as part of the requests. They
 will tell us a lot about the tor version (or other program) that's sending
 the requests.

 > 6. Consider a design for a more aggressive load shedding plan. Right now
 we send the 503 if we don't have the space left in our global write
 bucket, or we ran out of global write bucket the previous second. For
 vanilla-flavored dirport consensus responses to non-relay IP addresses, I
 could imagine something much more aggressive, like "could I serve ten of
 these? No? Then 503." with the goal of actually leaving some room to serve
 the more important ones rather than always being full or nearly full.

--
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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

2020-01-22 Thread Tor Bug Tracker & Wiki
#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-health  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Replying to [comment:2 Sebastian]:
 > I am not concerned about relays connecting from a wrong IP address. I
 basically feel like that shouldn't even be possible configuration-wise

 Relays can set different addresses in the Address and OutboundBindAddress
 options, and their inbound and outbound traffic will be on different
 addresses. Some operators use these options, others put their Address on a
 non-default route.

 So we do need to consider this case, particularly when relays are trying
 to discover their own IP address from an authority. But relays should fall
 back to discovering their address and getting a consensus from other
 relays, if all the authorities fail.

 So maybe it will work anyway? We should do a test to make sure.

--
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] #33031 [Internal Services/Service - nextcloud]: Expired TLS Cert

2020-01-22 Thread Tor Bug Tracker & Wiki
#33031: Expired TLS Cert
-+-
 Reporter:  sysrqb   |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by micah):

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


Comment:

 Thanks for the report - it seems the cert was properly renewed in
 December, but the webserver was not restarted to pick it up.

--
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] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths

2020-01-22 Thread Tor Bug Tracker & Wiki
#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #33018| Points:  0.4
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Please check for authority IPv6 addresses. I'm just about to make relays
 use IPv6 to authorities as part of sponsor 55, so we need an IPv6 check
 when we whitelist relays.

 There's a few subtle address issues in this patch, which we should
 document:
 * configured vs consensus addresses
 * inbound vs outbound addresses
 See the PR for details.

--
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] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

2020-01-22 Thread Tor Bug Tracker & Wiki
#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
---+--
 Reporter:  arma   |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202001  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 Replying to [comment:8 arthuredelstein]:
 > Awesome that you are looking into this Georg! I have the script running
 daily to generate the results on the website and I haven't run into the
 errors you saw. But your first patch makes sense to me and I applied it to
 master.
 >
 > The other two patches I won't apply because I don't want to break the
 live site, but I'm happy to try to help with any problems you might be
 running into.

 Thanks, you are welcome. The exit relay you specified is down, no? See:
 
https://metrics.torproject.org/rs.html#details/7BD7B547676257EF147F5D5B7A5B15F840F4B579,
 so you need to pick another one, which my third patch does. Ideally, we
 would not hard-code a relay here as this breaks from time to time. (And
 broke for me, hence the patch) I guess a better solution would be to pick
 a proper exit relay from the relays you have been testing anyway before
 testing the non-exit-ones. But for now I don't see why you can't take my
 third patch, like how would it break the live site?

 For the second one, yeah, I can see it. If you like I can try to rewrite
 it in a way that better fits your needs.

 If you have some scripts to group the results given some parameters (like
 "all relays with a DNS error in 80% of the cases during the last n days")
 I'd be happy to hear about them it would probably smart to have some
 automated way for at least extracting all the info for bad-exit decisions.

--
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] #32335 [Core Tor/Tor]: Set up a .github repository on GitHub

2020-01-22 Thread Tor Bug Tracker & Wiki
#32335: Set up a .github repository on GitHub
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 I requested a new URL for the FUNDING section after talking to Sarah.

--
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] #31332 [Metrics/Relay Search]: Please update the FallbackDir flags in relay search

2020-01-22 Thread Tor Bug Tracker & Wiki
#31332: Please update the FallbackDir flags in relay search
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Sorry that it's a manual process, and it doesn't work like all the other
 flags :-)

--
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] #32335 [Core Tor/Tor]: Set up a .github repository on GitHub

2020-01-22 Thread Tor Bug Tracker & Wiki
#32335: Set up a .github repository on GitHub
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 I asked for some specific changes to CONTRIBUTING and SUPPORT to allow
 multiple projects.

--
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] #31239 [Internal Services/Tor Sysadmin Team]: automate installs

2020-01-22 Thread Tor Bug Tracker & Wiki
#31239: automate installs
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 #32937 has seen a fairly successful install using setup-storage that would
 remove the need for custom shell scripts in favor of reusable, fairly
 readable config files.

 i've also reshuffled the new-machine-hetzner-robot docs in that direction,
 but the scripts still need to be removed and teh docs updated accordingly.

--
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] #30797 [Core Tor/Tor]: Stop shipping an abandoned systemd script?

2020-01-22 Thread Tor Bug Tracker & Wiki
#30797: Stop shipping an abandoned systemd script?
--+--
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #31576| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Here's the thread I just started on the packagers mailing list:
 https://lists.torproject.org/pipermail/tor-
 packagers/2020-January/82.html

--
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] #31576 [Core Tor/Tor]: Fix shellcheck errors in contrib/dist/rc.subr, and add to test-shellcheck

2020-01-22 Thread Tor Bug Tracker & Wiki
#31576: Fix shellcheck errors in contrib/dist/rc.subr, and add to 
test-shellcheck
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  shellcheck|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 I'm sorry, I forgot to ask.

 Here's the thread I just started on the packagers mailing list:
 https://lists.torproject.org/pipermail/tor-
 packagers/2020-January/82.html

--
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] #32335 [Core Tor/Tor]: Set up a .github repository on GitHub

2020-01-22 Thread Tor Bug Tracker & Wiki
#32335: Set up a .github repository on GitHub
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:4 ahf]:
 > This page is supposed to be "global" and be informative about *all* Tor-
 related projects we have on github.com/torproject right?

 Replying to [comment:4 ahf]:
 > This page is supposed to be "global" and be informative about *all* Tor-
 related projects we have on github.com/torproject right?

 Yes, it's global.

 So before we merge, we should:
 * check FUNDING with Sarah

 And after we merge, we can add other projects to:
 * CONTRIBUTING
 * SECURITY
 * SUPPORT
 (Or we could ask them to review this pull request, and add commits. But
 that might get messy.)

--
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] #32937 [Internal Services/Tor Sysadmin Team]: install a new node in the gnt-fsn cluster (fsn-node-03)

2020-01-22 Thread Tor Bug Tracker & Wiki
#32937: install a new node in the gnt-fsn cluster (fsn-node-03)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 added to nagios

--
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] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

2020-01-22 Thread Tor Bug Tracker & Wiki
#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
---+--
 Reporter:  arma   |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202001  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arthuredelstein):

 Awesome that you are looking into this Georg! I have the script running
 daily to generate the results on the website and I haven't run into the
 errors you saw. But your first patch makes sense to me and I applied it to
 master.

 The other two patches I won't apply because I don't want to break the live
 site, but I'm happy to try to help with any problems you might be running
 into.

--
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] #32937 [Internal Services/Tor Sysadmin Team]: install a new node in the gnt-fsn cluster (fsn-node-03)

2020-01-22 Thread Tor Bug Tracker & Wiki
#32937: install a new node in the gnt-fsn cluster (fsn-node-03)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 rest of the new-machine procedure:

  1. fixed /etc/hosts and /etc/resolv.conf

  2. fixed /etc/network/interfaces to add IPv6 and added the IPs by hand
 (!) this was required for LDAP generation to work

  3. added to LDAP

  4. made the puppet dance

  5. security upgrades (none)

  6. fixed aliases and hardening

  7. rebooted

 still need to:

  1. add to spreadsheet
  2. add to nagios
  3. configure ganeti

--
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] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths

2020-01-22 Thread Tor Bug Tracker & Wiki
#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #33018| Points:  0.4
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Another optimization we could do here: the whole priority thing is no
 longer used, since all five callers send in "priority 2". So we could
 either rip it out, or we could re-purpose it to use new kinds of
 priorities, like microdesc vs vanilla.

 Slight preference for keeping it in, and then using it for item (6) in
 #33018 ("handle vanilla vs microdesc flavors differently").

--
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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

2020-01-22 Thread Tor Bug Tracker & Wiki
#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-health  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by arma):

 dgoulet has a patch for (1) in #33029.

--
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] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths (was: dir-auth: Never send a 503 directory request code to another director

2020-01-22 Thread Tor Bug Tracker & Wiki
#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #33018| Points:  0.4
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:3 arma]:
 >   That's why this patch here should be ok for one or two authorities to
 run, but not more, until we also do the "whitelist relays" piece of it.

 Oh! I see that it does include this clause. So we should rename this
 ticket. I tried a new name 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] #32937 [Internal Services/Tor Sysadmin Team]: install a new node in the gnt-fsn cluster (fsn-node-03)

2020-01-22 Thread Tor Bug Tracker & Wiki
#32937: install a new node in the gnt-fsn cluster (fsn-node-03)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 Rerunning the install:

  1. login

  2. added an explicit step to set the hostname instead of hiding it in the
 disk partitionning

  3. partitionned the disks with the following configuration file:

 {{{
 # open questions
 # --align=optimal?
 # leave keys in /tmp/fai or specify passphrase?
 # use sameas: to set all disk names earlier?
 # bios_grub flag?

 disk_config nvme0n1 disklabel:gpt bootable:2 align-at:1M
 # bios grub second stage
 primary -   8MiB-   -
 # /boot
 primary -   512MiB  -   -
 # rest is RAID+LUKS+LVM
 primary -   0-  -   -

 disk_config nvme1n1 disklabel:gpt bootable:2 align-at:1M
 # same as above
 primary -   8MiB-   -
 primary -   512MiB  -   -
 primary -   0-  -   -

 disk_config sda disklabel:gpt align-at:1M
 primary -   0-  -   -

 disk_config sdb disklabel:gpt align-at:1M
 primary -   0-  -   -

 disk_config raid fstabkey:uuid
 raid1   /boot   nvme0n1p2,nvme1n1p2 ext4rw,noatime,errors=remount-
 ro
 raid1   -   nvme0n1p3,nvme1n1p3 -   -
 raid1   -   sda1,sdb1   -   -

 # FAI defaults to -c aes-xts-plain64 -s 256
 disk_config cryptsetup
 luks-   /dev/md1-   -
 luks-   /dev/md2-   -

 disk_config lvm fstabkey:uuid
 # previous convention was "vg_$hostname"
 vg  vg_nvme md1
 vg_nvme-root/   30G ext4rw
 vg_nvme-swapswap1G  swapsw

 vg  vg_hdd  md2

 # HDD disks config intentionally left blank
 }}}

  4. install the system, modified version:

 {{{
 mkdir -p /target && mount /dev/vg_nvme/root /target &&
 mkdir -p /target/boot && mount /dev/md0 /target/boot &&
 mkdir -p /target/run && mount -t tmpfs tgt-run /target/run &&
 mkdir /target/run/udev && mount -o bind /run/udev /target/run/udev
 &&
 bootdisk=/dev/nvme1n1 &&
 ROOTPASSWORD=$(tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 30) &&
 apt-get install -y grml-debootstrap && \
 sed -e 's/postfix//;
 s/vlan//;
 s/bridge-utils//;
 s/ifenslave//;
 s/resolvconf//;
 s/zsh//;
 s/strace//;
 s/os-prober//;
 s/bzip2//;
 s/file//;
 s/lsof//;
 s/most//;
 $adbus
 $acryptsetup-initramfs
 ' /etc/debootstrap/packages > /root/grml-packages &&
 grml-debootstrap --grub "$bootdisk" --target /target \
 --hostname `hostname` --release buster \
 --mirror https://mirror.hetzner.de/debian/packages/ \
 --packages /root/grml-packages \
 --password "$ROOTPASSWORD" \
 --remove-configs --defaultinterfaces &&
 umount /target/run/udev /target/run
 }}}

 I've also reset the LUKS passphrases with:

 {{{
 LUKS_PASSPHRASE=$(tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 30) &&
 echo $LUKS_PASSPHRASE | cryptsetup luksAddKey /dev/md1 --key-
 file=/tmp/fai/crypt_dev_md1 &&
 echo $LUKS_PASSPHRASE | cryptsetup luksAddKey /dev/md2 --key-
 file=/tmp/fai/crypt_dev_md2 &&
 cryptsetup luksRemoveKey /dev/md1 --key-file=/tmp/fai/crypt_dev_md1 &&
 cryptsetup luksRemoveKey /dev/md2 --key-file=/tmp/fai/crypt_dev_md2
 }}}

  4. step 4 is replaced with:

 {{{
 ( cat /tmp/fai/fstab ; echo ; echo tmpfs /tmp tmpfs defaults,size=512m 0 0
 ) > /target/etc/fstab
 }}}

 that tmpfs stuff could probably be merged into the setup-storage
 configuration.

  5. this step was step 11 and moved up so we avoid regenerating the initrd
 for nothing

  6. i rewired the luks-setup script so that it correctly deals with
 multiple PVs setup, and hardcoded the "discard" option because i think
 it's fair to assume / is on SSD.

  7. now a noop

  8. done

  9. done, weirdly doesn't match the output of FAI

  10. I had to run this before step 9 to make grub happy:

 {{{
 parted --script /dev/nvme0n1 set 1 bios_grub on
 parted --script /dev/nvme1n1 set 1 bios_grub on
 }}}

  11. network looks good (DHCP)

  12. regen'd, need to 

Re: [tor-bugs] #33029 [Core Tor/Tor]: dir-auth: Never send a 503 directory request code to another directory authority

2020-01-22 Thread Tor Bug Tracker & Wiki
#33029: dir-auth: Never send a 503 directory request code to another directory
authority
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #33018| Points:  0.4
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Looks good! A small issue:

 * "is the one of a configured directory" -> "is a configured directory"

 and a bigger issue:

 * "so it might get a 503 code and thus fail the upload of its brand new
 descriptor" -- I don't think you can get a 503 in response to a post
 attempt. That is, we only check global_write_bucket_low() in five cases:
   * handle_get_current_consensus(), in response to a vanilla or microdesc
 consensus request
   * handle_get_status_vote(), for when somebody is asking for our current
 or most recent vote [that one's fun because only dir auths serve votes,
 and previously dir auths would never decide to reply with a 503]
   * handle_get_microdesc(), when somebody is asking for individual
 microdescs
   * handle_get_descriptor(), same as above but for vanilla descriptors
   * handle_get_keys(), when somebody is asking for authority certificates

   So the "To clarify further the situation:" paragraph in the commit
 comment needs to change. I think the problematic scenario is that relays
 try to fetch new consensus and descriptor documents from authorities,
 because directory_fetches_from_authorities(), but the authorities give
 them a 503 and then they don't have a proper cached version to give out
 when clients come asking, and then clients don't get their network view
 and it all falls apart.

   That's why this patch here should be ok for one or two authorities to
 run, but not more, until we also do the "whitelist relays" piece of it.

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

Re: [tor-bugs] #32193 [Core Tor/Tor]: update .gitlab-ci.yml to remove broken cruft and add a complete test suite

2020-01-22 Thread Tor Bug Tracker & Wiki
#32193: update .gitlab-ci.yml to remove broken cruft and add a complete test 
suite
-+-
 Reporter:  eighthave|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, gitlab-ci, tor-ci, 043-can  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  hiro, catalyst   |Sponsor:
-+-

Comment (by eighthave):

 If you push the existing .gitlab-ci.yml to any gitlab.com fork, you will
 see that the CI job results in a broken build.  In my fork, you can see
 the jobs working.  Each job has a full log, that is literally just a log
 of the bash script running, e.g. the `script:` sections of .gitlab-ci.yml

--
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] #32954 [Core Tor/Tor]: Stop public authorities specifying an internal address for their IPv6 ORPort

2020-01-22 Thread Tor Bug Tracker & Wiki
#32954: Stop public authorities specifying an internal address for their IPv6
ORPort
--+--
 Reporter:  teor  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #30954| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * cc: neel (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] #32994 [Core Tor/Tor]: Get all flag defaults from port_cfg_new()

2020-01-22 Thread Tor Bug Tracker & Wiki
#32994: Get all flag defaults from port_cfg_new()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-client, easy,|  Actual Points:
  intro  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  new => assigned
 * cc: neel (added)
 * owner:  (none) => neel


--
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] #32954 [Core Tor/Tor]: Stop public authorities specifying an internal address for their IPv6 ORPort

2020-01-22 Thread Tor Bug Tracker & Wiki
#32954: Stop public authorities specifying an internal address for their IPv6
ORPort
--+--
 Reporter:  teor  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #30954| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  new => assigned
 * owner:  (none) => neel


--
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] #32711 [Applications/GetTor]: Gitlab repository is full and can't be updated

2020-01-22 Thread Tor Bug Tracker & Wiki
#32711: Gitlab repository is full and can't be updated
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gitlab   |  Actual Points:  3
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
-+--
Changes (by cohosh):

 * status:  needs_revision => needs_review


Comment:

 Thanks, made some changes.

--
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] #32937 [Internal Services/Tor Sysadmin Team]: install a new node in the gnt-fsn cluster (fsn-node-03)

2020-01-22 Thread Tor Bug Tracker & Wiki
#32937: install a new node in the gnt-fsn cluster (fsn-node-03)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 okay, after help from MrFai on IRC, I got this config to work, which is
 pretty frigging awesome:

 {{{
 # open questions
 # --align=optimal?
 # leave keys in /tmp/fai or specify passphrase?
 # use sameas: to set all disk names earlier?
 # bios_grub flag?

 disk_config nvme0n1 disklabel:gpt bootable:2
 # bios grub second stage
 primary -   8MiB-   -
 # /boot
 primary -   512MiB  -   -
 # rest is RAID+LUKS+LVM
 primary -   0-  -   -

 disk_config nvme1n1 disklabel:gpt bootable:2
 # same as above
 primary -   8MiB-   -
 primary -   512MiB  -   -
 primary -   0-  -   -

 disk_config sda disklabel:gpt
 primary -   0-  -   -

 disk_config sdb disklabel:gpt
 primary -   0-  -   -

 disk_config raid fstabkey:uuid
 raid1   /boot   nvme0n1p2,nvme1n1p2 ext4rw,noatime,errors=remount-
 ro
 raid1   -   nvme0n1p3,nvme1n1p3 -   -
 raid1   -   sda1,sdb1   -   -

 # FAI defaults to -c aes-xts-plain64 -s 256
 disk_config cryptsetup
 luks-   /dev/md1-   -
 luks-   /dev/md2-   -

 disk_config lvm fstabkey:uuid
 # previous convention was "vg_$hostname"
 vg  vg_nvme md1
 vg_nvme-root/   30G ext4rw
 vg_nvme-swapswap1G  swapsw

 vg  vg_hdd  md2

 # HDD disks config intentionally left blank
 }}}

 This gives us the following non-verbose run, which is also pretty awesome:

 {{{
 root@rescue ~ # setup-storage -f setup-storage-fsn-node-3 -X
 Starting setup-storage 2.2
 Using config file: setup-storage-fsn-node-3
 No volume groups found.
 Executing: wipefs -af /dev/nvme0n1p1
 Executing: wipefs -af /dev/nvme1n1p1
 Executing: mdadm --stop --scan
 Executing: mdadm --assemble --scan --config=/tmp/fai/mdadm-from-
 examine.conf
 Executing: mdadm -W --stop /dev/md0
 Executing: mdadm -W --stop /dev/md1
 Executing: mdadm -W --stop /dev/md2
 Executing: head -c 2048 /dev/urandom | od | tee /tmp/fai/crypt_dev_md1
 Executing: head -c 2048 /dev/urandom | od | tee /tmp/fai/crypt_dev_md2
 Executing: wipefs -af /dev/nvme0n1p2
 Executing: wipefs -af /dev/nvme0n1p3
 Executing: parted -s /dev/nvme0n1 mklabel gpt
 Executing: parted -s /dev/nvme0n1 mkpart primary "" 1048576B 9437183B
 Executing: parted -s /dev/nvme0n1 mkpart primary "" 9437184B 546308095B
 Executing: parted -s /dev/nvme0n1 set 2 boot on
 Executing: parted -s /dev/nvme0n1 mkpart primary "" 546308096B
 960197107199B
 Executing: wipefs -af /dev/sdb1
 Executing: parted -s /dev/sdb mklabel gpt
 Executing: parted -s /dev/sdb mkpart primary "" 1048576B 1831331839B
 Executing: wipefs -af /dev/sda1
 Executing: parted -s /dev/sda mklabel gpt
 Executing: parted -s /dev/sda mkpart primary "" 1048576B 1831331839B
 Executing: wipefs -af /dev/nvme1n1p2
 Executing: wipefs -af /dev/nvme1n1p3
 Executing: parted -s /dev/nvme1n1 mklabel gpt
 Executing: parted -s /dev/nvme1n1 mkpart primary "" 1048576B 9437183B
 Executing: parted -s /dev/nvme1n1 mkpart primary "" 9437184B 546308095B
 Executing: parted -s /dev/nvme1n1 set 2 boot on
 Executing: parted -s /dev/nvme1n1 mkpart primary "" 546308096B
 960197107199B
 Executing: parted -s /dev/nvme1n1 set 2 raid on
 Executing: parted -s /dev/nvme0n1 set 2 raid on
 Executing: parted -s /dev/nvme0n1 set 3 raid on
 Executing: parted -s /dev/nvme1n1 set 3 raid on
 Executing: parted -s /dev/sdb set 1 raid on
 Executing: parted -s /dev/sda set 1 raid on
 Executing: yes | mdadm --create  /dev/md0 --level=raid1 --force --run
 --raid-devices=2 /dev/nvme1n1p2 /dev/nvme0n1p2
 Executing: mkfs.ext4  /dev/md0
 Executing: yes | mdadm --create  /dev/md1 --level=raid1 --force --run
 --raid-devices=2 /dev/nvme0n1p3 /dev/nvme1n1p3
 Executing: yes | mdadm --create  /dev/md2 --level=raid1 --force --run
 --raid-devices=2 /dev/sdb1 /dev/sda1
 Executing: yes YES | cryptsetup luksFormat /dev/md1 /tmp/fai/crypt_dev_md1
 Executing: cryptsetup luksOpen /dev/md1 crypt_dev_md1 --key-file
 /tmp/fai/crypt_dev_md1
 Executing: yes YES | cryptsetup luksFormat /dev/md2 /tmp/fai/crypt_dev_md2
 Executing: cryptsetup luksOpen /dev/md2 crypt_dev_md2 --key-file
 

Re: [tor-bugs] #33028 [- Select a component]: v0.4.1.6 bug journalctl failed assertion

2020-01-22 Thread Tor Bug Tracker & Wiki
#33028: v0.4.1.6 bug journalctl failed assertion
--+--
 Reporter:  anonproject   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  - Select a component  |Version:  Tor: 0.4.1.6
 Severity:  Normal| Resolution:
 Keywords:  hs cache, newnym  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by anonproject):

 Another one:

 Jan 22 22:33:33 v79604.kvm.u21699 Tor[25477]:
 connection_ap_attach_pending(): Bug: 0x5567991c1c40 is no longer in
 circuit_wait. Its current state is waiting for rendezvous desc. Why is it
 on pending_entry_connections? (on Tor 0.4.1.6 )

--
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] #33005 [Core Tor/Tor]: Lower log level of standard error messages from PT's

2020-01-22 Thread Tor Bug Tracker & Wiki
#33005: Lower log level of standard error messages from PT's
--+--
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:  Sponsor28
--+--
Changes (by dgoulet):

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


Comment:

 Trivial. Merged!

--
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] #32193 [Core Tor/Tor]: update .gitlab-ci.yml to remove broken cruft and add a complete test suite

2020-01-22 Thread Tor Bug Tracker & Wiki
#32193: update .gitlab-ci.yml to remove broken cruft and add a complete test 
suite
-+-
 Reporter:  eighthave|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, gitlab-ci, tor-ci, 043-can  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  hiro, catalyst   |Sponsor:
-+-
Changes (by dgoulet):

 * reviewer:  dgoulet => hiro, catalyst


Comment:

 So this is quite large change to the .gitlab.yaml file but I have no way
 to confirm it works or makes senses actually as I have no clue what that
 file does.

 @hiro, @catalyst: makes sense 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] #32614 [Core Tor/Tor]: hs-v3: Consider flagging an intro point as bad if rendezvous fails multiple times

2020-01-22 Thread Tor Bug Tracker & Wiki
#32614: hs-v3: Consider flagging an intro point as bad if rendezvous fails 
multiple
times
-+--
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, tor-hs  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:  Sponsor27-can
-+--
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * keywords:  tor-circuit, tor-hs, 043-can => tor-circuit, tor-hs
 * milestone:  Tor: 0.4.3.x-final => Tor: unspecified


--
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] #33031 [Internal Services/Service - nextcloud]: Expired TLS Cert

2020-01-22 Thread Tor Bug Tracker & Wiki
#33031: Expired TLS Cert
-+-
 Reporter:  sysrqb   |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by sysrqb:

Old description:

> {{{
> Websites prove their identity via certificates, which are valid for a set
> time period. The certificate for nc.torproject.net expired on January 22,
> 2020.
>
> Error code: SEC_ERROR_EXPIRED_CERTIFICATE
> }}}

New description:

 {{{
 Websites prove their identity via certificates, which are valid for a set
 time period. The certificate for nc.torproject.net expired on January 22,
 2020.

 Error code: SEC_ERROR_EXPIRED_CERTIFICATE
 }}}

--

--
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] #32998 [Internal Services/Tor Sysadmin Team]: Upgrade metrics hosts to buster

2020-01-22 Thread Tor Bug Tracker & Wiki
#32998: Upgrade metrics hosts to buster
-+-
 Reporter:  karsten  |  Owner:  anarcat
 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 anarcat):

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


Comment:

 great! removed the old cluster and scheduled backup removals in one week
 from now:

 {{{
 root@bungei:~# echo 'rm -r /srv/backups/pg/meronense-9.6/' | at now + 7day
 warning: commands will be executed using /bin/sh
 job 17 at Wed Jan 29 19:18:00 2020
 }}}

 closing now. other metrics hosts will be done as part of the regular
 buster upgrade schedule and your team will receive a 2 day advance notice,
 as requested. :)

--
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] #33031 [Internal Services/Service - nextcloud]: Expired TLS Cert

2020-01-22 Thread Tor Bug Tracker & Wiki
#33031: Expired TLS Cert
-+-
 Reporter:  sysrqb   |  Owner:  nextcloud-
 |  admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 Websites prove their identity via certificates, which are valid for a set
 time period. The certificate for nc.torproject.net expired on January 22,
 2020.

 Error code: SEC_ERROR_EXPIRED_CERTIFICATE
 }}}

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 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] #33005 [Core Tor/Tor]: Lower log level of standard error messages from PT's

2020-01-22 Thread Tor Bug Tracker & Wiki
#33005: Lower log level of standard error messages from PT's
--+--
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor28
--+--
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 Updated PR as per Teor's comment.

--
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] #32672 [Core Tor/Tor]: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE BEFORE FEB 2020]

2020-01-22 Thread Tor Bug Tracker & Wiki
#32672: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE
BEFORE FEB 2020]
-+-
 Reporter:  teor |  Owner:  neel
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  044-should, 043-backport,|  Actual Points:
  041-backport, 042-backport, consider-  |
  backport-after-authority-test, fast-fix,   |
  network-health 043-should  |
Parent ID:   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * keywords:
 043-should, 041-backport, 042-backport, consider-backport-after-
 authority-test, fast-fix, network-health 043-should
 =>
 044-should, 043-backport, 041-backport, 042-backport, consider-
 backport-after-authority-test, fast-fix, network-health 043-should
 * milestone:  Tor: 0.4.3.x-final => Tor: 0.4.4.x-final


Comment:

 I'm thinking this is better for the 0.4.4 timeline.

--
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] #33029 [Core Tor/Tor]: dir-auth: Never send a 503 directory request code to another directory authority

2020-01-22 Thread Tor Bug Tracker & Wiki
#33029: dir-auth: Never send a 503 directory request code to another directory
authority
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #33018| Points:  0.4
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * points:  0.2 => 0.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] #33029 [Core Tor/Tor]: dir-auth: Never send a 503 directory request code to another directory authority

2020-01-22 Thread Tor Bug Tracker & Wiki
#33029: dir-auth: Never send a 503 directory request code to another directory
authority
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #33018| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 Branch: `ticket33029_043_01`
 PR: https://github.com/torproject/tor/pull/1681

--
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] #32872 [Circumvention/Pluggable transport]: New https-proxy implementation for shared hosting

2020-01-22 Thread Tor Bug Tracker & Wiki
#32872: New https-proxy implementation for shared hosting
---+---
 Reporter:  SomeoneElse|  Owner:  Nusenu
 Type:  project| Status:
   |  needs_information
 Priority:  Medium |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by phw):

 * status:  new => needs_information


Comment:

 I don't understand this. Can you please share your implementation, or
 elaborate on the design?

--
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] #33030 [Applications/rbm]: rust-android-x86 fails to build

2020-01-22 Thread Tor Bug Tracker & Wiki
#33030: rust-android-x86 fails to build
--+--
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * Attachment "rust-android-x86.log" 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

[tor-bugs] #33030 [Applications/rbm]: rust-android-x86 fails to build

2020-01-22 Thread Tor Bug Tracker & Wiki
#33030: rust-android-x86 fails to build
--+--
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Completely freshly installed Debian buster, all packages listed in the
 README installed. Build attempted via:
 {{{make release}}}

 Build log: https://people.torproject.org/~richard/logs/rust-
 android-x86.log

 Currently trying again with:
 {{{./rbm/rbm build rust --target release --target torbrowser-
 android-x86}}}

--
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] #32335 [Core Tor/Tor]: Set up a .github repository on GitHub

2020-01-22 Thread Tor Bug Tracker & Wiki
#32335: Set up a .github repository on GitHub
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 This page is supposed to be "global" and be informative about *all* Tor-
 related projects we have on github.com/torproject right?

--
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] #31332 [Metrics/Relay Search]: Please update the FallbackDir flags in relay search

2020-01-22 Thread Tor Bug Tracker & Wiki
#31332: Please update the FallbackDir flags in relay search
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

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


Comment:

 Done. Sorry that this took so long. Closing.

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Ah sorry missed that table:
 https://share.riseup.net/#Dpifs9Y9WxPGscwrlLiiVA

--
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] #21883 [Metrics/Analysis]: Perform one-off analysis for number of relays a bwauth decided the median for

2020-01-22 Thread Tor Bug Tracker & Wiki
#21883: Perform one-off analysis for number of relays a bwauth decided the 
median
for
--+
 Reporter:  Sebastian |  Owner:  tom
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  metrics-2018  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by karsten):

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


Comment:

 Replying to [comment:7 tom]:
 > I don't think anything needs to be done, unless Sebastian or Karsten or
 anyone has comments about the graphs (either the look or questions about
 the data.)  Although it's been a while since I generated them so I will
 need to relearn what I did ;)

 Nothing to be done here. The historical graphs look good, and I just
 checked that there are current ones on Consensus Health. Closing this
 ticket. If anybody has ideas for making them better, they're likely going
 to open a new ticket anyway. 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] #32997 [Circumvention/BridgeDB]: Captcha error on bridges.torproject.org

2020-01-22 Thread Tor Bug Tracker & Wiki
#32997: Captcha error on bridges.torproject.org
+---
 Reporter:  amirhossein |  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Immediate   |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Major   | Resolution:  duplicate
 Keywords:  bridgedb-reportbug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by phw):

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


Comment:

 Thanks for your bug report. I'm sorry that you were struggling with the
 CAPTCHAs. We know that they are often difficult to solve, and we plan to
 work on this soon. In the meanwhile, I'm closing this ticket as a
 duplicate because we already have a bug report for this: #24607.

--
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] #28871 [Metrics/Onionoo]: Relay with 6 weeks downtime only has 6_months and 5_years bandwidth graphs

2020-01-22 Thread Tor Bug Tracker & Wiki
#28871: Relay with 6 weeks downtime only has 6_months and 5_years bandwidth 
graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * priority:  Low => Medium


Comment:

 This ticket has the same priority as most other defects in this component.
 Changing to medium.

--
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] #31009 [Core Tor/Tor]: Tor lets transports advertise private IP addresses in descriptor

2020-01-22 Thread Tor Bug Tracker & Wiki
#31009: Tor lets transports advertise private IP addresses in descriptor
-+-
 Reporter:  phw  |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, tor-bridge, 035-backport,|  Actual Points:
  040-backport, 041-backport,|
  042-deferred-20190918, network-team-roadmap-   |
  2020Q1 |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-
Changes (by ahf):

 * status:  needs_revision => assigned
 * owner:  (none) => ahf
 * reviewer:  ahf =>


Comment:

 I'm assigning myself to help with the IPv6 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] #32998 [Internal Services/Tor Sysadmin Team]: Upgrade metrics hosts to buster

2020-01-22 Thread Tor Bug Tracker & Wiki
#32998: Upgrade metrics hosts to buster
-+-
 Reporter:  karsten  |  Owner:  anarcat
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Everything looks good now. Feel free to proceed with removing the old
 cluster. Maybe keep the backups a few more days just in case. Thanks for
 your support yesterday!

--
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] #30351 [Metrics/Website]: Unknown error in prepare_* functions using the spread() function

2020-01-22 Thread Tor Bug Tracker & Wiki
#30351: Unknown error in prepare_* functions using the spread() function
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 The spread() function works fine again using buster's r-cran-tidyr 0.8.2-1
 package, whereas it was previously broken with stretch's r-cran-tidyr
 0.6.1-1 package.

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 web.git/commit/?h=task-30351=ca90cf134c1e759debbb2b925c7ec785ba0131ad
 commit ca90cf1 in my task-30351 branch].

--
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] #32937 [Internal Services/Tor Sysadmin Team]: install a new node in the gnt-fsn cluster (fsn-node-03)

2020-01-22 Thread Tor Bug Tracker & Wiki
#32937: install a new node in the gnt-fsn cluster (fsn-node-03)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 worked on the setup-storage config, which currently looks like this:

 {{{
 # open questions
 # --align=optimal?
 # leave keys in /tmp/fai or specify passphrase?
 # use sameas: to set all disk names earlier?
 # bios_grub flag?

 disk_config nvme0n1 disklabel:gpt bootable:2
 # bios grub second stage
 primary -   8MiB-   -
 # /boot
 primary -   512MiB  -   -
 # rest is RAID+LUKS+LVM
 primary -   0-  -   -

 disk_config nvme1n1 disklabel:gpt bootable:2
 # same as above
 primary -   8MiB-   -
 primary -   512MiB  -   -
 primary -   0-  -   -

 disk_config sda disklabel:gpt
 primary -   0-  -   -

 disk_config sdb disklabel:gpt
 primary -   0-  -   -

 disk_config raid fstabkey:uuid
 raid1   /boot   nvme0n1p2,nvme1n1p2 ext4rw,noatime,errors=remount-
 ro
 raid1   -   nvme0n1p3,nvme1n1p3 -   -
 raid1   -   sda1,sdb1   -   -

 # FAI defaults to -c aes-xts-plain64 -s 256
 disk_config cryptsetup
 luks-   /dev/md1-   -
 luks-   /dev/md2-   -

 disk_config lvm fstabkey:uuid
 # previous convention was "vg_$hostname"
 vg  vg_nvme crypt_format_md1
 vg_nvme-root/   30G ext4rw
 vg_nvme-swapswap1G  swapsw
 vg  vg_hdd  crypt_format_md2

 # HDD disks config intentionally left blank

 }}}

 and fails like this:

 {{{
 root@rescue ~ # setup-storage -f setup-storage-fsn-node-3 -d -X
 disklist: nvme0n1
 nvme1n1
 sda
 sdb
 Starting setup-storage 2.2
 Using config file: setup-storage-fsn-node-3
 Input was:
 # open questions
 # --align=optimal?
 # leave keys in /tmp/fai or specify passphrase?
 # use sameas: to set all disk names earlier?
 # bios_grub flag?

 disk_config nvme0n1 disklabel:gpt bootable:2
 # bios grub second stage
 primary -   8MiB-   -
 # /boot
 primary -   512MiB  -   -
 # rest is RAID+LUKS+LVM
 primary -   0-  -   -

 disk_config nvme1n1 disklabel:gpt bootable:2
 # same as above
 primary -   8MiB-   -
 primary -   512MiB  -   -
 primary -   0-  -   -

 disk_config sda disklabel:gpt
 primary -   0-  -   -

 disk_config sdb disklabel:gpt
 primary -   0-  -   -

 disk_config raid fstabkey:uuid
 raid1   /boot   nvme0n1p2,nvme1n1p2 ext4rw,noatime,errors=remount-
 ro
 raid1   -   nvme0n1p3,nvme1n1p3 -   -
 raid1   -   sda1,sdb1   -   -

 # FAI defaults to -c aes-xts-plain64 -s 256
 disk_config cryptsetup
 luks-   /dev/md1-   -
 luks-   /dev/md2-   -

 disk_config lvm fstabkey:uuid
 # previous convention was "vg_$hostname"
 vg  vg_nvme crypt_format_md1
 vg_nvme-root/   30G ext4rw
 vg_nvme-swapswap1G  swapsw
 vg  vg_hdd  crypt_format_md2

 # HDD disks config intentionally left blank
 (CMD) parted -s /dev/nvme0n1 unit TiB print 1> /tmp/vg8ajSauDw 2>
 /tmp/vMMazFsqO7
 Executing: parted -s /dev/nvme0n1 unit TiB print
 (STDERR) Error: /dev/nvme0n1: unrecognised disk label
 (STDOUT) Model: SAMSUNG MZQLB960HAJR-7 (nvme)
 (STDOUT) Disk /dev/nvme0n1: 0.87TiB
 (STDOUT) Sector size (logical/physical): 512B/512B
 (STDOUT) Partition Table: unknown
 (STDOUT) Disk Flags:
 Parted could not read a disk label (new disk?)
 (CMD) parted -s /dev/nvme0n1 mklabel gpt 1> /tmp/MK287MFjgl 2>
 /tmp/55bOjMK73A
 Executing: parted -s /dev/nvme0n1 mklabel gpt
 (CMD) parted -s /dev/nvme0n1 unit TiB print 1> /tmp/NuP83_L6et 2>
 /tmp/kubLOQr9Wo
 Executing: parted -s /dev/nvme0n1 unit TiB print
 (STDOUT) Model: SAMSUNG MZQLB960HAJR-7 (nvme)
 (STDOUT) Disk /dev/nvme0n1: 0.87TiB
 (STDOUT) Sector size (logical/physical): 512B/512B
 (STDOUT) Partition Table: gpt
 (STDOUT) Disk Flags:
 (STDOUT)
 (STDOUT) Number  Start  End  Size  File system  Name  Flags
 (STDOUT)
 (CMD) parted -s /dev/nvme0n1 unit B print free 1> /tmp/FN2KfViTkm 2>
 /tmp/y2Pytod_rd
 Executing: parted -s /dev/nvme0n1 unit B print free
 (STDOUT) Model: SAMSUNG MZQLB960HAJR-7 (nvme)
 (STDOUT) Disk /dev/nvme0n1: 960197124096B
 (STDOUT) Sector size 

[tor-bugs] #33029 [Core Tor/Tor]: dir-auth: Never send a 503 directory request code to another directory authority

2020-01-22 Thread Tor Bug Tracker & Wiki
#33029: dir-auth: Never send a 503 directory request code to another directory
authority
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-dirauth
Actual Points:|  Parent ID:  #33018
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 This is a child ticket from #33018.

 The idea here is that even if we hit the global write limit (bw), we
 should not return 503 code but rather answer another directory authority.

 Dirauth _must_ be able to talk to each other at all time regardless of the
 bandwidth state.

 Setting 043 milestone because this should be considered a bug and could
 even be considered for backport since dirauth are suffering from this at
 the moment.

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 looks good. you're missing a bit in the README however - that's just the
 reference for a link, that link should also be added in the table above,
 IIRC. :)

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 New patch: https://share.riseup.net/#C2snYlmvXmWXkwiCyqYbYw

--
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] #33028 [- Select a component]: v0.4.1.6 bug journalctl failed assertion

2020-01-22 Thread Tor Bug Tracker & Wiki
#33028: v0.4.1.6 bug journalctl failed assertion
--+--
 Reporter:  anonproject   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Component:  - Select a component
  Version:  Tor: 0.4.1.6  |   Severity:  Normal
 Keywords:  hs cache, newnym  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Using tor as a relay and a client to make a batches on requests to onion
 domains; cleaning HS cache from time to time (NEWNYM signal).
 On some machines encountered th following in the system journal:


 {{{
 ```log
 Jan 22 17:49:45 xxx Tor[19497]: tor_bug_occurred_(): Bug:
 src/feature/hs/hs_client.c:685: setup_intro_circ_auth_key: Non-fatal
 assertion !(desc == NULL) failed. (Future instances of this warning will
 be silenced.) (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: Non-fatal assertion !(desc == NULL)
 failed in setup_intro_circ_auth_key at src/feature/hs/hs_client.c:685.
 Stack trace: (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /usr/bin/tor(log_backtrace_impl+0x47) [0x55c488cdfe77] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /usr/bin/tor(tor_bug_occurred_+0x186) [0x55c488cdb576] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /usr/bin/tor(hs_client_circuit_has_opened+0x3cf) [0x55c488bd10ff] (on Tor
 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /usr/bin/tor(circuit_send_next_onion_skin+0x2a8) [0x55c488b4d7f8] (on Tor
 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: /usr/bin/tor(+0x1469ca)
 [0x55c488b839ca] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /usr/bin/tor(circuit_receive_relay_cell+0x321) [0x55c488b85a71] (on Tor
 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /usr/bin/tor(command_process_cell+0x17f) [0x55c488b6761f] (on Tor 0.4.1.6
 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /usr/bin/tor(channel_tls_handle_cell+0x2bb) [0x55c488b4785b] (on Tor
 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: /usr/bin/tor(+0x1331af)
 [0x55c488b701af] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /usr/bin/tor(connection_handle_read+0x8f8) [0x55c488b35458] (on Tor
 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: /usr/bin/tor(+0xfd741)
 [0x55c488b3a741] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /lib64/libevent-2.0.so.5(event_base_loop+0x774) [0x7f8cd2272a14] (on Tor
 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: /usr/bin/tor(do_main_loop+0xd2)
 [0x55c488b3ba62] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: /usr/bin/tor(tor_run_main+0x11fd)
 [0x55c488b298dd] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: /usr/bin/tor(tor_main+0x3a)
 [0x55c488b26e2a] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: /usr/bin/tor(main+0x19)
 [0x55c488b26999] (on Tor 0.4.1.6 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug:
 /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f8cd118b505] (on Tor 0.4.1.6
 )
 Jan 22 17:49:45 xxx Tor[19497]: Bug: /usr/bin/tor(+0xe99eb)
 [0x55c488b269eb] (on Tor 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: tor_bug_occurred_(): Bug:
 src/feature/hs/hs_client.c:491: intro_circ_is_ok: Non-fatal assertion
 !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (Future instances
 of this warning will be silenced.) (on Tor 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug: Non-fatal assertion
 !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in
 intro_circ_is_ok at src/feature/hs/hs_client.c:491. Stack trace: (on Tor
 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(log_backtrace_impl+0x47) [0x55c488cdfe77] (on Tor 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(tor_bug_occurred_+0x186) [0x55c488cdb576] (on Tor 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(hs_client_send_introduce1+0x347) [0x55c488bd0bc7] (on Tor
 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(connection_ap_handshake_attach_circuit+0x7da)
 [0x55c488b660ba] (on Tor 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(connection_ap_attach_pending+0x198) [0x55c488b69fd8] (on Tor
 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(hs_client_receive_rendezvous_acked+0x7c) [0x55c488bd11ac] (on
 Tor 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(rend_process_relay_cell+0x113) [0x55c488c1a383] (on Tor
 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug: /usr/bin/tor(+0x1467e8)
 [0x55c488b837e8] (on Tor 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(circuit_receive_relay_cell+0x321) [0x55c488b85a71] (on Tor
 0.4.1.6 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(command_process_cell+0x17f) [0x55c488b6761f] (on Tor 0.4.1.6
 )
 Jan 22 17:49:46 xxx Tor[19497]: Bug:
 /usr/bin/tor(channel_tls_handle_cell+0x2bb) [0x55c488b4785b] (on Tor
 0.4.1.6 )
 

Re: [tor-bugs] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 uh! so then you're right i guess! :) move along, sorry :)

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Replying to [comment:2 anarcat]:

 > lower down, the `scrape_configs` array looks a bit strange to me.
 normally, the targets there look like `example.com:9091`, ie. with a port
 number at least. unless https://bridges.torproject.org/metrics actually
 gives out prometheus-compatible metrics (aka "OpenMetrics"). that doesn't
 seem to be the case right now (it's a 404).

 Uhm I read through the documentation of the blackbox expoter:
 https://github.com/prometheus/blackbox_exporter#prometheus-configuration

 As far as I can understand it's about the returned status code?

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Replying to [comment:2 anarcat]:
 > the grafana dashboard is, as expected, kind of undecipherable. :) so
 much JSON! so we can review this once it's pulled in the GUI... no harm
 done their either way, so that's okay.
 >



 Sure. I pulled it from the dashboard database. But I have should have
 added the link to the dashboard itself. I am going to do this.



 > you might have missed it, but `modules/profile/files/grafana/dashboards`
 is its own repository. it's one of those dark corners of the Puppet
 repository, which is currently a huge monorepo, but that does have some
 subrepos somehow. i'm looking into how to deal with that problem in
 #30770, in general. in particular, my remote for this repo right now is
 `g...@gitlab.com:anarcat/grafana-dashboards.git` because i didn't want to
 go through the trouble of creating a project in gitolite and all that
 stuff. i could either give you access to that, or we could move it
 somewhere else, or i could just push the changes myself.



 I can create a git repository or we can just leave it like it is. Whatever
 works better for you in this case.



 >
 > in any case, it would be great if you could document the dashboard's in
 the README file next to it so we know where it comes from and so on.
 >
 > as for the puppet work, the blackbox exporter class looks sane. i don't
 see it included anywhere in the patch though, so i'm not sure how it
 should work.



 I haven't included it yet. This will come in the next iteration.



 >
 > lower down, the `scrape_configs` array looks a bit strange to me.
 normally, the targets there look like `example.com:9091`, ie. with a port
 number at least. unless https://bridges.torproject.org/metrics actually
 gives out prometheus-compatible metrics (aka "OpenMetrics"). that doesn't
 seem to be the case right now (it's a 404).
 >
 > >  What is missing is the possibility for the service admins to add more
 targets without having to send patches to our puppet.
 >
 > That's going to be the tough part. Because the blackbox exporter is
 managed through puppet, in this configuration, we forcibly control the
 config file and local changes would be lost. So it's really one of three
 things:
 >
 >  1. they send us the target and so we need to intervene when that needs
 to be changed
 >  2. we patch the module to allow us to *not* manage the blackbox config
 (yet another patch to the module, we can take it)
 >  3. we just *not* manage the blackbox exporter through puppet at all,
 and add it manually to the `scrape_configs` target.
 >
 > I would do option 2, eventually, and start with option 1. makes sense?

 Yep makes sense.

--
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] #32937 [Internal Services/Tor Sysadmin Team]: install a new node in the gnt-fsn cluster (fsn-node-03)

2020-01-22 Thread Tor Bug Tracker & Wiki
#32937: install a new node in the gnt-fsn cluster (fsn-node-03)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 we toyed with the idea of getting a AX line here, which i documented in
 the new-machine page, but ended up going with the regular PX thing.

 the box is now up, with the following pubkeys:

 {{{
 ssh-dss
 
B3NzaC1kc3MAAACBAMljYhWq1MpFbijeTwP0ymSOPGuneFbjEGIqPWoY/qVd+ZtPl7i0Zb3HmkApX3bekvv2yWP+svZA1d30Omli/FzEtJfMUfssqPbE5gqEot+nGMhPXPvwsxs/t7FO0k0xFVzzFsypTm4+RFRiKqWY4gvwwwDfHv3n8NfyO+jOUga9FQDDltXnrmUiHcGTqFfUzEyokKvYlwAAAIEArFEoY00Rd4w18/utCLE2Y5MXVDFZXxgcVV+HPq+k9unfGZjK+jRRUKhq+yqSVIMdGoy65ddCB4/YRke+wQWgNr+Q6BGUf1ROWalhv1/rpbqq8Vmpf2D46yRgYEhUmLOljrXVEC7a1cPiX3cQRfL5CV4enmCLF9S/ZHvDIPAv2mYAAACAXabnKEAS+2kfc4wxJ19N/YmKbLZ+LpwEqX4/q6vN7OZ+SwIXAw749A1HvVV3PjUdR47tzsA/9hiT8UkXPLRjmA8wSXiKnyrYVHjl8ouEu4h35On89+ZxFXz406llHlCb52fFrH1YpfFuzEHEzJyjSoCcnn4ZIU1AQw5Y7OdJcbA=
 ecdsa-sha2-nistp256
 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBFF0WC3IaJuPiiuFYn8nGxbunNA8VbYMXKtmIIzED5DvcFc9Fy6x9M5KKY5gBvjFrZMGwDqnuXszmbGawviR4CU=
 ssh-ed25519
 C3NzaC1lZDI1NTE5ICXo6tObnMENCT1rQEsi5xPpnRdWxiJ1ubyKxBhsOEnb
 ssh-rsa
 
B3NzaC1yc2EDAQABAAABAQCumRjxbkKGvkfWk/nMFUvXDpCQtDtgBkYrGOPbP2y+5AXdrkBcEavKF6opqldBQoyairBQVLFcn9hYZO/A/+wKO7qgKKHOa2MHgW1FbWcrGd1+w7Cqxp7Gs/Ir8W921uBAM/9mQkwcZIsgnQx3w/x6/eIa3A8Wma1e41IUjRzt+e8Aq5xoSShqlvr/yXqkUJEj+MzIklOqtp4IYZywig/9uxGL0D7UOfCNZMAPNfuMw8+S2B4u+vLCITMm1yHhn/5pPMiODwDJ64LdNQysssZHQkjHwJNTH6cluN1tMiHe0niehWbGThoQFnzeMFuHCA4xVF8L8k0TcVPv+KzxfepZ
 }}}

 and IP 46.4.22.162. it's in the right datacenter (fsn1-dc13) so we're good
 on that.

 now onto the install procedure.

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 the grafana dashboard is, as expected, kind of undecipherable. :) so much
 JSON! so we can review this once it's pulled in the GUI... no harm done
 their either way, so that's okay.

 you might have missed it, but `modules/profile/files/grafana/dashboards`
 is its own repository. it's one of those dark corners of the Puppet
 repository, which is currently a huge monorepo, but that does have some
 subrepos somehow. i'm looking into how to deal with that problem in
 #30770, in general. in particular, my remote for this repo right now is
 `g...@gitlab.com:anarcat/grafana-dashboards.git` because i didn't want to
 go through the trouble of creating a project in gitolite and all that
 stuff. i could either give you access to that, or we could move it
 somewhere else, or i could just push the changes myself.

 in any case, it would be great if you could document the dashboard's in
 the README file next to it so we know where it comes from and so on.

 as for the puppet work, the blackbox exporter class looks sane. i don't
 see it included anywhere in the patch though, so i'm not sure how it
 should work.

 lower down, the `scrape_configs` array looks a bit strange to me.
 normally, the targets there look like `example.com:9091`, ie. with a port
 number at least. unless https://bridges.torproject.org/metrics actually
 gives out prometheus-compatible metrics (aka "OpenMetrics"). that doesn't
 seem to be the case right now (it's a 404).

 >  What is missing is the possibility for the service admins to add more
 targets without having to send patches to our puppet.

 That's going to be the tough part. Because the blackbox exporter is
 managed through puppet, in this configuration, we forcibly control the
 config file and local changes would be lost. So it's really one of three
 things:

  1. they send us the target and so we need to intervene when that needs to
 be changed
  2. we patch the module to allow us to *not* manage the blackbox config
 (yet another patch to the module, we can take it)
  3. we just *not* manage the blackbox exporter through puppet at all, and
 add it manually to the `scrape_configs` target.

 I would do option 2, eventually, and start with option 1. makes sense?

--
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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

2020-01-22 Thread Tor Bug Tracker & Wiki
#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-health  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by dgoulet):

 About (1), the DoS subsystem added a way to identify if the address is
 "probably" a relay or not in a very fast way with a bloom filter. Relay
 address are added when a `node_t` is added to the routerlist which for a
 dirauth contains all relays that have uploaded their descriptors.

 Code is in `./src/core/or/address_set.h` which is very convenient and
 already in use.

 We could implement (1) easily using 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

Re: [tor-bugs] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

2020-01-22 Thread Tor Bug Tracker & Wiki
#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
---+--
 Reporter:  arma   |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202001  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * Attachment "0003-Add-working-exit-FP-for-now.patch" 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] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

2020-01-22 Thread Tor Bug Tracker & Wiki
#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
---+--
 Reporter:  arma   |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202001  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * Attachment "0001-Initialize-circuit.patch" 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] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

2020-01-22 Thread Tor Bug Tracker & Wiki
#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
---+--
 Reporter:  arma   |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202001  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * Attachment "0002-Create-results-directories-if-they-do-not-exist.patch"
 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] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

2020-01-22 Thread Tor Bug Tracker & Wiki
#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
---+--
 Reporter:  arma   |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202001  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 I fixed a bunch of issues (patches attached) and have this running now.
 Need to think about good analysis of the results in a next step (while
 starting he contact/badexit process in parallel).

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by hiro:

Old description:

> I have started working on adding the possibility for our external
> prometheus to target endpoints via the blackbox exporter.
>
> Patch: https://share.riseup.net/#f45phbNbMrNSIcaKAvrbeQ
>
> What is missing is the possibility for the service admins to add more
> targets without having to send patches to our puppet.

New description:

 I have started working on adding the possibility for our external
 prometheus to target endpoints via the blackbox exporter.

 Patch: https://share.riseup.net/#wd8W-oiIFU3_FRkKBp_TEg

 What is missing is the possibility for the service admins to add more
 targets without having to send patches to our puppet.

--

--
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] #33027 [Internal Services/Tor Sysadmin Team]: Add blackbox exporter to prometheus ext

2020-01-22 Thread Tor Bug Tracker & Wiki
#33027: Add blackbox exporter to prometheus ext
-+
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #30152
   Points:   |   Reviewer:
  Sponsor:   |
-+
 I have started working on adding the possibility for our external
 prometheus to target endpoints via the blackbox exporter.

 Patch: https://share.riseup.net/#f45phbNbMrNSIcaKAvrbeQ

 What is missing is the possibility for the service admins to add more
 targets without having to send patches to our puppet.

--
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] #32995 [Community/Tor Support]: Download.

2020-01-22 Thread Tor Bug Tracker & Wiki
#32995: Download.
---+--
 Reporter:  choicemed  |  Owner:  ggus
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by rl1987):

 * owner:  (none) => ggus
 * component:  - Select a component => Community/Tor Support


--
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] #32335 [Core Tor/Tor]: Set up a .github repository on GitHub

2020-01-22 Thread Tor Bug Tracker & Wiki
#32335: Set up a .github repository on GitHub
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by rl1987):

 https://github.com/torproject/.github/pull/1

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

  1   2   >