Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 The code looks good to me, and everything passes.

 I have added some questions to #24113 and #23863 about possible changes to
 this code when we do those tickets.

 I have one question that we should resolve before backporting to 0.3.1 or
 releasing 0.3.2:

 In should_set_md_dirserver_restriction(), what if we have more than 10
 filtered guards, but less than 10 of them are actually contactable or
 running?

 For example, this can happen with the default Tor Browser bridges if a
 client can only contact bridges over IPv6, but hasn't set any reachability
 options. (There are many Tor Browser bridges, but only one of them has
 IPv6.)

 (I can't remember if filtered guards are guaranteed to be running or not.)

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

Re: [tor-bugs] #24113 [Core Tor/Tor]: We stop trying to download an md after 8 failed tries

[Tor Bug Tracker & Wiki]

#24113: We stop trying to download an md after 8 failed tries
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 After reviewing #23817, I have a question:
 * should we make the number of guards in
 should_set_md_dirserver_restriction() less than the number of microdesc
 fetches?

--
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] #23863 [Core Tor/Tor]: When our directory guards don't have each others' microdescs, we should try an authority or fallback (was: When our directory guards don't have each others' micro

[Tor Bug Tracker & Wiki]

#23863: When our directory guards don't have each others' microdescs, we should 
try
an authority or fallback
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Some more detailed design questions, after reviewing #23817:
 * what should we do when we are using bridges, or all the authorities and
 fallbacks are excluded by an EntryNodes setting?
   * should we fetch mds from a fallback or an authority over a 3-hop path?
   * is this what bridge clients do already, or do they give up when they
 can't get something from their bridge(s)?
 * if we are willing to fetch missing microdescs over a 3-hop path, can we
 make should_set_md_dirserver_restriction() always return 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

Re: [tor-bugs] #24326 [Internal Services/Tor Sysadmin Team]: tor browser error failed to take over tor network

[Tor Bug Tracker & Wiki]

#24326: tor browser error failed to take over tor network
-+-
 Reporter:  liam672  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:  Tor:
 |  very long term
Component:  Internal Services/Tor Sysadmin Team  |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  Major error's|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by liam672):

 * Attachment "unintelligent error's tor not working..png" added.

 unintelligent error's with technology.

--
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] #23968 [Applications/Tor Browser]: NoScript icon jumps to the right after update

[Tor Bug Tracker & Wiki]

#23968: NoScript icon jumps to the right after update
--+--
 Reporter:  gk|  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:
--+--

Comment (by cypherpunks):

 I can confirm NoScript auto update to version 5.1.7 caused the icon to
 jump to the right in Tor Browser 7.0.10

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

Re: [tor-bugs] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
+--
 Reporter:  tom |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  IPv6, tor-dirauth, easy, intro  |  Actual Points:
Parent ID:  #20916  | Points:  1
 Reviewer:  |Sponsor:  SponsorV-can
+--
Changes (by teor):

 * keywords:  IPv6, tor-dirauth => IPv6, tor-dirauth, easy, intro


Comment:

 dannenberg does not have an IPv6 ORPort in its descriptor, so this is the
 expected behaviour:

 http://193.23.244.244/tor/server/authority

 But we still need to fix the underlying bug:
 * if an authority has AuthDirHasIPv6Connectivity set, and
 * it has an IPv6 ORPort,
 * it should assume it's own IPv6 ORPort is reachable and vote for it

 This is what all authorities do with their own Running flag (which
 represents IPv4 and IPv6 ORPort reachability).

--
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] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by pospeselr):

 nightly-windows-i686 build fails (log attached).  I suspect this is the
 relevant bit:

 {{{
 /var/tmp/dist/mingw-w64/helpers/i686-w64-mingw32-g++ -std=gnu++11
 -mwindows -o UnifiedBindings5.o -c -I/var/tmp/build/firefox-4c66c8e30e3c
 /obj-mingw/dist/stl_wrappers  -DNDEBUG=1 -DTRIMMED=1 -DWIN32_LEAN_AND_MEAN
 -D_WIN32 -DWIN32 -D_CRT_RAND_S -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
 -DOS_WIN=1 -D_UNICODE -DCHROMIUM_BUILD -DU_STATIC_IMPLEMENTATION -DUNICODE
 -D_WINDOWS -D_SECURE_ATL -DHAVE_SIDEBAR -DSTATIC_EXPORTABLE_JS_API
 -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/var/tmp/build
 /firefox-4c66c8e30e3c/dom/bindings -I/var/tmp/build/firefox-4c66c8e30e3c
 /obj-mingw/dom/bindings -I/var/tmp/build/firefox-4c66c8e30e3c/obj-
 mingw/dist/include/mozilla/dom -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/base -I/var/tmp/build/firefox-4c66c8e30e3c/dom/battery
 -I/var/tmp/build/firefox-4c66c8e30e3c/dom/canvas -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/geolocation -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/html -I/var/tmp/build/firefox-4c66c8e30e3c/dom/indexedDB
 -I/var/tmp/build/firefox-4c66c8e30e3c/dom/media/webaudio -I/var/tmp/build
 /firefox-4c66c8e30e3c/dom/media/webspeech/recognition -I/var/tmp/build
 /firefox-4c66c8e30e3c/dom/svg -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/workers -I/var/tmp/build/firefox-4c66c8e30e3c/dom/xbl
 -I/var/tmp/build/firefox-4c66c8e30e3c/dom/xml -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/xslt/base -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/xslt/xpath -I/var/tmp/build/firefox-4c66c8e30e3c/dom/xul
 -I/var/tmp/build/firefox-4c66c8e30e3c/js/xpconnect/src -I/var/tmp/build
 /firefox-4c66c8e30e3c/js/xpconnect/wrappers -I/var/tmp/build/firefox-
 4c66c8e30e3c/layout/generic -I/var/tmp/build/firefox-
 4c66c8e30e3c/layout/style -I/var/tmp/build/firefox-
 4c66c8e30e3c/layout/xul/tree -I/var/tmp/build/firefox-
 4c66c8e30e3c/media/mtransport -I/var/tmp/build/firefox-
 4c66c8e30e3c/media/webrtc -I/var/tmp/build/firefox-
 4c66c8e30e3c/media/webrtc/signaling/src/common/time_profiling
 -I/var/tmp/build/firefox-
 4c66c8e30e3c/media/webrtc/signaling/src/peerconnection -I/var/tmp/build
 /firefox-4c66c8e30e3c/obj-mingw/ipc/ipdl/_ipdlheaders -I/var/tmp/build
 /firefox-4c66c8e30e3c/ipc/chromium/src -I/var/tmp/build/firefox-
 4c66c8e30e3c/ipc/glue -I/var/tmp/build/firefox-4c66c8e30e3c/obj-
 mingw/dist/include  -I/var/tmp/build/firefox-4c66c8e30e3c/obj-
 mingw/dist/include/nspr -I/var/tmp/build/firefox-4c66c8e30e3c/obj-
 mingw/dist/include/nss -DMOZILLA_CLIENT -include /var/tmp/build
 /firefox-4c66c8e30e3c/obj-mingw/mozilla-config.h -MD -MP -MF
 .deps/UnifiedBindings5.o.pp  -Wall -Wc++11-compat -Wempty-body -Wignored-
 qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-
 limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof
 -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-
 declarations -Wno-error=array-bounds -Wno-format -fno-lifetime-dse -fno-
 exceptions -fno-strict-aliasing -mms-bitfields -mstackrealign -fno-keep-
 inline-dllexport -fno-rtti -fno-exceptions -fno-math-errno -pipe  -g -O
 -fno-omit-frame-pointer   -Wno-error=shadow  /var/tmp/build/firefox-
 4c66c8e30e3c/obj-mingw/dom/bindings/UnifiedBindings5.cpp
 virtual memory exhausted: Operation not permitted
 make[5]: *** [UnifiedBindings20.o] Error 1
 }}}

 Looks like it's using 32-bit mingw:

 {{{
 debug-firefox$ file i686-w64-mingw32-g++
 i686-w64-mingw32-g++: ELF 32-bit LSB executable, Intel 80386, version 1
 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
 BuildID[sha1]=0x68147607a450ac3ec94bc7c069868e2bd952c314, not stripped
 }}}

 despite being a 64-bit kernel:

 {{{
 Linux runc 4.13.0-16-generic #19-Ubuntu SMP Wed Oct 11 18:35:14 UTC 2017
 x86_64 x86_64 x86_64 GNU/Linux
 }}}

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

Re: [tor-bugs] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

[Tor Bug Tracker & Wiki]

#23114: Circuit Build Timeout should apply at circuit completion
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller,  |  Actual Points:
  review-group-25|
Parent ID:  #23100   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Ok, mikeperry/bug23114 has been rebased on top of an extra fixup commit on
 top of  mikeperry/bug23100-squashed that refactors the function that both
 of these tickets are changing. This fixup commit does not change any
 functionality, it only moves code.

 I hope this makes it easier to review this change. Again, sorry for filing
 two tickets for the same block of code. I'll never do that again.

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

Re: [tor-bugs] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by pospeselr):

 * Attachment "firefox-windows-i686.log.gz" added.

 gzip'd build log

--
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] #23100 [Core Tor/Tor]: Circuit Build Timeout needs to count hidden service circuits

[Tor Bug Tracker & Wiki]

#23100: Circuit Build Timeout needs to count hidden service circuits
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery-  |  Actual Points:
  prop247-controller, needs-proposal, mike-can,  |
  prop247, tor-guard, review-group-25|
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by mikeperry):

 There is now an extra fixup commit on top of both
 mikeperry/bug23100-squashed and mikeperry/bug23100-presquashed-fixups that
 refactors the function that both of these tickets are changing. This fixup
 commit does not change any functionality, it only moves code. #23114 will
 be rebased on top of this fixup.

--
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] #23840 [Community/Outreach]: Cloudflare and Google Captcha failed 100%

[Tor Bug Tracker & Wiki]

#23840: Cloudflare and Google Captcha failed 100%
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Very High   |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Can someone test captcha API through all exit nodes to determine how many
 % are affected?
 Seems to me 99% of my browsing failed to pass that stupid google captcha.

 I hate Google. Deadly serious!!

--
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] #23840 [Community/Outreach]: Cloudflare and Google Captcha failed 100%

[Tor Bug Tracker & Wiki]

#23840: Cloudflare and Google Captcha failed 100%
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Very High   |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 https://discordapp.com/invite/X (X=ID)

 Can't complete the process because of this!

 "Why, hello there. beep boop. boop beep?"
 [ ] I'm not a robot

 Clicking on the checkbox instantly greet me with

 Try again later
 Your computer BLAH BLAH BLAH

 Seriously though, why Tor devs don't write a blog now? You did this when
 you hit by a cloudflare.

--
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] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by pospeselr):

 Testing now!

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

Re: [tor-bugs] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 It seems they added this error in this commit:
 
https://github.com/opencontainers/runc/commit/1cd050244e004bc9940787f888b4570328703100
 And later removed it in this commit:
 
https://github.com/opencontainers/runc/commit/e1146182a8cebb5a6133a9e298a5e4acf99652e9

 Apparently the platform.arch value was "never used, just validated", so
 maybe we can always set it to `amd64` to avoid the error with that runc
 version.

 I did that in branch `bug_24341`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_24341=946d493f800fa39fadba61fa0440a35074d0bbd5

 Could you check if that fix the problem?

--
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] #23544 [Metrics/Onionoo]: Add recommended_version parameter

[Tor Bug Tracker & Wiki]

#23544: Add recommended_version parameter
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Suggested specification for the relays-only parameter:

   "Return only relays running a Tor software version that is recommended
 (parameter value '''true''') or not recommended by the directory
 authorities (parameter value '''false'''). Relays are not contained in
 either result, if the version they are running is not known. Bridges are
 not contained in the result, regardless of which Tor version they are
 running. Parameter values are case-insensitive."

--
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] #21534 [Core Tor/Tor]: "Client asked me to extend back to the previous hop" in small networks

[Tor Bug Tracker & Wiki]

#21534: "Client asked me to extend back to the previous hop" in small networks
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression?, guard-selection,|  Actual Points:
  dirauth|
Parent ID:  #21573   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Authorities don't consider any nodes a guard, because they (effectively)
 set UseEntryGuards 0.
 That's deliberate, so they can bootstrap in a network with no Guards.

 They use a first hop on multi-hop circuits, but as you say, it's not
 required to have the Guard flag.

--
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] #23544 [Metrics/Onionoo]: Add recommended_version parameter

[Tor Bug Tracker & Wiki]

#23544: Add recommended_version parameter
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 It was indeed not terribly hard to implement.
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-23544
 My branch task-23544] contains an implementation that needs more review
 (than self review) and more testing.

 But before we merge this, let's decide what to do with #23962. If we
 decide to include bridges in the "version" parameter, we should also
 include them in the "recommended_version" parameter. If we decide against
 it, we can move forward with this ticket by reviewing and merging my
 branch. But let's not do that if we later decide to change the "version"
 parameter, because then we'll have to do the same with the
 "recommended_version" parameter.

 Not setting to needs_review yet.

--
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] #24287 [Metrics/Consensus Health]: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health summary

[Tor Bug Tracker & Wiki]

#24287: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health
summary
--+
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Thanks. I split off UnreachableIPv6 into #24344. I understand if it never
 gets done.
 (And that's ok: the absence of ReachableIPv6 is almost equivalent.)

--
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] #24344 [Metrics/Consensus Health]: Add an "UnreachableIPv6" flag to relays in consensus health

[Tor Bug Tracker & Wiki]

#24344: Add an "UnreachableIPv6" flag to relays in consensus health
--+--
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:  IPv6
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Split off #24287.

 If you ever have access to relay descriptors in consensus-health, a
 feature like OnionOO's #21637 (which will show unreachable addresses on
 RelaySearch/Atlas) would be great:

 If a relay declares an IPv6 address in its descriptor (in an "a" line),
 but an authority doesn't vote for it, that relay should get the
 UnreachableIPv6 pseudo-flag from that authority.

 If an authority's vote contains any "a" lines with IPv6 addresses, the
 authority should be marked as knowing the "ReachableIPv6" and
 "UnreachableIPv6" pseudo-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] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by pospeselr):

 Testing now!

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

Re: [tor-bugs] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 Does `alpha-linux-i686` have this problem too?

--
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] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
---+
 Reporter:  tom|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  IPv6, tor-dirauth  |  Actual Points:
Parent ID:  #20916 | Points:  1
 Reviewer: |Sponsor:  SponsorV-can
---+
Changes (by teor):

 * keywords:   => IPv6, tor-dirauth
 * points:   => 1
 * sponsor:   => SponsorV-can
 * parent:   => #20916
 * milestone:   => Tor: 0.3.3.x-final


Comment:

 Authorities should assume their configured IPv6 address is reachable, just
 like they do for IPv4.

 > Also strange: dannenberg votes on ReachableIPv6 but is not itself
 granted ReachableIPv6

 That's not surprising: voting on ReachableIPv6 requires outbound IPv6
 connectivity (like IPv6Exit).
 But receiving ReachableIPv6 requires inbound connectivity to an IPv6
 ORPort. Does it declare one in its descriptor?

 If it does, I'll email the dirauth list to let them know there's a
 misconfiguration, because it could end up with dannenberg not being marked
 Running,

--
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] #21697 [Core Tor/Torflow]: torflow bwfiles maybe should be updated

[Tor Bug Tracker & Wiki]

#21697: torflow bwfiles maybe should be updated
--+--
 Reporter:  tom   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:8 tom]:
 > Prelim results: https://i.imgur.com/BvOifZG.png
 >
 > Seems to not make a big difference, but I'll let it running over the
 weekend

 Are you testing my bug21697 branch?
 I don't expect it to make a difference.
 Even when the bug is triggered, it should have no effect or a minimal
 effect on the results.

 Or are you modifying the default bwfiles content?
 To test that, you'll need a clean checkout with no previous data, or the
 first aggregate run will overwrite bwfiles.

 Also, I can't read the labels on your graph.

--
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] #24343 [Core Tor/Tor]: Remove dead code and doc regarding the old SocksSocket option

[Tor Bug Tracker & Wiki]

#24343: Remove dead code and doc regarding the old SocksSocket option
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-doc, deadcode
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In `entry_connection_t`, there is still `is_socks_socket` option that is
 simply not used.

 Other place is this log which should be renamed to mention "Unix socket".

 {{{
 log_info(LD_NET, "Closing SOCKS SocksSocket connection");
 }}}

 Finally, the man page is still listing the option within another option
 (although `SocksSocketsGroupWritable` is still a thing that we should
 probably rename).

 {{{
SocksSocketsGroupWritable 0|1
  If this option is set to 0, don’t allow the filesystem group to read
 and write unix sockets (e.g. SocksSocket). If the option
  is set to 1, make the SocksSocket socket readable and writable by the
 default GID. (Default: 0)
 }}}

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

Re: [tor-bugs] #21534 [Core Tor/Tor]: "Client asked me to extend back to the previous hop" in small networks

[Tor Bug Tracker & Wiki]

#21534: "Client asked me to extend back to the previous hop" in small networks
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression?, guard-selection,|  Actual Points:
  dirauth|
Parent ID:  #21573   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => accepted
 * owner:  (none) => dgoulet


Comment:

 Pending more 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] #24342 [Core Tor]: Various spec fixes to dir-spec, rend-spec-v3 (was: Various spec fixes)

[Tor Bug Tracker & Wiki]

#24342: Various spec fixes to dir-spec, rend-spec-v3
--+--
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by filippo):

 * cc: filippo (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] #24342 [Core Tor]: Various spec fixes

[Tor Bug Tracker & Wiki]

#24342: Various spec fixes
--+--
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by filippo):

 * status:  new => needs_review


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

[tor-bugs] #24342 [Core Tor]: Various spec fixes

[Tor Bug Tracker & Wiki]

#24342: Various spec fixes
--+--
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 There are a few commits fixing various things in some of the specs,
 ranging from implementation mismatches to wording here:

 
https://github.com/FiloSottile/torspec/compare/53b7dee30b1044ae401338a9ce4b6c76e1c431e1...ab22bd1dce3b62b6120300fdead958c6924fe553

 The commit messages offer more rationale.

--
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] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

[Tor Bug Tracker & Wiki]

#23114: Circuit Build Timeout should apply at circuit completion
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller,  |  Actual Points:
  review-group-25|
Parent ID:  #23100   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_review => needs_revision


Comment:

 Hrmm.. I'm guessing that this branch is going to be annoying to review
 with the refactoring and changes in the same commit as well. I guess I
 will do the git juggling to break them apart...

 Sorry for all the git mess here. This ticket and #23100 really should have
 been just one ticket. Changing the same block of code in two tickets was
 really unwieldy. It means every fixup is automatically a conflict. Not to
 mention the unit test problem...

--
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] #24289 [Core Tor/Nyx]: When I go to https://nyx.torproject.org/changelog and click on "git repository" nothing happens.

[Tor Bug Tracker & Wiki]

#24289: When I go to https://nyx.torproject.org/changelog and click on "git
repository" nothing happens.
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks Dbryrtfbcbhgf, great catch! Sorry about the delay, been down sick.
 Fix pushed...

 https://gitweb.torproject.org/nyx.git/commit/?id=2ca19e6

--
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] #24310 [Applications/Tor Browser]: Consider encrypted bookmarks addon for storing onions on the browser

[Tor Bug Tracker & Wiki]

#24310: Consider encrypted bookmarks addon for storing onions on the browser
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tbb, network-need  |  Actual Points:
Parent ID:  | Points:  6
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Side-note, [https://lists.torproject.org/pipermail/tor-
 dev/2017-November/012614.html a person from tor-dev] said that they worked
 on a project like this. Perhaps code or ideas or icons might be reusable.

--
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] #24310 [Applications/Tor Browser]: Consider encrypted bookmarks addon for storing onions on the browser

[Tor Bug Tracker & Wiki]

#24310: Consider encrypted bookmarks addon for storing onions on the browser
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tbb, network-need  |  Actual Points:
Parent ID:  | Points:  6
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Replying to [comment:3 tom]:
 > Does Firefox's Master Password feature encrypt bookmarks?
 >

 Did some digging online and this doesn't seem to be the case. Seems to
 protect usernames and passwords only.

 > Also, could you talk more about client authorization credentials for
 .onions? How are those provided today (For some reason I thought you had
 to edit torrc) via Tor Browser?

 Yep, you need to edit the torrc, there is no way to do it through Tor
 Browser yet. Tickets #14389 and #19757 are related to this.

 HSv2 client auth creds look like this:
 {{{
 HidServAuth tkwk5o5n4eud3vwd.onion rJcrR/ZbCMDdJqTImOBvxB basic1
 }}}
 HSv3 client auth hasn't been implemented yet but it
 [https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-
 ng.txt#n2283 might look like this].

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

Re: [tor-bugs] #24324 [Metrics/Atlas]: When I view a relay on https://atlas.torproject.org I get stuck at a loading screen every time in Safari

[Tor Bug Tracker & Wiki]

#24324: When I view a relay on https://atlas.torproject.org I get stuck at a
loading screen every time in Safari
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  irl
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Major  | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by Dbryrtfbcbhgf):

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


Comment:

 Right now it is working.

--
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] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

[Tor Bug Tracker & Wiki]

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_information => merge_ready


Comment:

 So the circuit is *not* closed but it is re-used at the next SOCKS
 connection. I was mistaken, the magic of `circuit_is_acceptable()` returns
 the opened INTRODUCING circuit. So at least it is re-used.

 And I confirm with `CrcuitsAvailableTimeout 10` and `SocksTimeout 5`, the
 circuit gets closed short after the socks timeout.

 Going in `merge_ready` since it confirms what Mike was asking about.

--
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] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 OS: Ubuntu 17.10 amd64
 runc version: runc_1.0.0~rc2+docker1.13.1-0ubuntu1_amd64.deb
 failing targets:
   nightly-windows-i686
   nightly-windows-x86_64
   alpha-windows-i686
   alpha-windows-x86_64
   release-windows-i686
   release-windows-x86_64
   alpha_nightly-windows-i686
   alpha_nightly-windows-x86_64

 linux and macos targets do not have this problem

 output:
 {{{
 make alpha_nightly-windows-x86_64
 git submodule update --init
 ./rbm/rbm build release --target alpha_nightly --target torbrowser-
 windows-x86_64
 Building project tor-browser - tor-browser-7.5a8-windows-x86_64-30832d
 Building project container-image - container-
 image_precise-i386-7adf0860f1b6.tar.gz
 Building project debootstrap-image - container-image_precise-i386.tar.gz
 Using file /media/ssd/Code/Tor/tor-browser-build/out/debootstrap-image
 /container-image_ubuntu-base-17.04-base-amd64.tar.gz
 Error: Error starting remote:

 target arch 386 mismatch with current arch amd64

 Makefile:72: recipe for target 'alpha_nightly-windows-x86_64' failed
 make: *** [alpha_nightly-windows-x86_64] Error 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

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

[Tor Bug Tracker & Wiki]

#24340: (Sandbox) Caught a bad syscall attempt (syscall prctl)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sandbox, libasan
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This is only for libasan support:

 {{{
 20777 prctl(PR_GET_DUMPABLE)= 157
 20777 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
 si_call_addr=0x7f552ac9f047, si_syscall=__NR_prctl,
 si_arch=AUDIT_ARCH_X86_64} ---
 }}}

 We would need to support `PR_GET_DUMPABLE`.

--
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] #24339 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall mprotect)

[Tor Bug Tracker & Wiki]

#24339: (Sandbox) Caught a bad syscall attempt (syscall mprotect)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by dgoulet:

Old description:

> Trace is:
> {{{
> /usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7f6e71f908c0]
> /lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x13150)[0x7f6e70a72150]
> /lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
> /lib/x86_64-linux-
> gnu/libpthread.so.0(pthread_create+0x89b)[0x7f6e70a6737b]
> /usr/lib/x86_64-linux-
> gnu/libasan.so.4(pthread_create+0xf9)[0x7f6e71f72db9]
> git/tor/src/or/tor(spawn_func+0x117)[0x55673b5a52c7]
> git/tor/src/or/tor(threadpool_new+0x539)[0x55673b5a3499]
> git/tor/src/or/tor(cpu_init+0xb7)[0x55673b485917]
> git/tor/src/or/tor(do_main_loop+0x7fa)[0x55673b1a047a]
> git/tor/src/or/tor(tor_main+0x143d)[0x55673b1a579d]
> git/tor/src/or/tor(main+0x1c)[0x55673b1922bc]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f6e6f97f1c1]
> git/tor/src/or/tor(_start+0x2a)[0x55673b1940ba]
> }}}
>
> strace shows me:
>
> {{{
> 20085 mprotect(0x7f6e6b9bf000, 8388608, PROT_READ|PROT_WRITE) = 10
> 20085 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
> si_call_addr=0x7f6e6fa6ccf7, si_syscall=__NR_mprotect,
> si_arch=AUDIT_ARCH_X86_64} ---
> }}}
>
> Basically, our sandbox doesn't allow `PROT_WRITE`. Libc is 2.26.

New description:

 Trace is:
 {{{
 /usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7f6e71f908c0]
 /lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x13150)[0x7f6e70a72150]
 /lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
 /lib/x86_64-linux-
 gnu/libpthread.so.0(pthread_create+0x89b)[0x7f6e70a6737b]
 /usr/lib/x86_64-linux-
 gnu/libasan.so.4(pthread_create+0xf9)[0x7f6e71f72db9]
 git/tor/src/or/tor(spawn_func+0x117)[0x55673b5a52c7]
 git/tor/src/or/tor(threadpool_new+0x539)[0x55673b5a3499]
 git/tor/src/or/tor(cpu_init+0xb7)[0x55673b485917]
 git/tor/src/or/tor(do_main_loop+0x7fa)[0x55673b1a047a]
 git/tor/src/or/tor(tor_main+0x143d)[0x55673b1a579d]
 git/tor/src/or/tor(main+0x1c)[0x55673b1922bc]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f6e6f97f1c1]
 git/tor/src/or/tor(_start+0x2a)[0x55673b1940ba]
 }}}

 strace shows me:

 {{{
 20085 mprotect(0x7f6e6b9bf000, 8388608, PROT_READ|PROT_WRITE) = 10
 20085 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
 si_call_addr=0x7f6e6fa6ccf7, si_syscall=__NR_mprotect,
 si_arch=AUDIT_ARCH_X86_64} ---
 }}}

 Basically, our sandbox doesn't allow `PROT_READ|PROT_WRITE`. Libc is 2.26.

--

--
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] #24339 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall mprotect)

[Tor Bug Tracker & Wiki]

#24339: (Sandbox) Caught a bad syscall attempt (syscall mprotect)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sandbox
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Trace is:
 {{{
 /usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7f6e71f908c0]
 /lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x13150)[0x7f6e70a72150]
 /lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
 /lib/x86_64-linux-
 gnu/libpthread.so.0(pthread_create+0x89b)[0x7f6e70a6737b]
 /usr/lib/x86_64-linux-
 gnu/libasan.so.4(pthread_create+0xf9)[0x7f6e71f72db9]
 git/tor/src/or/tor(spawn_func+0x117)[0x55673b5a52c7]
 git/tor/src/or/tor(threadpool_new+0x539)[0x55673b5a3499]
 git/tor/src/or/tor(cpu_init+0xb7)[0x55673b485917]
 git/tor/src/or/tor(do_main_loop+0x7fa)[0x55673b1a047a]
 git/tor/src/or/tor(tor_main+0x143d)[0x55673b1a579d]
 git/tor/src/or/tor(main+0x1c)[0x55673b1922bc]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f6e6f97f1c1]
 git/tor/src/or/tor(_start+0x2a)[0x55673b1940ba]
 }}}

 strace shows me:

 {{{
 20085 mprotect(0x7f6e6b9bf000, 8388608, PROT_READ|PROT_WRITE) = 10
 20085 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
 si_call_addr=0x7f6e6fa6ccf7, si_syscall=__NR_mprotect,
 si_arch=AUDIT_ARCH_X86_64} ---
 }}}

 Basically, our sandbox doesn't allow `PROT_WRITE`. Libc is 2.26.

--
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] #24315 [Core Tor/Tor]: sandbox incompatible with glibc 2.26 (openat() not handled for all our files)

[Tor Bug Tracker & Wiki]

#24315: sandbox incompatible with glibc 2.26 (openat() not handled for all our
files)
--+
 Reporter:  dgoulet   |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Branch lgtm; but I can't test this because IMm now getting:

 `(Sandbox) Caught a bad syscall attempt (syscall mprotect)`. I'll open a
 ticket for that.

--
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] #24313 [Core Tor/Tor]: Tor 0.3.2.3-alpha crash: died: Caught signal 11 [crash from rend_consider_services_intro_points]

[Tor Bug Tracker & Wiki]

#24313: Tor 0.3.2.3-alpha crash: died: Caught signal 11 [crash from
rend_consider_services_intro_points]
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:4 asn]:
 > Hey, in case you can help with debugging, were you on single onion
 services? And also, do you have info logs by any chance?
 No, I was running Ricochet (obviously not a single onion service) when it
 told me that Tor crashed. I don't think there are info logs.

--
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] #24287 [Metrics/Consensus Health]: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health summary

[Tor Bug Tracker & Wiki]

#24287: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health
summary
--+
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tom):

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


Comment:

 Feel free to open a new ticket to track the UnReachable flag, but I don't
 think I'll wind up addressing it soon.

--
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] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
--+
 Reporter:  tom   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Check out https://consensus-health.torproject.org/consensus-health.html
 and Control+f for:

 BD6A829255CB08E66FBE7D3748363586E46B3810
 847B1F850344D7876491A54892F904934E4EB85D
 24E2F139121D4394C54B5BCC368B3B411857C413
 F2044413DAC2E02E3D6BCF4735A19BCA1DE97281


 Also strange: dannenberg votes on ReachableIPv6 but is not itself granted
 ReachableIPv6

--
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] #24287 [Metrics/Consensus Health]: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health summary

[Tor Bug Tracker & Wiki]

#24287: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health
summary
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tom):

 This is live:
 
https://gitweb.torproject.org/depictor.git/commit/?id=5a8e4af0d4a1b7ea62a79d37eda63b3a5c6bcd6c
 https://consensus-health.torproject.org/

 It exposed: #24338

--
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] #19001 [Obfuscation/Snowflake]: Tor Browser with Snowflake

[Tor Bug Tracker & Wiki]

#19001: Tor Browser with Snowflake
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Very High  |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Critical   | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by cypherpunks):

 * priority:  Medium => Very High
 * severity:  Normal => Critical


--
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] #24287 [Metrics/Consensus Health]: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health summary

[Tor Bug Tracker & Wiki]

#24287: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health
summary
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tom):

 Replying to [comment:3 teor]:
 > Oh, and do you have access to relay descriptors in consensus-health?

 I don't. I've resisted trying to add them because I think it will
 significantly increase the runtime and memory requirements of the script.
 (And as it is the script sometimes fails due to OOM)

--
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] #6767 [Core Tor/Tor]: tor crashes with Assertion smartlist_get(rl->old_routers, idx) == sd failed

[Tor Bug Tracker & Wiki]

#6767: tor crashes with Assertion smartlist_get(rl->old_routers, idx) == sd 
failed
-+-
 Reporter:  darkk|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.37
 Severity:  Major| Resolution:
 Keywords:  tor-relay crash assertion|  Actual Points:
  029-backport 030-backport 031-backport needs-  |
  insight|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.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] #21534 [Core Tor/Tor]: "Client asked me to extend back to the previous hop" in small networks

[Tor Bug Tracker & Wiki]

#21534: "Client asked me to extend back to the previous hop" in small networks
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression?, guard-selection,|  Actual Points:
  dirauth|
Parent ID:  #21573   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:8 teor]:
 > Authorities do not use guards for anything.

 Well they do for couple reason I can find with the logs. First, self
 reachability testing, it goes through a 3 path length circuit and thus
 requiring a Guard (`consider_testing_reachability()`)

 Second, client hidden service preemptive circuit
 (`needs_hs_client_circuits()`). This one happens quite a bit when CBT is
 learning (#24228).

 So what I mean here is that we should definitely investigate why
 authorities (so far I can only see them hitting this issue) don't consider
 any nodes a Guard and makes them fallback to the entire routerset.
 Actually, it is a bit worst then that because of:

 {{{
 flags &= ~ (CRN_NEED_UPTIME|CRN_NEED_CAPACITY|CRN_NEED_GUARD|
 CRN_PREF_ADDR);
 choice = router_choose_random_node(
  excludedsmartlist, excludedset, flags);
 }}}

 BUT, as it turns out, this is definitely not the problem of this
 ticket

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 In my branch `macro_free`, I've started doing this.  I got through all of
 src/common/*.h, and then decided I'd take a break and ask for comment
 before going any further.

--
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] #21697 [Core Tor/Torflow]: torflow bwfiles maybe should be updated

[Tor Bug Tracker & Wiki]

#21697: torflow bwfiles maybe should be updated
--+--
 Reporter:  tom   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 Here's a better image: https://i.imgur.com/J7GJtlW.png

--
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] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Our tor_free() macros has saved us a bunch of trouble in the past by
 ensuring that once we've freed a pointer, that pointer gets set to NULL.

 Wouldn't it be cool if all of our free() calls did this?  It should make
 our code generally less error-prone.

 As we work on #23847, I bet we will find it extremely helpful.

--
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] #21366 [Metrics/Onionoo]: Support whitespace in search term (as does Onionoo)

[Tor Bug Tracker & Wiki]

#21366: Support whitespace in search term (as does Onionoo)
-+---
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  reopened
 Priority:  Medium   |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Re-opening, because we might have merged something that doesn't work yet.
 Needs closer investigation next week. Oops.

--
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] #24232 [Webpages/Website]: 404 Dead Link in "Who Uses Tor"

[Tor Bug Tracker & Wiki]

#24232: 404 Dead Link in "Who Uses Tor"
--+--
 Reporter:  t0mmy |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by t0mmy):

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


--
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] #24336 [Webpages/Website]: Color scheme on board of directors page mixed up

[Tor Bug Tracker & Wiki]

#24336: Color scheme on board of directors page mixed up
--+--
 Reporter:  t0mmy |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On our BOD page [1] the color scheme/design of the background does not
 follow for Ramy Raoof and Julius Mittenzwei. Their colors should be
 reversed.

 [1] https://www.torproject.org/about/board.html.en

--
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] #24335 [Webpages/Website]: Ramy Raoof bio edit needed

[Tor Bug Tracker & Wiki]

#24335: Ramy Raoof bio edit needed
--+--
 Reporter:  t0mmy |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On our Board of Directors page [1], Ramy Raoof's bio ends with the line
 "Most recently, Ramy received the 2017 Heroes of Human Rights and
 Communications Surveillance from Access Now earlier this month."

 Suggest removing "earlier this month" to keep the bio current.

 [1] https://www.torproject.org/about/board.html.en

--
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] #16526 [Applications/Tor Messenger]: Import Pidgin configuration

[Tor Bug Tracker & Wiki]

#16526: Import Pidgin configuration
+
 Reporter:  lunar   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by arlolra):

 Upstream this is https://bugzilla.mozilla.org/show_bug.cgi?id=1057874

--
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] #24313 [Core Tor/Tor]: Tor 0.3.2.3-alpha crash: died: Caught signal 11 [crash from rend_consider_services_intro_points]

[Tor Bug Tracker & Wiki]

#24313: Tor 0.3.2.3-alpha crash: died: Caught signal 11 [crash from
rend_consider_services_intro_points]
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Hey, in case you can help with debugging, were you on single onion
 services? And also, do you have info logs by any chance?

--
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] #24059 [Metrics/Website]: Adapt Onionoo protocol page for next milestone

[Tor Bug Tracker & Wiki]

#24059: Adapt Onionoo protocol page for next milestone
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Thanks for checking! Pushed and deployed. 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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 031 branch lgtm and passes both `test-network-all` and manual real network
 test.

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.1.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] #24334 [Metrics/Onionoo]: Make Onionoo's results more maintainable

[Tor Bug Tracker & Wiki]

#24334: Make Onionoo's results more maintainable
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * keywords:   => metrics-2018


--
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] #24334 [Metrics/Onionoo]: Make Onionoo's results more maintainable

[Tor Bug Tracker & Wiki]

#24334: Make Onionoo's results more maintainable
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Expanding fields needs to be easier.  See
 
[https://gitweb.torproject.org/onionoo.git/tree/src/main/java/org/torproject/onionoo/server/ResponseBuilder.java#n239
 ResponseBilder]:
 {{{
  /* TODO Maybe there's a more elegant way (more maintainable, more
   * efficient, etc.) to implement this? */
 }}}

 Some automation for adding new fields; method not defined yet.

--
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] #24059 [Metrics/Website]: Adapt Onionoo protocol page for next milestone

[Tor Bug Tracker & Wiki]

#24059: Adapt Onionoo protocol page for next milestone
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  task | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 All current changes and the upcoming major change mentioned.

--
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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I can't see any more bugs or pending issues here.  So I'm going to merge
 this to 0.3.2 now, in hopes that it gets some testing over the weekend
 before the next alpha release next week.  Tim, if you have time to look at
 it next week anyway, it would probably be good to get another round of
 (post-merge) review on this.

 I tried again to rebase onto 0.3.1, in case we decide to backport there.
 Most of the conflicts came from the unit tests, so I have two new branches
 now: a `bug23817_031` that contains everything but the unit tests, and
 `bug23817_tests_032` that has the tests only.

--
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] #24059 [Metrics/Website]: Adapt Onionoo protocol page for next milestone

[Tor Bug Tracker & Wiki]

#24059: Adapt Onionoo protocol page for next milestone
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-24059=283109367f93cafb6162db090c1ead0bda3bb31b
 this commit in my task-24059 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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 made a squashed version as `bug23817_032_asn_a_squashed`

--
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] #24313 [Core Tor/Tor]: Tor 0.3.2.3-alpha crash: died: Caught signal 11 [crash from rend_consider_services_intro_points] (was: Tor 0.3.2.3-alpha crash: died: Caught signal 11)

[Tor Bug Tracker & Wiki]

#24313: Tor 0.3.2.3-alpha crash: died: Caught signal 11 [crash from
rend_consider_services_intro_points]
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #24313 [Core Tor/Tor]: Tor 0.3.2.3-alpha crash: died: Caught signal 11

[Tor Bug Tracker & Wiki]

#24313: Tor 0.3.2.3-alpha crash: died: Caught signal 11
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: asn, dgoulet (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] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  pastly
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+
Changes (by nickm):

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


Comment:

 Cherry-picked to maint-0.3.2; merged forward.

--
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] #24254 [Core Tor/Tor]: There needs to be documentation on what kernel versions the KIST Scheduler will run on

[Tor Bug Tracker & Wiki]

#24254: There needs to be documentation on what kernel versions the KIST 
Scheduler
will run on
+
 Reporter:  Dbryrtfbcbhgf   |  Owner:  pastly
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-sched, tor-doc  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  dgoulet |Sponsor:
+
Changes (by nickm):

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


Comment:

 cherry-picked to maint-0.3.2 and merging forward. 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] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

[Tor Bug Tracker & Wiki]

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_information
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:12 mikeperry]:
 > Ugh, the other wrinkle to check is if the hidden service comes back
 online after the socks timeout, but while that old intro circuit is still
 laying around. Does Tor try to reuse the intro in that case? Does that
 work, or does it break?

 First, no the `SocksTimeout` does *not* make the intro point circuit to
 close.

 I haven't tested it but I'm pretty sure the client won't find that circuit
 because it is set to `INTRODUCING` purpose where the SOCKS request makes
 the client look for an `INTRODUCE_ACK_WAIT` and if can't find any launches
 a new circuit and sets it to `INTRODUCING`.

 I need to confirm that but I do think we'll lose track of this circuit
 until its idle timeout of 52 minutes hehe.

--
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] #23861 [Core Tor/Tor]: Excessive I learned some more directory information. [...] log message at startup

[Tor Bug Tracker & Wiki]

#23861: Excessive I learned some more directory information. [...] log message 
at
startup
+
 Reporter:  s7r |  Owner:  dgoulet
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-relay, logging  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 looks good; merged to 0.3.2 and forward.

--
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] #21697 [Core Tor/Torflow]: torflow bwfiles maybe should be updated

[Tor Bug Tracker & Wiki]

#21697: torflow bwfiles maybe should be updated
--+--
 Reporter:  tom   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 Prelim results: https://i.imgur.com/BvOifZG.png

 Seems to not make a big difference, but I'll let it running over the
 weekend

--
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] #23577 [Core Tor/Tor]: Add rendezvous point IPv6 address to client introduce cells

[Tor Bug Tracker & Wiki]

#23577: Add rendezvous point IPv6 address to client introduce cells
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  implemented
  ipv6, review-group-25  |  Actual Points:  2
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

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


Comment:

 Merged to master. Thanks to everyone!

--
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] #24315 [Core Tor/Tor]: sandbox incompatible with glibc 2.26 (openat() not handled for all our files) (was: sandbox: openat() not handled for all our files)

[Tor Bug Tracker & Wiki]

#24315: sandbox incompatible with glibc 2.26 (openat() not handled for all our
files)
--+
 Reporter:  dgoulet   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

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

[tor-bugs] #24333 [Core Tor/Tor]: Fix TROVE-2017-012

[Tor Bug Tracker & Wiki]

#24333: Fix TROVE-2017-012
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  trove-2017-011
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Ticket for medium severity issue TROVE-2017-012

 See https://trac.torproject.org/projects/tor/wiki/TROVE

--
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] #24167 [Core Tor/Tor]: connection_check_event: Bug: Event missing on connection

[Tor Bug Tracker & Wiki]

#24167: connection_check_event: Bug: Event missing on connection
-+-
 Reporter:  Felixix  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay mem-limit 031-backport |  Actual Points:
  030-backport 029-backport 028-backport |
  025-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 Okay. Going to try it out in 0.3.2, and mark for possible backport.
 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] #20963 [Core Tor/Tor]: [notice] The Tor Directory Consensus has changed how many circuits we must track to detect network failures from 0 to 20.

[Tor Bug Tracker & Wiki]

#20963: [notice] The Tor Directory Consensus has changed how many circuits we 
must
track to detect network failures from 0 to 20.
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport, 031-deferred-20170425  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Thanks for the review! I'm merging this to 0.3.2 and forward; I'm guessing
 Roger isn't going to get to this soon.

--
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] #24097 [Core Tor/Tor]: evdns_callback(): Bug: eventdns returned no addresses or error

[Tor Bug Tracker & Wiki]

#24097: evdns_callback(): Bug: eventdns returned no addresses or error
--+
 Reporter:  toralf|  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Thanks for the review! I'm merging this to 0.3.2 and forward.

--
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] #24146 [Applications/Tor Browser]: Linux Tor Browser 7.0.10 version: The proxy server is refusing connections (was: Linux 7.0.9 version: The proxy server is refusing connections)

[Tor Bug Tracker & Wiki]

#24146: Linux Tor Browser 7.0.10 version: The proxy server is refusing 
connections
--+--
 Reporter:  TorontoBoy|  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: 0.3.1.8
 Severity:  Normal| Resolution:
 Keywords:  linux,ubuntu  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by TorontoBoy):

 * status:  closed => reopened
 * version:   => Tor: 0.3.1.8
 * resolution:  worksforme =>


Comment:

 Tor browser upgraded to 7.0.10, proxy server is again refusing all
 connections, browser completely unusable. I completely removed Adblock
 Plus plugin, so no other addon plugins. Reboote but Tor browser still does
 not work.

 Torbutton and Torlauncher, usually the green onion icon to the left of the
 address bar, does not appear, so I cannot change tor circuits.

 Any help would be appreciated. I guess I could delete Tor browser and
 reinstall?
 Thank you all.

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

Re: [tor-bugs] #23863 [Core Tor/Tor]: When our directory guards don't have each others' microdescs, we should mark some dead

[Tor Bug Tracker & Wiki]

#23863: When our directory guards don't have each others' microdescs, we should
mark some dead
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:9 asn]:
 > Replying to [comment:8 teor]:
 > > I think we should implement an authority md fetch for clients that run
 out of microdesc attempts. And I think they can easily handle the load of
 a few mds, because they are handling a similar consensus load from clients
 and relays already.
 > >
 > > I also don't think removing fallbacks from the list will help much,
 because bootstrapping clients try authorities anyway.
 > >
 >
 > I'm continuing the discussion here altho it's worth mentioning that teor
 also added some more calculations in #24113.
 >
 > I think I can get behind doing an authority md fetch for clients that
 have failed too many microdesc attempts. To further reduce the load on
 dirauths, perhaps we should do this only if we are missing descriptors for
 some of our primary guards (i.e. only if we are missing very crucial mds),
 since clients can/should usually tolerate missing a few random mds.

 I think asking an authority is a good idea.
 Is it also worth asking a fallback first?
 This might be another way to reduce load on the authorities.
 And I think it would really help some clients if we do it, because some
 networks block authority addresses.

 If we only ask an authority or fallback when we are missing a guard
 microdesc, this leaks our guards to the authority or fallback.
 I think that is probably ok. Because these queries are mixed in with a
 bunch of other client queries.
 (Authorities see about as many client queries as they see relay queries.)

 But here's what we can do to make the leak less obvious:
 * ask for all the missing microdescs, not just the primary guard ones
   * this has a very low impact, because we are already doing a request -
 we should definitely do it.
 * ask all the time, not just when we are missing primary guards
   * this has a higher impact, but I think we can easily afford to do it if
 we want to,
   * but I agree with you - I don't think we need to do it, so let's not
 bother right now.

 Some detailed questions about the md request:

 What if we are missing more microdescs than fit in a single request?
 How do we make sure our primary guards are in that request?

 What order do we usually use for md hashes in requests?
 When we make multiple requests, do we usually split mds between them at
 random?
 Do we usually sort the hashes to destroy ordering information?

 (I can imagine myself writing a request that starts with the guard md
 hashes, and not realising I was leaking them.)

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

Re: [tor-bugs] #24198 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall kill)

[Tor Bug Tracker & Wiki]

#24198: (Sandbox) Caught a bad syscall attempt (syscall kill)
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 For some reason Chutney is not failing for me anymore even without
 `bug24198_029`. I tested `bug24198_029` and chutney seems to continue
 working fine...

--
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] #24332 [Applications/Tor Browser]: Add a script to convert code signed OSX bundles from tar to dmg

[Tor Bug Tracker & Wiki]

#24332: Add a script to convert code signed OSX bundles from tar to dmg
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:  #24331
   Points:|   Reviewer:
  Sponsor:|
--+--
 During the signing process we code-sign the OSX bundles on our signing
 machine, creating tarballs containing the OSX bundles. After this step is
 done we need to convert those tarballs to dmg files using some build
 machine. We can add a script to `tor-browser-build` doing that using the
 same tools we use to generate the unsigned dmg files.

--
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] #23863 [Core Tor/Tor]: When our directory guards don't have each others' microdescs, we should mark some dead

[Tor Bug Tracker & Wiki]

#23863: When our directory guards don't have each others' microdescs, we should
mark some dead
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID:  #21969 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by asn):

 Replying to [comment:8 teor]:
 > I think we should implement an authority md fetch for clients that run
 out of microdesc attempts. And I think they can easily handle the load of
 a few mds, because they are handling a similar consensus load from clients
 and relays already.
 >
 > I also don't think removing fallbacks from the list will help much,
 because bootstrapping clients try authorities anyway.
 >

 I'm continuing the discussion here altho it's worth mentioning that teor
 also added some more calculations in #24113.

 I think I can get behind doing an authority md fetch for clients that have
 failed too many microdesc attempts. To further reduce the load on
 dirauths, perhaps we should do this only if we are missing descriptors for
 some of our primary guards (i.e. only if we are missing very crucial mds),
 since clients can/should usually tolerate missing a few random mds.

 If we agree on the general concept here, I will come up with an
 implementation plan early next week.

--
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] #23657 [Applications/Tor Browser]: Decide directories used for signed/unsigned builds in tor-browser-builds

[Tor Bug Tracker & Wiki]

#23657: Decide directories used for signed/unsigned builds in tor-browser-builds
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #24331| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * parent:   => #24331


--
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] #24331 [Applications/Tor Browser]: Improve the Tor Browser signing process

[Tor Bug Tracker & Wiki]

#24331: Improve the Tor Browser signing process
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This is the parent ticket for adding more scripts to automate some parts
 of the signing process.

--
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] #23719 [Applications/Tor Browser]: Make sure WebExtensions are spared from JIT disabling in higher security settings (Medium-High)

[Tor Bug Tracker & Wiki]

#23719: Make sure WebExtensions are spared from JIT disabling in higher security
settings (Medium-High)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff59-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:   => ff59-esr


--
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] #24330 [Metrics/Website]: Unify metrics-web logging approach also for operation

[Tor Bug Tracker & Wiki]

#24330: Unify metrics-web logging approach also for operation
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 * slf4j-api should be used.
 * logback configuration
 * etc

--
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] #24329 [Metrics/Website]: Name R, sql, and python scripts consistently

[Tor Bug Tracker & Wiki]

#24329: Name R, sql, and python scripts consistently
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:  metrics-2018
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Name R, sql, and python scripts consistently and apply style guidelines,
 which partially might need to be defined.

--
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] #24328 [Metrics/Website]: Make db credentials and url as well as paths (webstats, legacy, onionperf etc.) configurable

[Tor Bug Tracker & Wiki]

#24328: Make db credentials and url as well as paths (webstats, legacy, 
onionperf
etc.)  configurable
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:  metrics-2018
Actual Points:   |  Parent ID:  #24041
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This concerns all languages use R, java, sql, python.
 Configuration could be filebased (see example legacy.config).

 Suggestion: one file 'metrics-web.properties' containing the configuration
 for all different modules.

 (Of course, keep an eye on the decisions made in #24041.)

--
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] #24324 [Metrics/Atlas]: When I view a relay on https://atlas.torproject.org I get stuck at a loading screen every time in Safari

[Tor Bug Tracker & Wiki]

#24324: When I view a relay on https://atlas.torproject.org I get stuck at a
loading screen every time in Safari
---+--
 Reporter:  Dbryrtfbcbhgf  |  Owner:  irl
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 Please try to clear your cache and refresh the page. Safari does not
 appear to honour the cache headers that are sent by the web server. We
 have added cache breakers to resources, but maybe a resource is missed.

--
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] #23783 [Core Tor/Tor]: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7

[Tor Bug Tracker & Wiki]

#23783: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7
-+-
 Reporter:  Bizarre™ |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  0.3.2.2-alpha-blogpost-bugreport,|  Actual Points:
  windows, mingw |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by Bizarre™):

 @cypherpunks:

 Sorry, but I'm not the one behind that IP address. I'm always behind a
 VPN, but this is the first I've seen that IP address.

--
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] #16553 [Metrics/Onionoo]: Add support for searching by (partial) host name

[Tor Bug Tracker & Wiki]

#16553: Add support for searching by (partial) host name
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Very Low |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

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


Comment:

 Java8 remark added to #23752.

 Closing, thanks!

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

Re: [tor-bugs] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
--+--
 Reporter:  iwakeh|  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics   |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics-2017  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by iwakeh):

 For Onionoo see (as one example) #16553 comment:22 following.

--
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] #21637 [Metrics/Onionoo]: Include both declared and reachable IPv6 OR addresses

[Tor Bug Tracker & Wiki]

#21637: Include both declared and reachable IPv6 OR addresses
+---
 Reporter:  teor|  Owner:  metrics-team
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  metrics-2017, ipv6  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+---
Changes (by karsten):

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


Comment:

 Added a change log entry, rebased, and pushed to master. Thanks for
 checking!

--
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] #16553 [Metrics/Onionoo]: Add support for searching by (partial) host name

[Tor Bug Tracker & Wiki]

#16553: Add support for searching by (partial) host name
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Very Low |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Rebased and merged to master. Not closing yet until we have moved the Java
 8 part to another ticket.

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

Re: [tor-bugs] #24327 [Metrics/ExoneraTor]: Sort results under technical details by timestamp and, if necessary, by fingerprint

[Tor Bug Tracker & Wiki]

#24327: Sort results under technical details by timestamp and, if necessary, by
fingerprint
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review one commit in
 [https://gitweb.torproject.org/user/karsten/exonerator.git/log/?h=task-24327
 my task-24327 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

[tor-bugs] #24327 [Metrics/ExoneraTor]: Sort results under technical details by timestamp and, if necessary, by fingerprint

[Tor Bug Tracker & Wiki]

#24327: Sort results under technical details by timestamp and, if necessary, by
fingerprint
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 A while ago, in
 
[https://gitweb.torproject.org/exonerator.git/commit/?id=92cbc074b9bee07d4b3243070788187080dccd05
 92cbc07], we took out ORDER BY statements, because we didn't need them
 anymore in order to produce correct output. However, this also made the
 technical details part less readable with entries appearing in random
 order. Let's fix this by sorting results first by timestamp and then by
 fingerprint.

--
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] #24326 [Internal Services/Tor Sysadmin Team]: tor browser error failed to take over tor network

[Tor Bug Tracker & Wiki]

#24326: tor browser error failed to take over tor network
-+-
 Reporter:  liam672  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:  Tor: very
 |  long term
Component:  Internal Services/Tor Sysadmin   |Version:  Tor:
  Team   |  unspecified
 Severity:  Normal   |   Keywords:  Major
 |  error's
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I recently installed the tor browser and it was working fine than I
 started getting programme error's with my operating system which is
 window's then the tor browser stopped working and come's up with the error
 failed to take over tor network. I've since had more problem's with the
 internet and window's how ever window's say's there are no viruses or
 malware installed on my pc but I continue to have major error's and
 problem's. I can't seem too be able to connect to the tor browser and I've
 got too reconnect to the tor network according to the error's I've had
 this problem with the last device I installed the tor network on as well
 it's been happening for over a year. I've also got multiple error's with
 the tor web site when I tried to report this problem I've got the screen
 shot's I'll upload when I can get on my pc and get the programme's to
 start working properly. Can I please be emailed at liam_sei...@hotmail.com
 in regard's to this matter because Tor isn't working properly on my pc.

--
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] #21637 [Metrics/Onionoo]: Include both declared and reachable IPv6 OR addresses

[Tor Bug Tracker & Wiki]

#21637: Include both declared and reachable IPv6 OR addresses
+---
 Reporter:  teor|  Owner:  metrics-team
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo |Version:
 Severity:  Normal  | Resolution:
 Keywords:  metrics-2017, ipv6  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+---
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Checks and tests pass, line coverage up by 2% and branch coverage by 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

Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass, |  Actual Points:
  TorBrowserTeam201711   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-disk-leak, tbb-proxy-bypass, TorBrowserTeam201711R => tbb-
 disk-leak, tbb-proxy-bypass, TorBrowserTeam201711


Comment:

 Thanks for the review! Let's talk about SMB in a different bug, though.

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