Re: [tor-bugs] #19061 [Core Tor/Stem]: Tor event descriptions

2016-05-15 Thread Tor Bug Tracker & Wiki
#19061: Tor event descriptions
---+
 Reporter:  sambuddhabasu  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by sambuddhabasu):

 I have updated some files to work accordingly. Please take a look at:
 https://github.com/sammyshj/stem/pull/4

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


[tor-bugs] #19061 [Core Tor/Stem]: Tor event descriptions

2016-05-15 Thread Tor Bug Tracker & Wiki
#19061: Tor event descriptions
---+
 Reporter:  sambuddhabasu  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Allow stem to provide descriptions for Tor events.

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


Re: [tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

2016-05-15 Thread Tor Bug Tracker & Wiki
#18620: HSFORGET command to clear cached client state for a HS
-+-
 Reporter:  str4d|  Owner:  str4d
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-hs, 029-accepted, review-|Version:  Tor:
  group-1|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  asn  |  Actual Points:
 | Points:  small
 |Sponsor:
 |  SponsorR-can
-+-

Comment (by str4d):

 Thanks for the review asn! Apologies for the issues getting the patch to
 work - it was based on Tor 0.2.7.6 (which is the version Briar is
 currently using). I have ported the patch onto master (with associated
 changes per your review), and uploaded it here:

 https://github.com/str4d/tor/tree/18620-hsforget

 > Do you think that would be useful for this patch?

 I don't believe so, because the new `rend_cache_remove_entry()` function
 calls `rend_cache_entry_free(cache_entry)`, which calls
 `rend_service_descriptor_free(cache_entry->parsed)`, which contains:

 {{{
   if (desc->intro_nodes) {
 SMARTLIST_FOREACH(desc->intro_nodes, rend_intro_point_t *, intro,
   rend_intro_point_free(intro););
 smartlist_free(desc->intro_nodes);
   }
 }}}

 Thus the `rend_intro_point_t` objects are never reused.

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


Re: [tor-bugs] #12890 [Core Tor/Tor]: Design and implement optimizations for socket write limits

2016-05-15 Thread Tor Bug Tracker & Wiki
#12890: Design and implement optimizations for socket write limits
--+--
 Reporter:  robgjansen|  Owner:
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, 027-triaged-1-out  |  Actual Points:
Parent ID:  #12541| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

 * severity:   => Normal


Comment:

 Linux 4.6.0 adds a somewhat more friendly bit of information to `struct
 tcp_info` that might increase accuracy (write_seq - snd_nxt).

 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cd9b266095f422267bddbec88f9098b48ea548fc
 {{{
 tcpi_notsent_bytes reports the amount of bytes in the write queue that
 were not yet sent.
 }}}

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


Re: [tor-bugs] #19060 [Core Tor/Tor]: Should SafeLogging hide bridge IP addresses in logs?

2016-05-15 Thread Tor Bug Tracker & Wiki
#19060: Should SafeLogging hide bridge IP addresses in logs?
+--
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  029-proposed, easy  |  Actual Points:
Parent ID:  | Points:  small
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 I'm wary of crippling log lines like these. We put the IP:port in there
 specifically so operators (who, like most humans, are notoriously bad at
 debugging or questioning assumptions) would be forced to confront that
 it's a different one than they thought it would be. If we give them
 another hoop to jump through, most of them won't, and we might as well
 just rip out the log line.

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


Re: [tor-bugs] #18994 [Applications/Tor Browser]: Tor crashes after tor browser update running bridge mode in Windows

2016-05-15 Thread Tor Bug Tracker & Wiki
#18994: Tor crashes after tor browser update running bridge mode in Windows
--+--
 Reporter:  eli   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor broser, bridge mode   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by eli):

 Replying to [comment:6 teor]:
 > Replying to [comment:5 eli]:
 > > comment by teor:
 > > > Your Tor is running as a bridge relay using the Tor Browser bundle
 > on Windows.
 > > > I'm not sure if that's something we support.
 > > > Where are those instructions from?
 > >
 > > Nowhere.  Based on my experience running windows bridges in previous
 versions of tor I assumed that the same could be done in tor browser 4+.
 I guess I should've taken the hint when torrc-defaults no longer had any
 suggestions for bridge lines.  I did ask about this at
 h...@rt.torproject.org before I learned that it had been shut down.
 > >
 > > FWIW: I'd bought a low-power box intending to dedicate it to running
 bridges 24/7, assuming that I could load a linux distro onto it.  Turns
 out that's not true; the CPU/graphics chips, which are hardwired in, can't
 load Debian or even run it from a live USB or CD.  So as long as I'm using
 that box I'll have to run tor for windows.
 > >
 > > The other reason that I thought I should be able to run a bridge mode
 under tor browser is the windows bridges I'm seeing in .../server-
 descriptors/ .
 >
 > Do you mean bridges, or relays?

 Bridges.

 > Bridges are relays with `BridgeRelay 1` set in their torrc, and they
 don't appear in the standard set of Tor network descriptors.

 Yes, that's how I configure torrc.

 > The supported way of running a bridge or relay on Windows is using the
 expert bundle linked from
 https://www.torproject.org/download/download.html.en

 Thanks, I was about to go looking for that.

 > > (Admittedly a small number: currently less than 100. I haven't been
 able to make the time to extract previous numbers from archives.  Tor
 browser in client mode is excellent; but are devs moving toward bridge
 mode being enabled in *nix only?)
 >
 > No, we are happy for people to run relays or bridges on Windows, but
 it's not a very common configuration. So we sometimes have trouble
 debugging and maintaining it.
 >
 > We would love people to test relays and bridges on Windows and help
 improve support for them.

 Good. I'll teach myself how to build from source.

 > > > It's also worth noting that you just leaked your bridge's IP
 address, > so it might be worth getting another IP address if it's static.
 > >
 > > That may be because I've been testing different configurations, and
 not paying attention to DNS leakage. Could it be because I'm enabling
 SafeLogging 1 during tests?
 >
 > Do you mean `SafeLogging 0`?

 Yes, sorry for the mistype. I do follow the instructions in tor-
 manual.html.en.pdf

 > `SafeLogging 1` is the default, and hides client IP addresses in some
 log messages.
 > But it doesn't hide bridge IP addresses, see #19060 for a suggested fix
 for this.

 Tnanks for this pointer.

 > > > It looks like your torrc is not set up in a way that Tor Browser can
 > > > find the ControlPort. Is the ControlPort on 9150 where Tor Browser
 > > > expects it to be?
 > >
 > > Yes, that's the error msg about half the time. I was able to use
 ControlPortWriteToFile to identify the control port in previous
 configurations (I recall it was 9150, but I killed that log and may be
 misremembering.) In the few configurations I was able to (too quickly) run
 this past week, that line hasn't been producing output.
 >
 > Why not set a static ControlPort using `ControlPort 9150`?

 I did that, but  for some reason it didn't work during last weeks trials.
 Probably  something I overlooked during the rushed sessions. Will try
 again.

 thanks again, I'll move along on all you've suggested. Unfortunately I
 don't get much time except on weekens, so more result s will come along
 slowly. FWIW here's the torrc I've generally been testing:

 # This file was generated by Tor; if you edit it, comments will not be
 preserved
 # The old torrc file was renamed to torrc.orig.1 or similar, and Tor will
 ignore it

 BridgeRelay 1
 ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec
 TorBrowser\Tor\PluggableTransports \obfs4proxy
 ContactInfo eliaz [at] riseup.net
 ControlPort 127.0.0.1:9150
 ControlPortWriteToFile C:\Users\Ed Agro\AppData\Roaming\tor\Log\control-
 port160511-1705HRS.txt
 DataDirectory C:\sources\tor\TBB installed\Tor
 Browser\Browser\TorBrowser\Data\Tor
 ExitPolicy reject *:*
 GeoIPFile 

Re: [tor-bugs] #15588 [Core Tor/Tor]: Allow client authorization on control port ADD_ONION services

2016-05-15 Thread Tor Bug Tracker & Wiki
#15588: Allow client authorization on control port ADD_ONION services
-+-
 Reporter:  special  |  Owner:  special
 Type:  enhancement  | Status:
 Priority:  High |  reopened
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-hs, control, TorCoreTeam201605,  |Version:
  TorCoreTeam-postponed-201604   | Resolution:
Parent ID:  #8993|  Actual Points:
 Reviewer:  nickm| Points:  small
 |Sponsor:
-+-
Changes (by atagar):

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


Comment:

 Hi there, just a minor
 [https://gitweb.torproject.org/torspec.git/commit/?id=c2865d9 spec
 issue]...

 {{{
 + [ClientAuth was added in Tor 0.x.x.x.]
 }}}

 Actual version please. :)

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


Re: [tor-bugs] #18994 [Applications/Tor Browser]: Tor crashes after tor browser update running bridge mode in Windows

2016-05-15 Thread Tor Bug Tracker & Wiki
#18994: Tor crashes after tor browser update running bridge mode in Windows
--+--
 Reporter:  eli   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor broser, bridge mode   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:5 eli]:
 > comment by teor:
 > > Your Tor is running as a bridge relay using the Tor Browser bundle
 > on Windows.
 > > I'm not sure if that's something we support.
 > > Where are those instructions from?
 >
 > Nowhere.  Based on my experience running windows bridges in previous
 versions of tor I assumed that the same could be done in tor browser 4+.
 I guess I should've taken the hint when torrc-defaults no longer had any
 suggestions for bridge lines.  I did ask about this at
 h...@rt.torproject.org before I learned that it had been shut down.
 >
 > FWIW: I'd bought a low-power box intending to dedicate it to running
 bridges 24/7, assuming that I could load a linux distro onto it.  Turns
 out that's not true; the CPU/graphics chips, which are hardwired in, can't
 load Debian or even run it from a live USB or CD.  So as long as I'm using
 that box I'll have to run tor for windows.
 >
 > The other reason that I thought I should be able to run a bridge mode
 under tor browser is the windows bridges I'm seeing in .../server-
 descriptors/ .

 Do you mean bridges, or relays?

 Bridges are relays with `BridgeRelay 1` set in their torrc, and they don't
 appear in the standard set of Tor network descriptors.

 The supported way of running a bridge or relay on Windows is using the
 expert bundle linked from
 https://www.torproject.org/download/download.html.en

 > (Admittedly a small number: currently less than 100. I haven't been able
 to make the time to extract previous numbers from archives.  Tor browser
 in client mode is excellent; but are devs moving toward bridge mode being
 enabled in *nix only?)

 No, we are happy for people to run relays or bridges on Windows, but it's
 not a very common configuration. So we sometimes have trouble debugging
 and maintaining it.

 We would love people to test relays and bridges on Windows and help
 improve support for them.

 > > It's also worth noting that you just leaked your bridge's IP address,
 > so it might be worth getting another IP address if it's static.
 >
 > That may be because I've been testing different configurations, and not
 paying attention to DNS leakage. Could it be because I'm enabling
 SafeLogging 1 during tests?

 Do you mean `SafeLogging 0`?
 `SafeLogging 1` is the default, and hides client IP addresses in some log
 messages.
 But it doesn't hide bridge IP addresses, see #19060 for a suggested fix
 for this.

 > > It looks like your torrc is not set up in a way that Tor Browser can
 > > find the ControlPort. Is the ControlPort on 9150 where Tor Browser
 > > expects it to be?
 >
 > Yes, that's the error msg about half the time. I was able to use
 ControlPortWriteToFile to identify the control port in previous
 configurations (I recall it was 9150, but I killed that log and may be
 misremembering.) In the few configurations I was able to (too quickly) run
 this past week, that line hasn't been producing output.

 Why not set a static ControlPort using `ControlPort 9150`?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19060 [Core Tor/Tor]: Should SafeLogging hide bridge IP addresses in logs?

2016-05-15 Thread Tor Bug Tracker & Wiki
#19060: Should SafeLogging hide bridge IP addresses in logs?
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  029-proposed, easy
Actual Points:|  Parent ID:
   Points:  small |   Reviewer:
  Sponsor:|
--+
 Bridge relay operators sometimes post logs containing their bridge's IP
 address.

 We could make this less likely by making `SafeLogging 1` (the default)
 filter bridge IP addresses in messages like:
 * "Your server (%s:%d) has not managed to confirm that its ORPort is
 reachable" ...
 * "Your server (%s:%d) has not managed to confirm that its DirPort is
 reachable" ...
 * "Now checking whether ORPort %s:%d"...
 * "and DirPort %s:%d"
 * anything else that lists a bridge's IP or fingerprint

 This could be implemented by creating safe_str_bridge and
 escaped_safe_str_bridge similar to safe_str and escaped_safe_str, but with
 a check if BridgeRelay is 1 as well. It would also need a tor manual page
 update that says that we escape bridge information when SafeLogging is
 anything besides "0".

 Or, we could add "bridge" to the options for SafeLogging, but that seems
 over-complicated, because we'd have to define 1 vs relay vs bridge
 semantics in a way that makes sense.

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


Re: [tor-bugs] #19057 [Internal Services/Wiki]: Prohibit modifications of doc/EmailProvider

2016-05-15 Thread Tor Bug Tracker & Wiki
#19057: Prohibit modifications of doc/EmailProvider
+--
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [comment:4 cypherpunks]:
 > >Please lets discuss that on tor talk, here is the email I wrote:
 > Sorry, I won't. I have already given you too much deanonymizing
 information.

 nothing should stop you from creating a random email address at one of the
 recommended mail providers ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19059 [Internal Services/Service - lists]: Request for gsoc-admin@ list

2016-05-15 Thread Tor Bug Tracker & Wiki
#19059: Request for gsoc-admin@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Minor  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Hi there, just a quick request for a new list. We presently have a
 gsoc2016@ alias that points to tor-team@. It would be nice if we had a
 proper gsoc-admin@ list, and updated that alias to point there.

 list name: gsoc-admin
 list admins: atagar

 This should be a closed list. I'll add Roger and Sebastian (the other
 admins) to the list once it's created.

 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


[tor-bugs] #19058 [HTTPS Everywhere/EFF-HTTPS Everywhere]: IMDB photogalleries inaccesible

2016-05-15 Thread Tor Bug Tracker & Wiki
#19058: IMDB photogalleries inaccesible
---+--
 Reporter:  cypherpunks|  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal |   Keywords:  imdb
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 While changing image links of galleries on imdb.com, they're rewritten to
 secure.imdb.com, which now requires IMDbPro login (paid).

 It seems the solution would be turning this rule off.

 This is most probably the offending rule:
 {{{
 https://secure.imdb.com/$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] #18733 [Metrics/CollecTor]: contributor's guide incl. coding guidelines for java projects

2016-05-15 Thread Tor Bug Tracker & Wiki
#18733: contributor's guide incl. coding guidelines for java projects
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID:  #18730 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Started a wiki page summarizing the findings
 
[https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/MetricsJavaStyleGuide
 here].

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


Re: [tor-bugs] #18841 [Core Tor/Tor]: Test test_bt.sh fails

2016-05-15 Thread Tor Bug Tracker & Wiki
#18841: Test test_bt.sh fails
--+
 Reporter:  trudokal  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Major | Resolution:
 Keywords:  test, patch 026-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by trudokal):

 Hi nickm

 Just wanted to say thanks for your responsiveness and cooperation. Keep up
 the good work!

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


Re: [tor-bugs] #19057 [Internal Services/Wiki]: Prohibit modifications of doc/EmailProvider

2016-05-15 Thread Tor Bug Tracker & Wiki
#19057: Prohibit modifications of doc/EmailProvider
+--
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Replying to [comment:4 cypherpunks]:
 > Your fucking spam filter and fucking recaptcha ate my detailed response
 for the word bu5ine55. BTW, I have solved recaptcha correctly, but still
 was kicked. Why do I see this shit on your site?
 >
 > @mo, in brief: they can be forced either legally (by court order or by
 law) or illegally (by blackmailing owners by using evidence forged or
 illegally (surveillance without court order) discovered or by stopping
 bu5ine55 operation (it's legal to stop operation, by the decision of high-
 ranked law enforcement officer in my jurisdiction, so it is often used for
 blackmailing bu5ine55men)) to implement users identification via phone
 and, may be, browser fingerprinting. Rarity of good email services says
 that they are. It's not about spam (spam filters using machine learning
 work extremely well), it's all about not making law enforcement angry.
 >
 > >Please lets discuss that on tor talk, here is the email I wrote:
 > Sorry, I won't. I have already given you too much deanonymizing
 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] #19057 [Internal Services/Wiki]: Prohibit modifications of doc/EmailProvider

2016-05-15 Thread Tor Bug Tracker & Wiki
#19057: Prohibit modifications of doc/EmailProvider
+--
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by cypherpunks):

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


Comment:

 Your fucking spam filter and fucking recaptcha ate my detailed response
 for the word bu5ine55. Are you also adversary?

 @mo, in short: they can be forced either legally or illegally to implement
 users identification via phone. Rarity of good email services says that
 they are. It's not about spam (spam filters using machine learning work
 extremely well), it's all about not making law enforcement angry.

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


Re: [tor-bugs] #19057 [Internal Services/Wiki]: Prohibit modifications of doc/EmailProvider

2016-05-15 Thread Tor Bug Tracker & Wiki
#19057: Prohibit modifications of doc/EmailProvider
+-
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  | Resolution:  invalid
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by cypherpunks):

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


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


Re: [tor-bugs] #19057 [Internal Services/Wiki]: Prohibit modifications of doc/EmailProvider

2016-05-15 Thread Tor Bug Tracker & Wiki
#19057: Prohibit modifications of doc/EmailProvider
+-
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by cypherpunks):

 Hi,

 I started that wiki page and I noticed your - from my point of view -
 unjustified edits/worries.
 Please lets discuss that on tor talk, here is the email I wrote:
 https://lists.torproject.org/pipermail/tor-talk/2016-May/040915.html

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


Re: [tor-bugs] #19057 [Internal Services/Wiki]: Prohibit modifications of doc/EmailProvider

2016-05-15 Thread Tor Bug Tracker & Wiki
#19057: Prohibit modifications of doc/EmailProvider
+-
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by mo):

 I disagree. You seem to have a misconception of how law enforcement works.
 There is no legal pressure to not accept Tor users; the reason why mail
 providers start rejecting Tor users is because a minority of the Tor users
 create annoyances due to spamming and abuse. In certain situations of
 course law enforcement would contact a mail provider and ask them to
 idenify a user, but that is the result of active misuse, not because they
 found it on a list on the Torproject wiki, and in the usual jurisdiction
 this is not a legal problem since it is legal to not verify user
 information. Law enforcement will not reach out and pressure a provider
 simply because of the fact they allow or don't allow Tor users.

 Not listing providers in that sense will protect them from being easily
 found from a large number of Tor users and abusers. This will reduce the
 abuse, which will probably result in them allowing Tor "by accident" (by
 default) for longer. This is a larger discussion around misuse and
 protecting "valuable" services, but for me the benefits and the
 publication of such information outweighs the downsides.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19057 [Internal Services/Wiki]: Prohibit modifications of doc/EmailProvider

2016-05-15 Thread Tor Bug Tracker & Wiki
#19057: Prohibit modifications of doc/EmailProvider
+-
 Reporter:  cypherpunks |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 Someone have created doc/EmailProvider and constantly removes my notes
 from there. Creating such a list, especially on torproject official
 website, can be harmful, because it reduces the cost of discovering such
 services to law enforcement.
 The fact users are not identified are flaws in a state, and states will
 fix them. Those unfixed services are really rare. Creating such a public
 list will allow law enforcement to fix them all. All the law enforcement
 will have to do is to monitor such lists and enforce services` owners.

 So I propose to lock the page to prevent addition of services and make an
 official statement about it.

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


Re: [tor-bugs] #11776 [Applications/Tor Browser]: Could not connect to tor control port

2016-05-15 Thread Tor Bug Tracker & Wiki
#11776: Could not connect to tor control port
--+--
 Reporter:  jim197|  Owner:
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by uedadayon):

 I changed all of my network settings and now it's working.
 I don't know what's wrong but network setting would be caused.

 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] #18743 [Applications/Tor Browser]: "Sign in to Sync" icon not hidden in ESR45-based Tor Browser

2016-05-15 Thread Tor Bug Tracker & Wiki
#18743: "Sign in to Sync" icon not hidden in ESR45-based Tor Browser
-+-
 Reporter:  mcs  |  Owner:  tbb-team
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff45-esr, TorBrowserTeam201605 => ff45-esr,
 TorBrowserTeam201605R
 * status:  needs_revision => needs_review


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


Re: [tor-bugs] #18743 [Applications/Tor Browser]: "Sign in to Sync" icon not hidden in ESR45-based Tor Browser

2016-05-15 Thread Tor Bug Tracker & Wiki
#18743: "Sign in to Sync" icon not hidden in ESR45-based Tor Browser
+--
 Reporter:  mcs |  Owner:  tbb-team
 Type:  defect  | Status:
 Priority:  Medium  |  needs_revision
Component:  Applications/Tor Browser|  Milestone:
 Severity:  Normal  |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605  | Resolution:
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--

Comment (by arthuredelstein):

 Thanks for the good suggestions. Here's a new version with both things
 fixed.

 ​https://github.com/arthuredelstein/torbutton/commit/18743+1
 Hash 5b17ddc4efa21716cf666594930469a99e398d44

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