Re: [tor-bugs] #20152 [Core Tor/Tor]: Update DirAuthority man entry for client begindir, no IPv6 DirPort

[Tor Bug Tracker & Wiki]

#20152: Update DirAuthority man entry for client begindir, no IPv6 DirPort
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Agreed!

 For posterity though, the version cutoff for where clients started using
 the ORPort, i.e. for when we deployed the begindir design, is 0.2.0.22-rc:
 {{{
   o Major features:
 - Enable encrypted directory connections by default for non-relays,
   so censor tools that block Tor directory connections based on their
   plaintext patterns will no longer work. This means Tor works in
   certain censored countries by default 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] #20156 [Internal Services/Blog]: log.torproject.org is DOWN

[Tor Bug Tracker & Wiki]

#20156: log.torproject.org is DOWN
+
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Blog  |Version:
 Severity:  Blocker | Resolution:  worksforme
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arma):

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


Comment:

 Sounds like you noticed it while it was rebooting to get a new kernel.

 I'm going to close this ticket since it is no longer the case that the
 blog server is down.

 (I assume you meant blog, not log, since there is no log. I think.)

 That said, #20158 is still an open ticket alas.

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

Re: [tor-bugs] #12799 [Core Tor/Tor]: fingerprints - descriptor Space removal, case normalization

[Tor Bug Tracker & Wiki]

#12799: fingerprints - descriptor Space removal, case normalization
--+---
 Reporter:  grarpamp  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.22
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by grarpamp):

 * severity:   => Normal


Comment:

 > teor mentioned, in an unrelated ticket
 > You might have been thinking of the OnionOO query syntax.

 Was thinking the consensus and [sys]log files and control port of this
 ticket.

 > This would be ok for output, but for input, we need to keep accepting
 both forms.

 Fixing the output and docs will cause input to gravitate that way by
 example, which is cool, yielding possible de-acceptance point in future.

 Looking around the net at various usage and rationales, lower case hex
 seems highly preferred these days... no visual character ambiguity,
 requires no keyboard or spoken shift key, no case insensitive flags to
 regexes or extra 'tolower'ing step, matches output of hash tools, 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

Re: [tor-bugs] #20153 [Core Tor/Tor]: VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"

[Tor Bug Tracker & Wiki]

#20153: VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--

Comment (by grarpamp):

 > > Somewhat related, relay fingerprints also need to be
 > I couldn't find a Core Tor/Tor-specific ticket, do you have the number?
 Moving this subject to this ticket...
 https://trac.torproject.org/projects/tor/ticket/12799

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

Re: [tor-bugs] #20010 [Core Tor/Tor]: modifications of relay(s) on fallback whitelist

[Tor Bug Tracker & Wiki]

#20010: modifications of relay(s) on fallback whitelist
-+
 Reporter:  niij |  Owner:  teor
 Type:  enhancement  | Status:  closed
 Priority:  Very Low |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  fallback, whitelist  |  Actual Points:  0.2
Parent ID:  #18828   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

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


Comment:

 Ok, fixed now, I must have seen these in-progress.
 The changes will be merged with the fallbacks 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] #20153 [Core Tor/Tor]: VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"

[Tor Bug Tracker & Wiki]

#20153: VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:1 grarpamp]:
 > Also, the correct form is fc00::/7 without brackets.
 > Brackets are used with URI's to delineate ports as in
 https://[fc00::1]:443/ .
 > Addresses must also be written in lower case.
 > I see numerous places in the manpage, and thus probably also in
 > the code that need fixed to not use brackets and be lowercased.

 The code accepts any mix of lowercase and uppercase, I believe this to be
 a feature, not a bug. I'd be ok with making the man page and Tor output
 consistent, but I'm wary of breaking Control Port output parsers.

 The code only accepts IPv6 addresses with brackets, and almost all
 contexts that accept an IPv6 address also accept a port. (This is one of
 the exceptions, there may be one or two more.) The current IPv6 parsing
 code also uses the brackets to distinguish between an IPv4 address and an
 IPv6 address. I think I'd prefer consistency over standards-compliance in
 this particular instance.

 > For tor purposes, I'd suggest to override the 'should be followed'
 > of rfc5952 and instead write/print output only in the full 32 character
 > form simply to make parsing easier for downstream consumers that
 > may not utilize parsing libraries (tor tool script writers, etc).
 > Or at least make a new 'FullIPv6Representation" (FullIPv6Rep)
 > config option for it.
 >
 > https://tools.ietf.org/html/rfc5952
 > https://tools.ietf.org/html/rfc4291
 > https://tools.ietf.org/html/rfc3986

 This is a different issue, please open an enhancement request.
 Putting multiple requests in the same issue makes it likely that some get
 missed.

 > Somewhat related, relay fingerprints also need to be
 > lowercased and without embedded spaces. I think there's
 > a ticket on that too.

 I couldn't find a Core Tor/Tor-specific ticket, do you have the number?
 You might have been thinking of the OnionOO query syntax.

 This would be ok for output, but for input, we need to keep accepting both
 forms.

 Please feel free to open another ticket if you can't find one.

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

Re: [tor-bugs] #20159 [Core Tor/Tor]: setevents hs_desc cancels other setevents

[Tor Bug Tracker & Wiki]

#20159: setevents hs_desc cancels other setevents
--+
 Reporter:  grarpamp  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 ok. fwiw, I'd be glad to  take an addevents/delevents command pair as a
 patch.

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

Re: [tor-bugs] #20159 [Core Tor/Tor]: setevents hs_desc cancels other setevents

[Tor Bug Tracker & Wiki]

#20159: setevents hs_desc cancels other setevents
--+
 Reporter:  grarpamp  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by grarpamp):

 Ok, read the spec, my bad. So long as all possible events can fit on a
 single line and tor can parse them out and activate them all, then the
 ticket context can be closed.

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

Re: [tor-bugs] #20153 [Core Tor/Tor]: VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"

[Tor Bug Tracker & Wiki]

#20153: VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--

Comment (by grarpamp):

 > make sure that Tor actually accepts these things without the brackets.

 Of course, as above 'in the code'.

 > "reject [fc00::1]:80"

 It is correct to use brackets to delineate ports when ports are present.

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

Re: [tor-bugs] #20151 [Core Tor/Tor]: Fix parse_virtual_addr_network minimum network size

[Tor Bug Tracker & Wiki]

#20151: Fix parse_virtual_addr_network minimum network size
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.2.??? => Tor: 0.2.9.x-final


Comment:

 This is a one-line fix.  Anybody want to submit a patch?

 +1 if the patch fixes the manpage too, and if the patch explains that
 wider networks are better, because they lower the odds of an attacker
 successfully guessing an in-use IP.

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

Re: [tor-bugs] #20153 [Core Tor/Tor]: VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"

[Tor Bug Tracker & Wiki]

#20153: VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Before somebody goes around removing all the brackets, they should make
 sure that Tor actually accepts these things without the brackets.

 Tor also uses brackets to separate IPv6 addresses from ports, as in
 "reject [fc00::1]:80"

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

Re: [tor-bugs] #20159 [Core Tor/Tor]: setevents hs_desc cancels other setevents

[Tor Bug Tracker & Wiki]

#20159: setevents hs_desc cancels other setevents
--+
 Reporter:  grarpamp  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 This is working as documented: *every* SETEVENTS call replaces all
 previous events.  From the spec:
 {{{
   Any events *not* listed in the SETEVENTS line are turned off; thus,
 sending
   SETEVENTS with an empty body turns off all event reporting.
 }}}

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

Re: [tor-bugs] #20157 [Applications/TorBirdy]: Don't force timezone=UTC when creating new calendar events

[Tor Bug Tracker & Wiki]

#20157: Don't force timezone=UTC when creating new calendar events
---+-
 Reporter:  infinity0  |  Owner:  sukhbir
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by infinity0):

 OK, great thanks! BTW for future reference if you need to do this again
 elsewhere, Europe/London is not exactly equivalent to UTC due to daylight
 savings; you would want Europe/Reykjavik instead.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20159 [Core Tor/Tor]: setevents hs_desc cancels other setevents

[Tor Bug Tracker & Wiki]

#20159: setevents hs_desc cancels other setevents
--+
 Reporter:  grarpamp  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Events set before hs_desc seem to be canceled by hs_desc.
 Events set after hs_desc seem to cancel hs_desc.
 To replicate, do above along with the stream event.

 Events should be an additive OR of all events set.

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rubiate):

 Still crashes with the bug20103_028 branch.


 {{{
 ==17092==ERROR: AddressSanitizer: heap-use-after-free on address
 0x60e0004d8bb8 at pc 0x7fd113288016 bp 0x7ffc5d960c30 sp 0x7ffc5d960c28
 READ of size 2 at 0x60e0004d8bb8 thread T0
 #0 0x7fd113288015 in tor_addr_family src/common/address.h:155
 #1 0x7fd113288015 in tor_addr_is_null src/common/address.c:871
 #2 0x7fd113288458 in tor_addr_is_valid src/common/address.c:932
 #3 0x7fd112faee5b in node_get_all_orports src/or/nodelist.c:836
 #4 0x7fd113265e4a in node_is_a_configured_bridge
 src/or/entrynodes.c:1871
 #5 0x7fd11327290a in any_bridge_supports_microdescriptors
 src/or/entrynodes.c:2487
 #6 0x7fd112f99229 in we_use_microdescriptors_for_circuits
 src/or/microdesc.c:924
 #7 0x7fd112f99553 in usable_consensus_flavor src/or/microdesc.c:961
 #8 0x7fd112fa32ae in networkstatus_set_current_consensus
 src/or/networkstatus.c:1686
 #9 0x7fd11320263c in connection_dir_client_reached_eof
 src/or/directory.c:2009
 #10 0x7fd113206e99 in connection_dir_reached_eof
 src/or/directory.c:2471
 #11 0x7fd1131a996e in connection_reached_eof src/or/connection.c:4841
 #12 0x7fd1131a996e in connection_handle_read_impl
 src/or/connection.c:3528
 #13 0x7fd112f84b67 in conn_read_callback src/or/main.c:803
 #14 0x7fdc93db in event_base_loop (/usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5+0x103db)
 #15 0x7fd112f86396 in run_main_loop_once src/or/main.c:2543
 #16 0x7fd112f86396 in run_main_loop_until_done src/or/main.c:2589
 #17 0x7fd112f86396 in do_main_loop src/or/main.c:2515
 #18 0x7fd112f8bb94 in tor_main src/or/main.c:3646
 #19 0x7fd112f7965b in main src/or/tor_main.c:30
 #20 0x7fd10f6eab44 in __libc_start_main (/lib/x86_64-linux-
 gnu/libc.so.6+0x21b44)
 #21 0x7fd112f7c01a (tor/src/or/tor+0x56501a)

 0x60e0004d8bb8 is located 88 bytes inside of 160-byte region
 [0x60e0004d8b60,0x60e0004d8c00)
 freed by thread T0 here:
 #0 0x7fd111971527 in __interceptor_free (/usr/lib/x86_64-linux-
 gnu/libasan.so.1+0x54527)
 #1 0x7fd112f9b9f9 in networkstatus_vote_free
 src/or/networkstatus.c:313
 #2 0x7fd112fa357a in networkstatus_set_current_consensus
 src/or/networkstatus.c:1660
 #3 0x7fd11320263c in connection_dir_client_reached_eof
 src/or/directory.c:2009
 #4 0x7fd113206e99 in connection_dir_reached_eof
 src/or/directory.c:2471
 #5 0x7fd1131a996e in connection_reached_eof src/or/connection.c:4841
 #6 0x7fd1131a996e in connection_handle_read_impl
 src/or/connection.c:3528
 #7 0x7fd112f84b67 in conn_read_callback src/or/main.c:803
 #8 0x7fdc93db in event_base_loop (/usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5+0x103db)
 }}}

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

Re: [tor-bugs] #17581 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Delete https rule to lurkmore.to causing access problem

[Tor Bug Tracker & Wiki]

#17581: Delete https rule to lurkmore.to causing access problem
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Blocker  | Resolution:  fixed
 Keywords:  httpse-ruleset-bug   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by fuglede):

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


Comment:

 https://lurkmore.to works completely fine for me, so I'm thinking that
 this issue must have fixed itself at some point. If the issue does
 persist, do please reopen this one.

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

Re: [tor-bugs] #17195 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere breaks the Vuze Blog

[Tor Bug Tracker & Wiki]

#17195: HTTPS Everywhere breaks the Vuze Blog
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by fuglede):

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


Comment:

 Looks like this was fixed in `3c5a7c61feb4e5a87c2c2a1ed547a4ec4ae5f2fc`.

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

Re: [tor-bugs] #17054 [HTTPS Everywhere/EFF-HTTPS Everywhere]: change lock color for insecure ssl ciphers

[Tor Bug Tracker & Wiki]

#17054: change lock color for insecure ssl ciphers
---+--
 Reporter:  elypter|  Owner:  jsha
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by fuglede):

 * severity:   => Normal


Comment:

 The idea of having a browser extension which does that is certainly good
 enough, but I wouldn't consider it within the scope of HTTPS Everywhere
 (which currently carries out any kinds of checks on the ciphers that are
 used).

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

Re: [tor-bugs] #19317 [Metrics/CollecTor]: Sanitize TCP ports in bridge descriptors

[Tor Bug Tracker & Wiki]

#19317: Sanitize TCP ports in bridge descriptors
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * priority:  Medium => High


Comment:

 Please review the last two commits in
 [https://gitweb.torproject.org/karsten/metrics-db.git/log/?h=task-19317-2
 my branch task-19317-2].  The first commit
 ([https://gitweb.torproject.org/karsten/metrics-
 db.git/commit/?h=task-19317-2=ecb053899eb965c2778cf05479c26549d67f7956
 ecb0538]) has the same code as the [https://gitweb.torproject.org/karsten
 /metrics-
 db.git/commit/?h=task-19317=c742c388da500b0f9b2df236f49d280aa2715c96
 commit in my earlier task-19317 branch], rebased to master.  Note that
 this patch doesn't include changes based on the
 [https://trac.torproject.org/projects/tor/ticket/19317#comment:8
 suggestions above], which we should make as soon as unit tests are in
 place.  The second commit ([https://gitweb.torproject.org/karsten/metrics-
 db.git/commit/?h=task-19317-2=f608c94c7f731241bf7ee8e627ca1da98c23d858
 f608c94]) splits tarballs into one per month and descriptor type.  I'm
 already running this code in parallel to the main CollecTor instance, and
 I'm ready to switch over as soon as 1) the tarball samples I sent you look
 okay and 2) this branch is ready to be merged.  By the way, I'd say we
 don't need to put out a release for this, but I can as well run a -dev
 version on the primary CollecTor instance.

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

Re: [tor-bugs] #11284 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere blocking DiS CSS and images

[Tor Bug Tracker & Wiki]

#11284: HTTPS Everywhere blocking DiS CSS and images
-+-
 Reporter:  cypherpunks  |  Owner:  pde
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  HTTPS-E next Chrome
 |  release
Component:  HTTPS Everywhere/EFF-|Version:  HTTPS-E chrome
  HTTPS Everywhere   |  2013.10.16
 Severity:  Normal   | Resolution:  fixed
 Keywords:  CSS, Images, Chrome  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by fuglede):

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


Comment:

 I had a quick browse around, and to me the site looks similar no matter if
 the ruleset is on or not, so it would appear that this one has fixed
 itself over time. Closing as such, but please reopen if it remains
 problematic. In that case, a link for a page with breakage would be
 helpful in nailing the issue.

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

Re: [tor-bugs] #14003 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Add forum.startmail.com and support.startmail.com to the StartMail ruleset

[Tor Bug Tracker & Wiki]

#14003: Add forum.startmail.com and support.startmail.com to the StartMail 
ruleset
---+-
 Reporter:  cypherpunks|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by fuglede):

 * severity:   => Normal


Comment:

 Added in https://github.com/EFForg/https-everywhere/pull/6906

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rubiate):

 It was 0.2.8.7 until I added debugging statements so that's probably not
 helpful. The line is   "networkstatus_vote_free(current_md_consensus)"
 which is really on src/or/networkstatus.c:1651


 Here it is with proper line numbers. This is from the tor-0.2.8.7 tag, or
 "Tor v0.2.8.7 (git-263088633a63982a)".

 {{{
 freed by thread T0 here:
 #0 0x7f7f8ef24527 in __interceptor_free (/usr/lib/x86_64-linux-
 gnu/libasan.so.1+0x54527)
 #1 0x7f7f9054e9f9 in networkstatus_vote_free
 src/or/networkstatus.c:313
 #2 0x7f7f90556563 in networkstatus_set_current_consensus
 src/or/networkstatus.c:1651
 #3 0x7f7f907b568c in connection_dir_client_reached_eof
 src/or/directory.c:2009
 #4 0x7f7f907b9ee9 in connection_dir_reached_eof
 src/or/directory.c:2471
 #5 0x7f7f9075c9be in connection_reached_eof src/or/connection.c:4841
 #6 0x7f7f9075c9be in connection_handle_read_impl
 src/or/connection.c:3528
 #7 0x7f7f90537b67 in conn_read_callback src/or/main.c:803
 #8 0x7f7f8e77c3db in event_base_loop (/usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5+0x103db)
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20158 [Internal Services/Blog]: Comments on the 3 most recent blog posts disappeared

[Tor Bug Tracker & Wiki]

#20158: Comments on the 3 most recent blog posts disappeared
+-
 Reporter:  boklm   |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Blog  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 We can still see them in the admin interface, under the list of published
 comments, so they are not completely lost, but they don't appear anymore
 under the blog posts.

 Posting new comments is still working.

 It could be related to the reboot of the server hosting the blog today.

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

Re: [tor-bugs] #20157 [Applications/TorBirdy]: Don't force timezone=UTC when creating new calendar events

[Tor Bug Tracker & Wiki]

#20157: Don't force timezone=UTC when creating new calendar events
---+-
 Reporter:  infinity0  |  Owner:  sukhbir
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by sukhbir):

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


Comment:

 Thanks for reporting. Other users also complained about this and given
 this is a local setting, I reverted it in
 
[https://gitweb.torproject.org/torbirdy.git/commit/?id=3ea8e5d3280515d1ac15f1e7002bce05fff29ba7
 3ea8e] earlier and this will be a part of the next release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20157 [Applications/TorBirdy]: Don't force timezone=UTC when creating new calendar events

[Tor Bug Tracker & Wiki]

#20157: Don't force timezone=UTC when creating new calendar events
---+-
 Reporter:  infinity0  |  Owner:  sukhbir
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Currently, TorBirdy sets the Thunderbird internal timezone to UTC to avoid
 leaking the user's location when sending emails. However, this carries
 through to the Calendar functionality [1] and now when I create a new
 event it defaults to Europe/London timezone.

 For usability, this should still be in the user's own local timezone - I
 think there is not much security value in forcing this to UTC for everyone
 since you're already trusting your calendar provider with quite a lot of
 information. (Or at least default to local tz, and allow the user to
 explicitly override it to UTC.)


 [1] This was integrated into recent Thunderbird versions, you should be
 able to see it in your "add-ons", as either "Lightning" or "Iceowl"
 (Debian).

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

Re: [tor-bugs] #20154 [Applications/Tor Browser]: If you specify a exit node you can not connect to url that contain the port number

[Tor Bug Tracker & Wiki]

#20154: If you specify a exit node you can not connect to url that contain the 
port
number
--+---
 Reporter:  w |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dcf):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 Thanks for reporting this. In this case, while it might be surprising, Tor
 Browser is only doing what you instructed.

 Every exit node has an "[[doc/ReducedExitPolicy|exit policy]]" that says
 what destinations and ports it is willing to connect to. An exit policy
 that only allows access to ports 22, 80, and 443 would look like this:
 {{{
 accept *:22
 accept *:80
 accept *:443
 reject *:*
 }}}
 It must be that the exit node you chose does not allow access to port 182.
 Tor cannot build a circuit that violates the exit policy, so it gives up.
 When you remove your ExitNodes setting, Tor is free to choose a different
 exit node, one that ''does'' allow access to port 182, which is why Tor
 works in that case. When you omit the port number, Tor Browser uses the
 default port number 80, which is allowed by almost all exits.

 You can check the exit policy of your chosen exit node by searching for it
 at https://atlas.torproject.org/. If the exit does not allow the port you
 want, there's nothing you can do—you have to choose a different exit.

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Branch `bug20103_028` might fix this.  Before I put it in needs_review,
 though, it would be good to have it get testing.  (I could also use an
 answer to my question above about the exact Tor version)

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Oh MAN.  When we free the consensus earlier (line 1662) in
 networkstatus_vote_free, we don't  we don't invalidate all the
 routerstatus_t objects that the node_t structures point to.  But they are
 used deep inside download_status_reset().  Tricky!

 Could you tell me what exact version of Tor you were testing on debian
 above?  I want to make sure that it is
 "networkstatus_free(current_md_consensus)" that's on line
 src/or/networkstatus.c:1662 , not some other networkstatus_free().

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Okay, it looks like there's a logic error inside
 networkstatus_set_current_consensus().

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

Re: [tor-bugs] #20103 [Core Tor/Tor]: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4

[Tor Bug Tracker & Wiki]

#20103: Crash on OpenBSD: tor invoked from Tor Browser 6.0.4
-+-
 Reporter:  attila   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  bug regression 028-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rubiate):

 Bah, I'm slow. Of course, it works the same everywhere, just the results
 are different. On OpenBSD the memory is read protected after it's freed,
 hence crashes.

 I should have compiled it ASAN on Debian (doh, that's probably what you
 meant), would've worked this out faster.

 {{{
 ==12100==ERROR: AddressSanitizer: heap-use-after-free on address
 0x60e0004adf78 at pc 0x7f5185128426 bp 0x7ffed0454d70 sp 0x7ffed0454d68
 READ of size 2 at 0x60e0004adf78 thread T0
 #0 0x7f5185128425 in tor_addr_family src/common/address.h:155
 #1 0x7f5185128425 in tor_addr_is_null src/common/address.c:871
 #2 0x7f5185128868 in tor_addr_is_valid src/common/address.c:932
 #3 0x7f5184e4f23b in node_get_all_orports src/or/nodelist.c:838
 #4 0x7f518510625a in node_is_a_configured_bridge
 src/or/entrynodes.c:1871
 #5 0x7f5185112d1a in any_bridge_supports_microdescriptors
 src/or/entrynodes.c:2487
 #6 0x7f5184e39499 in we_use_microdescriptors_for_circuits
 src/or/microdesc.c:924
 #7 0x7f5184e397c3 in usable_consensus_flavor src/or/microdesc.c:961
 #8 0x7f5184e3fe8f in networkstatus_consensus_is_bootstrapping
 src/or/networkstatus.c:1257
 #9 0x7f51850977da in find_dl_schedule src/or/directory.c:3731
 #10 0x7f51850a005e in download_status_reset src/or/directory.c:3950
 #11 0x7f5184e43cd0 in networkstatus_set_current_consensus
 src/or/networkstatus.c:1690
 #12 0x7f51850a2a4c in connection_dir_client_reached_eof
 src/or/directory.c:2009
 #13 0x7f51850a72a9 in connection_dir_reached_eof
 src/or/directory.c:2471
 #14 0x7f5185049d7e in connection_reached_eof src/or/connection.c:4841
 #15 0x7f5185049d7e in connection_handle_read_impl
 src/or/connection.c:3528
 #16 0x7f5184e24dd7 in conn_read_callback src/or/main.c:803
 #17 0x7f51830693db in event_base_loop (/usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5+0x103db)
 #18 0x7f5184e26606 in run_main_loop_once src/or/main.c:2543
 #19 0x7f5184e26606 in run_main_loop_until_done src/or/main.c:2589
 #20 0x7f5184e26606 in do_main_loop src/or/main.c:2515
 #21 0x7f5184e2be04 in tor_main src/or/main.c:3646
 #22 0x7f5184e198cb in main src/or/tor_main.c:30
 #23 0x7f518158ab44 in __libc_start_main (/lib/x86_64-linux-
 gnu/libc.so.6+0x21b44)
 #24 0x7f5184e1c28a (tor/src/or/tor+0x56528a)

 0x60e0004adf78 is located 88 bytes inside of 160-byte region
 [0x60e0004adf20,0x60e0004adfc0)
 freed by thread T0 here:
 #0 0x7f5183811527 in __interceptor_free (/usr/lib/x86_64-linux-
 gnu/libasan.so.1+0x54527)
 #1 0x7f5184e3b9ea in networkstatus_vote_free
 src/or/networkstatus.c:320
 #2 0x7f5184e43915 in networkstatus_set_current_consensus
 src/or/networkstatus.c:1662
 #3 0x7f51850a2a4c in connection_dir_client_reached_eof
 src/or/directory.c:2009
 #4 0x7f51850a72a9 in connection_dir_reached_eof
 src/or/directory.c:2471
 #5 0x7f5185049d7e in connection_reached_eof src/or/connection.c:4841
 #6 0x7f5185049d7e in connection_handle_read_impl
 src/or/connection.c:3528
 #7 0x7f5184e24dd7 in conn_read_callback src/or/main.c:803
 #8 0x7f51830693db in event_base_loop (/usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5+0x103db)

 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20156 [Internal Services/Blog]: log.torproject.org is DOWN

[Tor Bug Tracker & Wiki]

#20156: log.torproject.org is DOWN
+-
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Blog  |Version:
 Severity:  Blocker |   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] #15852 [Applications/Tor Browser]: Remove/synchronize Torbutton SOCKS pref logic

[Tor Bug Tracker & Wiki]

#15852: Remove/synchronize Torbutton SOCKS pref logic
-+-
 Reporter:  mikeperry|  Owner:  brade
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-4.5-regression, tbb-torbutton-   |  Actual Points:
  conversion, TorBrowserTeam201608R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by gk):

 Replying to [comment:20 legind]:
 > Is  there any reason why the config options
 >
 > {{{
 > extensions.torbutton.socks_host
 > extensions.torbutton.socks_port
 > }}}
 >
 > were not removed with this update?  Are they still being used anywhere?

 Looking at Torbutton master it seems to me they are gone as well? Grepping
 in different ways does not show instances of them anymore. Where do you
 still see 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] #19996 [HTTPS Everywhere]: extensions.torbutton.https_proxy and similar preferences are gone

[Tor Bug Tracker & Wiki]

#19996: extensions.torbutton.https_proxy and similar preferences are gone
--+--
 Reporter:  gk|  Owner:  legind
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 This is correct. There might even be more prefs that got removed and are
 important for HTTPS-E (probably for its SSL observatory code). I have not
 checked that closely. Just saw the issue mentioned in this ticket in the
 browser console.

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

Re: [tor-bugs] #20155 [Internal Services/Service - trac]: Cannot login to trac using onion service

[Tor Bug Tracker & Wiki]

#20155: Cannot login to trac using onion service
--+---
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 This is a duplicate of #19963.

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