Re: [tor-bugs] #29128 [Core Tor/Tor]: Place complete obfs4 bridge line in accessible location

[Tor Bug Tracker & Wiki]

#29128: Place complete obfs4 bridge line in accessible location
-+-
 Reporter:  phoul|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, tor-doc, |  Actual Points:
  040-deferred-20190220  |
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28
-+-
Changes (by teor):

 * status:  needs_information => new


Comment:

 Replying to [comment:11 phw]:
 > Replying to [comment:9 nickm]:
 > > Is there a standardized way for Tor to learn from the PT which fields
 it should put in the Bridge line?  It knows the `fingerprint`, and it has
 a good guess about the `address` field (though the PT may want to override
 that), but it  usually needs the PT's help to learn the `port` and any
 other fields.
 > [[br]]
 > I believe that all we need is in the `SMETHOD` line that Tor reads from
 the PT proxy's stdout.

 The complete PT line is sent to bridge users by BridgeDB.
 (That line *must* contain all the required information, otherwise bridge
 users wouldn't be able to use the bridge.)

 BridgeDB gets bridge PT lines from bridge extra-info document "transport"
 lines:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1211

 These lines come from pt_get_extra_info_descriptor_string(), which you
 should be able to just dump to a file:
 
https://github.com/torproject/tor/blob/989b6325d671744aacec191b181e8b0b0fee35be/src/feature/client/transports.c#L1613

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

Re: [tor-bugs] #25204 [Applications/Tor Browser]: Switch security.insecure_connection_* prefs to warn users about insecure HTTP in FF60-esr

[Tor Bug Tracker & Wiki]

#25204: Switch security.insecure_connection_* prefs to warn users about insecure
HTTP in FF60-esr
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr, ux-team |  Actual Points:
Parent ID:  #30037| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Backport https://bugzilla.mozilla.org/show_bug.cgi?id=1562881

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

Re: [tor-bugs] #29128 [Core Tor/Tor]: Place complete obfs4 bridge line in accessible location

[Tor Bug Tracker & Wiki]

#29128: Place complete obfs4 bridge line in accessible location
-+-
 Reporter:  phoul|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, tor-doc, |  Actual Points:
  040-deferred-20190220  |
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28
-+-

Comment (by phw):

 Replying to [comment:9 nickm]:
 > Is there a standardized way for Tor to learn from the PT which fields it
 should put in the Bridge line?  It knows the `fingerprint`, and it has a
 good guess about the `address` field (though the PT may want to override
 that), but it  usually needs the PT's help to learn the `port` and any
 other fields.
 [[br]]
 I believe that all we need is in the `SMETHOD` line that Tor reads from
 the PT proxy's stdout. Our [https://gitweb.torproject.org/torspec.git/tree
 /pt-spec.txt#n544 pt-spec.txt] documents its format as:
 {{{
 SMETHOD   [options]
 }}}
 Note that `[options]` will need a bit of processing because
 [https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt#n555 it's
 currently defined] as `ARGS:[=,]+[=]`.

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

Re: [tor-bugs] #31111 [Core Tor/Tor]: negotiate one machine per index

[Tor Bug Tracker & Wiki]

#3: negotiate one machine per index
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+

Comment (by mikeperry):

 We do want to support negotiation of multiple machines on a single
 circuit. At a glance this looks ok. Are we sure we didn't make this
 mistake elsewhere in loops like this?

 Tobias: Thanks for this. Are multiple machines per circuit working ok for
 you with this patch applied?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31386 [Applications/Tor Browser]: Firefox Error

[Tor Bug Tracker & Wiki]

#31386: Firefox Error
+--
 Reporter:  boneless50  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Applications/Tor Browser
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 -OS - macOS Catalina 10.15 Beta
 -Tor - Version 8.5.4
 -Issue - Fresh install of Tor returns the attached error. Multiple
 deletions/re-installs of both Tor and Firefox produce the same result.
 Please see attached for a screenshot of the error.


 Process:   firefox [978]
 Path:  /Applications/Tor
 Browser.app/Contents/MacOS/firefox
 Identifier:org.torproject.torbrowser
 Version:   8.5.4 (6019.3.7)
 Code Type: X86-64 (Native)
 Parent Process:??? [1]
 Responsible:   firefox [978]
 User ID:   501

 Date/Time: 2019-08-09 09:57:20.409 -0400
 OS Version:Mac OS X 10.15 (19A526h)
 Report Version:12
 Bridge OS Version: 4.0 (17P50521d)
 Anonymous UUID:B34EB067-DEC1-1599-F385-F9B2AC42E061


 Time Awake Since Boot: 440 seconds

 System Integrity Protection: enabled

 Crashed Thread:0  Dispatch queue: com.apple.main-thread

 Exception Type:EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes:   EXC_I386_GPFLT
 Exception Note:EXC_CORPSE_NOTIFY

 Termination Signal:Segmentation fault: 11
 Termination Reason:Namespace SIGNAL, Code 0xb
 Terminating Process:   exc handler [978]

 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   com.apple.CoreGraphics  0x7fff32479084
 CGDataProviderGetWorkBufferSize + 26
 1   com.apple.CoreGraphics  0x7fff32317b4b
 CGSImageDataLock + 1433
 2   com.apple.CoreGraphics  0x7fff32317543
 RIPImageDataInitializeShared + 177
 3   com.apple.CoreGraphics  0x7fff32317102
 RIPImageCacheGetRetained + 731
 4   com.apple.CoreGraphics  0x7fff32316bd7
 ripc_AcquireRIPImageData + 385
 5   com.apple.CoreGraphics  0x7fff323607e4 ripc_DrawImages
 + 2860
 6   com.apple.CoreGraphics  0x7fff3235f0da
 CGContextDrawImages + 206
 7   com.apple.coreui0x7fff4aed4227
 DrawNinePartImageWithOperation + 5538
 8   com.apple.coreui0x7fff4aed2b52
 DrawNinePartElementFromRenditionWithOperation + 428
 9   com.apple.coreui0x7fff4aeb5468 -[CUIThemeFacet
 
_drawSpecificRenditionKey:rendition:inFrame:context:alpha:operation:isFocused:isFlipped:effects:]
 + 397
 10  com.apple.coreui0x7fff4aeb52cc -[CUIThemeFacet
 _drawSpecificRenditionKey:inFrame:context:isFocused:isFlipped:effects:] +
 153
 11  com.apple.coreui0x7fff4aed7f9b -[CUIThemeFacet
 drawInFrame:isFocused:context:] + 119
 12  com.apple.coreui0x7fff4aecd807
 CUICoreThemeRenderer::DrawWindowFrameStandardNew(CUIDescriptor const*) +
 3837
 13  com.apple.coreui0x7fff4aeb4105
 CUIRenderer::Draw(CGRect, CGContext*, __CFDictionary const*,
 __CFDictionary const**) + 1785
 14  com.apple.coreui0x7fff4aeb39da CUIDraw + 278
 15  com.apple.AppKit0x7fff2f209e75
 __44-[NSAppearance _drawInRect:context:options:]_block_invoke + 47
 16  com.apple.AppKit0x7fff2fbc9596
 -[NSCompositeAppearance
 _callCoreUIWithBlock:options:requireBezelTintColor:] + 389
 17  com.apple.AppKit0x7fff2f209e40 -[NSAppearance
 _drawInRect:context:options:] + 111
 18  com.apple.AppKit0x7fff2f3999ce
 _NSDrawThemeBackground + 1203
 19  com.apple.AppKit0x7fff2f39940d -[NSWindow
 _generateCompositedBackground] + 409
 20  com.apple.AppKit0x7fff2f39924e -[NSWindow
 _compositedBackground] + 46
 21  com.apple.AppKit0x7fff2f186c61 -[NSThemeFrame
 _needsVisualEffectViewBackgroundWithMaterial:blendingMode:] + 53
 22  com.apple.AppKit0x7fff2f19cffa -[NSThemeFrame
 _updateBackdropView] + 61
 23  com.apple.AppKit0x7fff2f1868c6 -[NSThemeFrame
 initWithFrame:styleMask:owner:] + 350
 24  com.apple.AppKit0x7fff2f170ff8 -[NSWindow
 _commonInitFrame:styleMask:backing:defer:] + 640
 25  com.apple.AppKit0x7fff2f170882 -[NSWindow
 _initContent:styleMask:backing:defer:contentView:] + 1193
 26  com.apple.AppKit0x7fff2f1703d3 -[NSWindow
 initWithContentRect:styleMask:backing:defer:] + 42
 27  XUL 0x00011140a1fb 0x10f60d000 +
 31445499

 Thread 1:
 0   libsystem_pth

Re: [tor-bugs] #31406 [Core Tor/Tor]: new ip-address for tor.dizum.com (auth-dir)

[Tor Bug Tracker & Wiki]

#31406: new ip-address for tor.dizum.com (auth-dir)
-+-
 Reporter:  usura|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Critical | Resolution:
 Keywords:  ip dir-auth 029-backport |  Actual Points:
  035-backport 040-backport 041-backport |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 armadev says: i think doing [a backport release] just for a new dizum ip
 address is borderline. since the old address will work for a long while
 yet (years, was alex's estimate)

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

Re: [tor-bugs] #31406 [Core Tor/Tor]: new ip-address for tor.dizum.com (auth-dir)

[Tor Bug Tracker & Wiki]

#31406: new ip-address for tor.dizum.com (auth-dir)
-+-
 Reporter:  usura|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Critical | Resolution:
 Keywords:  ip dir-auth 029-backport |  Actual Points:
  035-backport 040-backport 041-backport |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  ip dir-auth => ip dir-auth 029-backport 035-backport
 040-backport 041-backport
 * points:   => 0.2
 * type:  defect => task


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

Re: [tor-bugs] #31406 [Core Tor/Tor]: new ip-address for tor.dizum.com (auth-dir)

[Tor Bug Tracker & Wiki]

#31406: new ip-address for tor.dizum.com (auth-dir)
--+
 Reporter:  usura |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  ip dir-auth   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We can confirm that the new IP is signed by dizum's relay and authority
 keys, because the consensus contains the new IP. (All 9 authorities have
 checked the signature on dizum's descriptor and vote, which both contain
 the new IP.)

 {{{
 dir-source dizum E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 45.66.33.45
 45.66.33.45 80 443
 contact 1024R/8D56913D Alex de Joode 
 vote-digest 159D8D8D8174DE8F866A552D27A3CD809DDC062F
 …
 r dizum fqbq1v2DCDxTj0QDi7+gd1h911U GZmZtCLaPDQNxkhIFj8UcgTRAuA 2019-08-12
 15:28:40 45.66.33.45 443 80
 s Authority Fast Running Stable V2Dir Valid
 v Tor 0.4.0.5
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2 Padding=1
 w Bandwidth=20 Unmeasured=1
 p reject 1-65535
 }}}

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

Re: [tor-bugs] #31164 [Circumvention]: Set up default bridge at Karlstad University

[Tor Bug Tracker & Wiki]

#31164: Set up default bridge at Karlstad University
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges|  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by phw):

 Another thing that just came to my mind: Please set `BridgeDistribution`
 to `none` in your torrc, so your bridge isn't distributed by BridgeDB. As
 explained in #13727, this prevents users from using both your (publicly
 known) default bridge and a private bridge at the same time, which may
 help a censor discover the private bridge.

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

Re: [tor-bugs] #31164 [Circumvention]: Set up default bridge at Karlstad University

[Tor Bug Tracker & Wiki]

#31164: Set up default bridge at Karlstad University
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges|  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by phw):

 Replying to [comment:3 pulls]:
 > I got an OK to use 1 gbit of our link. Will upgrade the hardware of the
 box (lacked AESNI) this week. To use the full link, should the box run
 more than one instance of tor? Something else to keep in mind? Appreciate
 any help here.
 [[br]]
 Great news! Two tor instances sound like a good plan. Several other
 default bridge operators are doing this:
 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges

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

Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=2

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=2
---+
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.4.0.5
 Severity:  Normal | Resolution:
 Keywords:  wtf-pad, 041-must  |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  asn|Sponsor:  Sponsor2
---+
Changes (by teor):

 * keywords:  wtf-pad, 041-should => wtf-pad, 041-must
 * reviewer:   => asn


Comment:

 We must get this patch in 0.4.1. If we don't, we need a more complicated
 patch.
 asn said he would review this patch in the team meeting.

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

Re: [tor-bugs] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+--
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Replying to [comment:12 cohosh]:
 > if the client has already sent its upstream bytes, those bytes are lost
 forever and so all subsequent snowflakes will look like they are failing
 even if their connection to the bridge is fine. This is what the
 sequencing layer in #29206 is for.

 Would it be smart, while we don't have the sequencing layer in place yet,
 for Snowflake to have some keepalive or timeout feature, where it notices
 that it's sent its bytes, and things aren't looking good, and it should
 abort that connection so Tor can try a new one?

 If we can do it in a simple way, it might help people in the short term.
 And in the long term, we might still need some sort of similar "gosh that
 channel looks like it has failed" feature to know when it's time to launch
 a new 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #24818, #24852, #24853, #26567

[Tor Bug Tracker & Wiki]

Batch modification to #24818, #24852, #24853, #26567 by teor:


Comment:
Standardise keyword to tor-spec

--
Tickets URL: 

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

Re: [tor-bugs] #9316 [Circumvention/BridgeDB]: BridgeDB should export statistics

[Tor Bug Tracker & Wiki]

#9316: BridgeDB should export statistics
-+-
 Reporter:  asn  |  Owner:  phw
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics, bridgedb, prometheus,   |  Actual Points:
  anti-censorship-roadmap-september  |
Parent ID:  #31274   | Points:  3
 Reviewer:  cohosh   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by phw):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:32 cohosh]:
 > This looks good to me, I added some comments to this commit:
 
https://github.com/NullHypothesis/bridgedb/commit/d6fa8e18dd764cbc612f834338cb71c4ab322a9b
 [[br]]
 Thanks. My latest branch should include all your feedback:
 https://github.com/NullHypothesis/bridgedb/commits/fix/9316
 [[br]]
 > There were some changes that I couldn't track how they relate to the
 metrics feature, perhaps they snuck in from some other changes being made
 to bridgedb? Otherwise it looks really good!
 [[br]]
 Right, I split the branch into three commits, to make it less confusing.
 
[https://github.com/NullHypothesis/bridgedb/commit/0d5ed52e5906260e142ef9cfa12752810fd1ffa2
 0d5ed52e] fixes the broken download of Tor exit relays,
 
[https://github.com/NullHypothesis/bridgedb/commit/85a69d1be3f14a8ba0c5ba8e4840e40214217941
 85a69d1b] updates a comment, and
 
[https://github.com/NullHypothesis/bridgedb/commit/91d12652065f7912a6a8fe12bee27fc9dcaeb842
 91d12652] implements the metrics feature.
 [[br]]
 > There might be an unchecked failure case
 
[https://github.com/NullHypothesis/bridgedb/blob/d1a70dee2ca476b0819a1cb24212215e31c755d6/bridgedb/distributors/moat/server.py#L741
 here] with the moat reporting for when we don't have any bridge lines to
 return. It's not really a failure of the system though so much as a lack
 of bridges so I'm not sure how we'd want to count that.
 [[br]]
 The current metrics implementation is user-centric, meaning that requests
 are classified as "success" if the user did everything right and "fail" if
 the user did something wrong (e.g., used an email account other than Gmail
 or Riseup, or failed to solve the CAPTCHA).

 We probably also want BridgeDB-centric metrics such as "number of bridges
 per ring" and "number of requests that were answered with 0 bridges". I
 suggest that we discuss these in a separate ticket, ok?

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

Re: [tor-bugs] #31397 [Core Tor/Tor]: Appveyor: pacman.exe : error: msys: signature … is invalid

[Tor Bug Tracker & Wiki]

#31397: Appveyor: pacman.exe : error: msys: signature … is invalid
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Critical | Resolution:  fixed
 Keywords:  041-must, tor-ci-fail, ci-   |  Actual Points:
  environment, appveyor, Windows |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 It looks like this issue was resolved externally.

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

Re: [tor-bugs] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+--
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Okay I bootstrapped 100 Tor connections through snowflake and uploaded the
 bootstrap progress as an attachment to this ticket. Each bootstrap
 requests a new snowflake from the broker in the usual way. It looks like
 the majority of snowflakes are working just fine and the client can
 bootstrap to 100%. Any bootstrap above 10% and below 100% means the
 bootstrap didn't finish in 30s. This means that these connections are
 slower than usual but not necessarily buggy. Bootstraps of only 10% mean
 that the data probably never reached the bridge.

 This doesn't test the bandwidth of the proxies, it only gives us a rough
 idea of how reachable they are and it looks like for the most part the
 webextension proxies aren't failing in this way.

 Like I mentioned above though, if you are unlucky and get a bad snowflake,
 all subsequent snowflakes will fail until you make a new connection
 because of the lost data.

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

Re: [tor-bugs] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+--
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * Attachment "snowflake_health_check.pdf" added.

 100 probes of snowflake proxies

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

Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=2

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=2
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+

Comment (by teor):

 Looks good to me, but I think you probably want asn to review this patch?
 He's much more familiar with the padding code.

 Do you want me to help by writing the tor-spec update for Padding=1 and
 Padding=2 ? (#31392)

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

Re: [tor-bugs] #31392 [Core Tor/Tor]: Explain Padding 1 and 2 in tor-spec.txt

[Tor Bug Tracker & Wiki]

#31392: Explain Padding 1 and 2 in tor-spec.txt
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:  #31356   | Points:  0.1
 Reviewer:   |Sponsor:  Sponsor2
-+

Old description:

> Padding=1 is declared by some versions of tor without Padding support. We
> will eventually stop declaring support for it.
> Padding=2 is the guaranteed working version.

New description:

 Padding=1 is declared by some versions of tor without Padding support. We
 will  stop declaring support for it I once #31356 is merged into 0.4.1.
 Padding=2 is the guaranteed working version once #31356 is merged into
 0.4.1 and later.

--

Comment (by teor):

 Updated based on discussion in #31356.

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

Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=2 (was: 0.4.1 relays should list Padding=1, 2)

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=2
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+

Old description:

> Somehow we accidentally merged the protover for padding support while
> doing the incremental merge thing, and 0.4.0 relays are advertising
> padding that they don't support. This is mostly harmless, because the
> negotiation will not succeed and then clients will stop, but it will
> result in those clients emitting a "Middle node did not accept our
> padding request" protocol warn/info message.
>
> ~~We should just remove this protover field from 0.4.0.x.~~
>
> At the weekly meeting last week, we decided that we can't remove a
> protover once it's been released.
> Instead, we will:
> * make 0.4.1 and later relays declare Padding=1,2 (pre-0.4.1 stable)
> * make 0.4.1 and later clients require Padding=2 (padding is not on by
> default, so we can do this at any time)

New description:

 Somehow we accidentally merged the protover for padding support while
 doing the incremental merge thing, and 0.4.0 relays are advertising
 padding that they don't support. This is mostly harmless, because the
 negotiation will not succeed and then clients will stop, but it will
 result in those clients emitting a "Middle node did not accept our padding
 request" protocol warn/info message.

 ~~We should just remove this protover field from 0.4.0.x.~~

 At the weekly meeting last week, we decided that we can't remove a
 protover once it's been released.
 Instead, we will:
 * make 0.4.1 and later relays declare Padding=2 (pre-0.4.1 stable)
 * make 0.4.1 and later clients require Padding=2 (padding is not on by
 default, so we can do this at any time)

 Edited to simplify: we don't need to preserve compatibility with alphas.

--

Comment (by teor):

 I also edited the ticket description to match our discussion, so the
 reviewer is not confused.

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

Re: [tor-bugs] #31393 [Core Tor/Tor]: Stop declaring support for Padding=1 after 0.4.1-stable is released

[Tor Bug Tracker & Wiki]

#31393: Stop declaring support for Padding=1 after 0.4.1-stable is released
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  merge-after-041-stable, wtf-pad, |  Actual Points:
  technical-debt, 040-backport, 041-backport |
Parent ID:  #31356   | Points:  0.2
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

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


Comment:

 We don't need to preserve compatibility with alphas, so we can stop
 declaring Padding=1 immediately.

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

Re: [tor-bugs] #31387 [Core Tor/Tor]: Make 0.4.1 and later clients require Padding=2

[Tor Bug Tracker & Wiki]

#31387: Make 0.4.1 and later clients require Padding=2
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  wtf-pad, 042-should  |  Actual Points:
Parent ID:  #31356   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+
Changes (by teor):

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


Comment:

 We don't need to preserve compatibility with alphas,

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

Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=1, 2

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=1,2
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+

Comment (by teor):

 Replying to [comment:8 mikeperry]:
 > I think we should keep this simple, so that it can get in before
 0.4.1-stable, with low risk. We do not support alphas once the stable is
 released.

 You're right, that's a new policy that I hadn't quite caught up with.

 > This means that we can just bump the protover without doing all of the
 extra effort to phase out Padding=1 in stages.
 >
 > In other words: if this gets merged before 0.4.1-stable, then once
 0.4.1-stable is released, it won't matter that our older 0.4.1 alpha
 clients won't negotiate with newer 0.4.1 relays -- they are unsupported.
 Similarly, it doesn't matter if 0.4.1-stable clients won't negotiate with
 0.4.1-alpha relays -- those relays are also unsupported.

 We don't need to keep Padding=1 working in alphas, so it is much simpler
 to just bump the protover. (That's different to what we discussed in the
 meeting and in #tor-dev, but I agree with you now. We're not taking
 support away from a stable release, and no-one should be relying on the
 alpha behaviour.)

 > Here is a cleanly organized PR against 0.4.1 that passes CI and is now
 actually ready for review: https://github.com/torproject/tor/pull/1230
 >
 > FTR: I didn't call you crazy. I called this entire situation crazy
 (which I meant to include my response). I meant "crazy" in the sense that
 what we were doing did not make sense to me and made things confusing to
 others. The thing that upset me was that I am capable of viewing the CI
 logs of PRs that I'm still actively rebasing and re-organizing.. I didn't
 need those logs to occupy space in this ticket, and I didn't want them to,
 which is why I didn't ask anyone to review it or even mention the branch
 yet.. That said, I should have reacted more reasonably myself rather than
 mirroring and exaggerating what I felt were unreasonable actions, which is
 a bad habit of mine that I have been trying to break. It was the end of a
 long week.

 Thanks for this explanation. I am also trying to react less to situations
 which stress me out.

 Here's how I'd like a conversation like this to go in future:

 teor: does something unnecessary
 mikeperry: Please don't do that thing. Can I delete your comment?
 teor: Oops sorry. Of course! I will try to remember next time.

 I am going to edit my comment with the logs to reduce the space it takes
 up.

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

Re: [tor-bugs] #31356 [Core Tor/Tor]: 0.4.1 relays should list Padding=1, 2

[Tor Bug Tracker & Wiki]

#31356: 0.4.1 relays should list Padding=1,2
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.0.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-should  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  Sponsor2
-+
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 I think we should keep this simple, so that it can get in before
 0.4.1-stable, with low risk. We do not support alphas once the stable is
 released. This means that we can just bump the protover without doing all
 of the extra effort to phase out Padding=1 in stages.

 In other words: if this gets merged before 0.4.1-stable, then once
 0.4.1-stable is released, it won't matter that our older 0.4.1 alpha
 clients won't negotiate with newer 0.4.1 relays -- they are unsupported.
 Similarly, it doesn't matter if 0.4.1-stable clients won't negotiate with
 0.4.1-alpha relays -- those relays are also unsupported.

 Here is a cleanly organized PR against 0.4.1 that passes CI and is now
 actually ready for review: https://github.com/torproject/tor/pull/1230

 FTR: I didn't call you crazy. I called this entire situation crazy (which
 I meant to include my response). I meant "crazy" in the sense that what we
 were doing did not make sense to me and made things confusing to others.
 The thing that upset me was that I am capable of viewing the CI logs of
 PRs that I'm still actively rebasing and re-organizing.. I didn't need
 those logs to occupy space in this ticket, and I didn't want them to,
 which is why I didn't ask anyone to review it or even mention the branch
 yet.. That said, I should have reacted more reasonably myself rather than
 mirroring and exaggerating what I felt were unreasonable actions, which is
 a bad habit of mine that I have been trying to break. It was the end of a
 long 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] #31382 [Internal Services/Tor Sysadmin Team]: Please create email alias/forwarding and LDAP for federico (OONI)

[Tor Bug Tracker & Wiki]

#31382: Please create email alias/forwarding and LDAP for federico (OONI)
-+-
 Reporter:  ewyatt   |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 done.

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

Re: [tor-bugs] #31382 [Internal Services/Tor Sysadmin Team]: Please create email alias/forwarding and LDAP for federico (OONI)

[Tor Bug Tracker & Wiki]

#31382: Please create email alias/forwarding and LDAP for federico (OONI)
-+-
 Reporter:  ewyatt   |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  new => assigned
 * owner:  tpa => anarcat


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

Re: [tor-bugs] #31382 [Internal Services/Tor Sysadmin Team]: Please create email alias/forwarding and LDAP for federico (OONI)

[Tor Bug Tracker & Wiki]

#31382: Please create email alias/forwarding and LDAP for federico (OONI)
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Sounds good. Yes 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] #28804 [Core Tor/Tor]: Add circuit padding to padding-spec.txt and write a doc for researchers

[Tor Bug Tracker & Wiki]

#28804: Add circuit padding to padding-spec.txt and write a doc for researchers
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, tor-spec, 041-proposed, network-  |
  team-roadmap-august, scalability-roadmap   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 We should be sure to document potential shutdown sync issues of #30992 in
 a "known bugs/implementation issues" section. I bet there will be other
 things for such a section, 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] #30992 [Core Tor/Tor]: circpadding machines have shutdown sync issues (with intro circ NACKs and other cases)

[Tor Bug Tracker & Wiki]

#30992: circpadding machines have shutdown sync issues (with intro circ NACKs 
and
other cases)
--+
 Reporter:  asn   |  Owner:  mikeperry
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad 042-proposed  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 Replying to [comment:12 asn]:
 > Replying to [comment:11 mikeperry]:
 > I admit I don't understand exactly our "machine replace" ideal behavior
 and what goals we have for it. Can you please expand on the above and what
 other goals we have here?

 The machine replacement is meant to allow us to use the
 
[https://github.com/torproject/tor/blob/maint-0.4.1/src/core/or/circuitpadding.h#L149
 machine conditions] to apply different padding machines to different
 phases of circuit lifetime.

 For example, our current padding machines only deal with circuit setup. We
 may want to add future padding machines that apply to REND circuits that
 are built and have streams on them. To do this, we would specify the
 additional circuit state condition CIRCPAD_HAS_STREAMS on the machines
 that add padding to rend circuits that already have streams on them. These
 machines would not apply during the setup phase, but would apply after we
 have padded the rend and it has been joined. So our current machines would
 shut down, and these would start up.

 Another example might be something like "We only want to pad on circuits
 that have active streams on them to port 22, to try to make SSH circuits
 look more like web circuits". For these, we would implement #29083 as a
 machine condition. Then, machines could spin up and shut down on a circuit
 only while it has port 22 streams on it (which could be opened and closed
 repeatedly).

 > > I think my preference is for 2, but maybe a protover bump is cleaner
 anyway, since we already have to mess with it for #31356, and bumping it
 to 2 would avoid the need for any 0.4.0 patching.
 >
 > I agree that '2' seems like a plausible solution here. Are the
 PADDING_NEGOTIATE(D) cells extensible enough to add such a thing? Or how
 do we go about it?

 Yes. The circpad negotiation cells have version fields, so we can add
 extra fields for them that are only checked if the version value is high
 enough for them to be present.

 > Also, can you explain how the "machine counter" logic of '2' would work
 with multiple desynched START/STOP commands flying in the air like in
 comment:7 and comment:10? Would we ignore any START/STOP commands that
 don't correspond to our latest state? And how would that work for the
 issue in comment:10? Could that create more issues?

 Yes, we would ignore any commands that did not correspond to a machine
 counter for our most recent machine. This will solve the comment:7
 sequence. For the comment:10 sequence, the key implementation detail is
 that we have to update the "current machine counter" upon shutdown, so
 that after we tear our machines down, all previous in-flight stops, etc
 will still be recognized as from the previous machine.

 A related question is if we should treat these cells as "dropped" cells
 for side channel defenses like vanguards... I think the right answer here
 is to still retain the hop number of the previous machine, as well, so we
 can verify that these invalid commands are not injected from say, the exit
 node as a side channel vector.

 Anyway, that is my current thinking.. The side channel piece of this might
 be solved with another approach, though..

 All of this complication is why it's smartest just to let this be for now,
 especially since fixing it for 0.4.1 won't change any of the
 fingerprintability of these circuits..

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

Re: [tor-bugs] #30942 [Core Tor/Tor]: [warn] Unexpected INTRODUCE_ACK on circuit 3944288021.

[Tor Bug Tracker & Wiki]

#30942: [warn] Unexpected INTRODUCE_ACK on circuit 3944288021.
+--
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-padding, 041-backport?  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  dgoulet |Sponsor:
+--

Comment (by mikeperry):

 Here is a single commit master branch patch:
 https://github.com/torproject/tor/pull/1231

 I don't think we need to backport either the warn, or the comment, so I
 closed the earlier 0.4.1 PR. Much simpler this way.

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

Re: [tor-bugs] #31406 [Core Tor/Tor]: new ip-address for tor.dizum.com (auth-dir)

[Tor Bug Tracker & Wiki]

#31406: new ip-address for tor.dizum.com (auth-dir)
--+
 Reporter:  usura |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  ip dir-auth   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * priority:  Very High => High
 * milestone:   => Tor: 0.4.2.x-final


Old description:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Guys,
>
> tor.dizum.com has changed it's IP address. As tor.dizum.com is a
> directory server, it's ip address is hardcoded in the source code.
>
> Please update the ip.
>
> OLD: 194.109.206.212
> NEW: 45.66.33.45
>
> You can verify and validate this change by either
> 1) retrieving the ip for tor.dizum.com.
> 2) contact alex, by email or by phone or on irc to verify this change.
> 3) you could read the announcement at the dir-auth list.
>
> -BEGIN PGP SIGNATURE-
> Version: BCPG v1.47
>
> iGYEARECACYFAl1RuckfHEFsZXggZGUgSm9vZGUgPGFsZXhAaWRnYXJhLm5sPgAK
> CRB4AD5zEX0r0DQsAJwN+/zRHTRgIiiXps8Lw0NieQgFpACgoz/YHdlt/X2YMQQL
> bpY/OwGavRE=
> =SFAn
> -END PGP SIGNATURE-

New description:

 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Guys,

 tor.dizum.com has changed it's IP address. As tor.dizum.com is a directory
 server, it's ip address is hardcoded in the source code.

 Please update the ip.

 OLD: 194.109.206.212
 NEW: 45.66.33.45

 You can verify and validate this change by either
 1) retrieving the ip for tor.dizum.com.
 2) contact alex, by email or by phone or on irc to verify this change.
 3) you could read the announcement at the dir-auth list.

 -BEGIN PGP SIGNATURE-
 Version: BCPG v1.47

 iGYEARECACYFAl1RuckfHEFsZXggZGUgSm9vZGUgPGFsZXhAaWRnYXJhLm5sPgAK
 CRB4AD5zEX0r0DQsAJwN+/zRHTRgIiiXps8Lw0NieQgFpACgoz/YHdlt/X2YMQQL
 bpY/OwGavRE=
 =SFAn
 -END PGP SIGNATURE-
 }}}

--

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

Re: [tor-bugs] #30992 [Core Tor/Tor]: circpadding machines have shutdown sync issues (with intro circ NACKs and other cases) (was: circpadding: Circsetup machines give out warnings when client-side in

[Tor Bug Tracker & Wiki]

#30992: circpadding machines have shutdown sync issues (with intro circ NACKs 
and
other cases)
--+
 Reporter:  asn   |  Owner:  mikeperry
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad 042-proposed  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * keywords:  wtf-pad circpad 041-should => wtf-pad circpad 042-proposed
 * points:  0.4 => 3
 * milestone:  Tor: 0.4.1.x-final => Tor: unspecified


Comment:

 I am taking this out of 0.4.1 because none of the above cases are
 catastrophic, and fixing them with a sequence number fix will still have
 cell count issues that cause these circuits to be uniquely recognizable
 (due to the extra padding negotiation *and* cannibalization onionskin
 cells each time there is a purpose change due to a NACK). We need both the
 sequence number fix and padding machine changes to make these cannibalized
 NACKed intro circuits not stand out. :/

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

Re: [tor-bugs] #31406 [Core Tor/Tor]: new ip-address for tor.dizum.com (auth-dir)

[Tor Bug Tracker & Wiki]

#31406: new ip-address for tor.dizum.com (auth-dir)
--+
 Reporter:  usura |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  ip dir-auth   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by usura):

 * Attachment "tor-sig.txt" added.

 pgp signed text

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31406 [Core Tor/Tor]: new ip-address for tor.dizum.com (auth-dir)

[Tor Bug Tracker & Wiki]

#31406: new ip-address for tor.dizum.com (auth-dir)
-+--
 Reporter:  usura|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Component:  Core Tor/Tor
  Version:   |   Severity:  Critical
 Keywords:  ip dir-auth  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Guys,

 tor.dizum.com has changed it's IP address. As tor.dizum.com is a directory
 server, it's ip address is hardcoded in the source code.

 Please update the ip.

 OLD: 194.109.206.212
 NEW: 45.66.33.45

 You can verify and validate this change by either
 1) retrieving the ip for tor.dizum.com.
 2) contact alex, by email or by phone or on irc to verify this change.
 3) you could read the announcement at the dir-auth list.

 -BEGIN PGP SIGNATURE-
 Version: BCPG v1.47

 iGYEARECACYFAl1RuckfHEFsZXggZGUgSm9vZGUgPGFsZXhAaWRnYXJhLm5sPgAK
 CRB4AD5zEX0r0DQsAJwN+/zRHTRgIiiXps8Lw0NieQgFpACgoz/YHdlt/X2YMQQL
 bpY/OwGavRE=
 =SFAn
 -END PGP SIGNATURE-

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

Re: [tor-bugs] #31200 [Circumvention/Snowflake]: Hand out proxy-go snowflakes more frequently than webextension snowflakes

[Tor Bug Tracker & Wiki]

#31200: Hand out proxy-go snowflakes more frequently than webextension 
snowflakes
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25681   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+-
Changes (by arlolra):

 * status:  needs_review => merge_ready


Comment:

 Sure

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

Re: [tor-bugs] #31159 [Internal Services/Tor Sysadmin Team]: Monitor anti-censorship www services with prometheus

[Tor Bug Tracker & Wiki]

#31159: Monitor anti-censorship www services with prometheus
-+-
 Reporter:  phw  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30152   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by phw):

 Replying to [comment:1 hiro]:
 > There is also another aspect to consider, in the case of a service like
 gettor, monitoring the https endpoint will only give us some info about
 the static html we are serving with apache. Gettor itself (the service
 sending emails) is a twisted service instead.
 [[br]]
 Gotcha. We have a similar problem with BridgeDB because it is exposed over
 an Apache reverse proxy and you cannot directly talk to BridgeDB.
 However, if BridgeDB is down, bridges.torproject.org responds with an
 internal server error if I remember correctly, so we can still monitor
 BridgeDB despite the reverse proxy, right?

 To monitor BridgeDB, we need to set up an exporter, right?
 [[br]]
 > Maybe we can consider an approach in which services expose an http
 endpoint that we can use to know that the service is alive. Otherwise I
 think we could do some other monitoring via nagios checks.
 [[br]]
 I think we already have that for BridgeDB and snowflake's website but not
 for GetTor.

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

Re: [tor-bugs] #31293 [Applications/Tor Browser]: tor-android-service gradle failure when probing network interfaces

[Tor Bug Tracker & Wiki]

#31293: tor-android-service gradle failure when probing network interfaces
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sisbell):

 May be caused by this issue: #25623 . Try enabling network and see if it
 fixes 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] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, tor-hs,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by neel):

 * 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] #13194 [Core Tor/Tor]: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell

[Tor Bug Tracker & Wiki]

#13194: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-hs, needs-design  |  Actual Points:
  privcount-maybe metrics performance|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by neel):

 * status:  assigned => new


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

Re: [tor-bugs] #13194 [Core Tor/Tor]: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell

[Tor Bug Tracker & Wiki]

#13194: Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-hs, needs-design  |  Actual Points:
  privcount-maybe metrics performance|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by neel):

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


Comment:

 Removing myself from assigned.

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

Re: [tor-bugs] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+--
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 After more tests, it looks like the client version has nothing to do with
 it.

 Most of my connections (including ones through webextension snowflakes)
 seem to be doing fine. A few are failing in one of two ways:
 1. the proxy fails to answer in time
 2. the proxy answers and the datachannel is opened but the client never
 gets downstream bytes

 Unfortunately for case 2, if the client has already sent its upstream
 bytes, those bytes are lost forever and so all subsequent snowflakes will
 look like they are failing even if their connection to the bridge is fine.
 This is what the sequencing layer in #29206 is for. #29206 will also help
 alleviate some these symptoms by allowing the 30s timeout window to be
 lessened so that snowflakes can be gathered more quickly (#25429).

 I'm currently running the snowflake reachability tests from #30368 to try
 to get a sense of how many snowflakes are unreliable and I'll post back
 here with more info.

 I'll also try to have a look at what's going on with case 1 and how often
 that's happening.

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

Re: [tor-bugs] #31293 [Applications/Tor Browser]: tor-android-service gradle failure when probing network interfaces

[Tor Bug Tracker & Wiki]

#31293: tor-android-service gradle failure when probing network interfaces
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sisbell):

 The build failure occurs with gradle 4.1. With Gradle 4.10 (which we are
 using for esr68) gradle assigns a default 127.0.0.1 value if it is unable
 to query the interface. So it doesn't thrown an NPE and moves along
 happily.

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

Re: [tor-bugs] #31405 [Community/Mirrors]: Download links of Tor mirrors should not point to torproject.org domain

[Tor Bug Tracker & Wiki]

#31405: Download links of Tor mirrors should not point to torproject.org domain
---+--
 Reporter:  anadahz|  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Mirrors  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by ggus):

 * status:  new => assigned
 * owner:  ggus => hiro


Comment:

 Since Lektor migration, we're hardcoding an url ".torproject.org" to
 download. This macro must be rewritten in order to download from mirrors:

 
https://gitweb.torproject.org/project/web/tpo.git/tree/templates/macros/downloads.html

 {{{
 {% macro render_windows(version, alt) %}
   {% set download_prefix = 'https://www.torproject.org/dist/torbrowser/' +
 version + '/' %}
   {% if alt == 'en' %}
 {% set alt = 'en-US' %}
   {% elif alt == 'es' %}
 {% set alt = 'es-ES' %}
   {% endif %}
   {% set download_link_64 = download_prefix + 'torbrowser-install-win64-'
 + version + '_' + alt + '.exe' %}
   {% set download_link_32 = download_prefix + 'torbrowser-install-' +
 version + '_' + alt + '.exe' %}
   {% set sig_link_64 = download_link_64 + '.asc' %}
   {% set sig_link_32 = download_link_32 + '.asc' %}

 }}}

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

Re: [tor-bugs] #31200 [Circumvention/Snowflake]: Hand out proxy-go snowflakes more frequently than webextension snowflakes

[Tor Bug Tracker & Wiki]

#31200: Hand out proxy-go snowflakes more frequently than webextension 
snowflakes
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25681   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--
Changes (by cohosh):

 * status:  assigned => needs_review


Comment:

 https://github.com/cohosh/snowflake/compare/ticket31200

 This raises it from every 5 seconds to every 20 seconds.

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

Re: [tor-bugs] #31200 [Circumvention/Snowflake]: Hand out proxy-go snowflakes more frequently than webextension snowflakes

[Tor Bug Tracker & Wiki]

#31200: Hand out proxy-go snowflakes more frequently than webextension 
snowflakes
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25681   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---
Changes (by cohosh):

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


Comment:

 Working on this now to alleviate some reported quality issues with
 snowflake connections (#31385). The feature suggested in #25598 sounds
 great, but for now I want to just temporarily increase the polling period
 for the webextension proxies.

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

Re: [tor-bugs] #31405 [Community/Mirrors]: Download links of Tor mirrors should not point to torproject.org domain

[Tor Bug Tracker & Wiki]

#31405: Download links of Tor mirrors should not point to torproject.org domain
---+--
 Reporter:  anadahz|  Owner:  ggus
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Mirrors  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by antonela):

 * owner:  hiro => ggus
 * cc: traumschule, trac-dip-importer (removed)
 * component:  Webpages/Website => Community/Mirrors


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31405 [Webpages/Website]: Download links of Tor mirrors should not point to torproject.org domain

[Tor Bug Tracker & Wiki]

#31405: Download links of Tor mirrors should not point to torproject.org domain
--+--
 Reporter:  anadahz   |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The download links from mirrors should not point to torproject.org domain
 but instead to the original mirror server.

 Example mirror URL: https://mirror.oldsql.cc/tor/download/
 * **Provides** Tor Browser download URL:
 https://www.torproject.org/dist/torbrowser/8.5.4/torbrowser-install-
 win64-8.5.4_en-US.exe
 * **Should provide** the following Tor Browser download URL:
 https://mirror.oldsql.cc/tor/dist/torbrowser/8.5.4/torbrowser-install-
 win64-8.5.4_en-US.exe

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

Re: [tor-bugs] #31366 [Core Tor/Tor]: Move the connection_edge_process_relay_cell() assignment out of the if statement in circuit_receive_relay_cell()

[Tor Bug Tracker & Wiki]

#31366: Move the connection_edge_process_relay_cell() assignment out of the if
statement in circuit_receive_relay_cell()
--+
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  technical-debt, fast-fix  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #31353 [Core Tor/Tor]: Jenkins failure on windows: Overflow in implicit constant conversion

[Tor Bug Tracker & Wiki]

#31353: Jenkins failure on windows: Overflow in implicit constant conversion
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  compilation   |  Actual Points:  0.1
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #31352 [Core Tor/Tor]: Jenkins failure on windows: ENETUNREACH undeclared.

[Tor Bug Tracker & Wiki]

#31352: Jenkins failure on windows: ENETUNREACH undeclared.
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  regression windows  |  Actual Points:  0.1
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #31240 [Core Tor/Tor]: Make confparse able to handle multiple config_format_t objects at once

[Tor Bug Tracker & Wiki]

#31240: Make confparse able to handle multiple config_format_t objects at once
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:  3
Parent ID:  #29211   | Points:  3
 Reviewer:  teor |Sponsor:  Sponsor31-can
-+-
Changes (by asn):

 * reviewer:   => teor


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

Re: [tor-bugs] #31314 [Core Tor/Tor]: Modify git-merge-forward.sh so it can create test merge branches

[Tor Bug Tracker & Wiki]

#31314: Modify git-merge-forward.sh so it can create test merge branches
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  git-scripts, network-team-roadmap-   |  Actual Points:  0.8
  october|
Parent ID:  #31178   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor31-must
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #31175 [Core Tor/Tor]: Teach practracker to apply separate rules for C headers

[Tor Bug Tracker & Wiki]

#31175: Teach practracker to apply separate rules for C headers
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:  .1
Parent ID:  #29746   | Points:  1
 Reviewer:  asn  |Sponsor:  Sponsor31-can
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #29879 [Core Tor/Tor]: Make git-push-all.sh push branches in a specific order

[Tor Bug Tracker & Wiki]

#29879: Make git-push-all.sh push branches in a specific order
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, git-scripts, fast-fix,   |  Actual Points:  0.2
  041-deferred-20190530  |
Parent ID:   | Points:  0.1
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor31-can
-+-
Changes (by asn):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #30979 [Core Tor/Tor]: pre-push hook runs practracker unconditionally

[Tor Bug Tracker & Wiki]

#30979: pre-push hook runs practracker unconditionally
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:  0
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #31176 [Core Tor/Tor]: Teach practracker about .may_include files

[Tor Bug Tracker & Wiki]

#31176: Teach practracker about .may_include files
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  practracker, tech-debt,  |  Actual Points:  1
  refactoring, easy, 041-deferred-20190530,  |
  network-team-roadmap-august|
Parent ID:  #29746   | Points:  1.5
 Reviewer:  teor |Sponsor:
 |  Sponsor31-can
-+-
Changes (by asn):

 * reviewer:   => teor


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

Re: [tor-bugs] #27514 [Community/Tor Support]: Add instructions how to verify signatures on Android

[Tor Bug Tracker & Wiki]

#27514: Add instructions how to verify signatures on Android
---+-
 Reporter:  traumschule|  Owner:  traumschule
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docshackathon  |  Actual Points:
Parent ID:  #30259 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by ggus):

 * keywords:   => docshackathon


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

Re: [tor-bugs] #17735 [Community/Training]: Create a public repository of training/outreach material

[Tor Bug Tracker & Wiki]

#17735: Create a public repository of training/outreach material
+
 Reporter:  dgoulet |  Owner:  Kelley
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Community/Training  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by ggus):

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


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

Re: [tor-bugs] #27514 [Community/Tor Support]: Add instructions how to verify signatures on Android

[Tor Bug Tracker & Wiki]

#27514: Add instructions how to verify signatures on Android
---+-
 Reporter:  traumschule|  Owner:  traumschule
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #30259 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by ggus):

 Moving this to: https://dip.torproject.org/web/support/issues/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] #28154 [Community/Tor Support]: What do the different onions mean on the address bar?

[Tor Bug Tracker & Wiki]

#28154: What do the different onions mean on the address bar?
---+---
 Reporter:  emmapeel   |  Owner:  gus
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords:  docshackathon  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by ggus):

 * keywords:   => docshackathon
 * status:  assigned => closed
 * resolution:   => duplicate


Comment:

 Moved to: https://dip.torproject.org/web/support/issues/9

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

Re: [tor-bugs] #30083 [Community/Tor Support]: support portal: replace duplicated support questions for symlinks

[Tor Bug Tracker & Wiki]

#30083: support portal: replace duplicated support questions for symlinks
---+---
 Reporter:  emmapeel   |  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords:  docshackathon  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by ggus):

 * keywords:   => docshackathon
 * status:  assigned => closed
 * resolution:   => duplicate


Comment:

 Moving this ticket to: https://dip.torproject.org/web/support/issues/8

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

Re: [tor-bugs] #30690 [Community/Outreach]: Please include licensing information in outreach materials

[Tor Bug Tracker & Wiki]

#30690: Please include licensing information in outreach materials
+--
 Reporter:  gwolf   |  Owner:  antonela
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  docshackathon   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by antonela):

 * owner:  alison => antonela
 * status:  new => assigned
 * keywords:   => docshackathon


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

Re: [tor-bugs] #28475 [Community/Tor Support]: Update support portal on Tor Browser for Android

[Tor Bug Tracker & Wiki]

#28475: Update support portal on Tor Browser for Android
---+---
 Reporter:  emmapeel   |  Owner:  phoul
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords:  docshackathon  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by ggus):

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


Comment:

 Moved this ticket to: https://dip.torproject.org/web/support/issues/7

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

Re: [tor-bugs] #31404 [Applications/Tor Browser]: Unsolvable reCAPTCHAs

[Tor Bug Tracker & Wiki]

#31404: Unsolvable reCAPTCHAs
--+--
 Reporter:  antonela  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by anadahz):

 I can always reproduce this.

 Tor Browser version: `8.5.4`
 Firefox version: `68.0.1`

 Website to reproduce it (or try to subscribe on any mailing list listed in
 Sourceforge): https://sourceforge.net/projects/qbittorrent/lists
 /qbittorrent-devel

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

Re: [tor-bugs] #31140 [Applications/Tor Browser]: Tor Browser for Android 60.8.0 crash on aarch64

[Tor Bug Tracker & Wiki]

#31140: Tor Browser for Android 60.8.0 crash on aarch64
-+-
 Reporter:  j3tracey |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  TorBrowserTeam201907   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:15 sysrqb]:
 > Maybe: https://bugzilla.mozilla.org/show_bug.cgi?id=1455709

 This is looking positive. Debug build fully bootstraps and the browser
 works. Now building a release build and will test 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] #29918 [Community/Tor Support]: add Trademark FAQ to the support portal

[Tor Bug Tracker & Wiki]

#29918: add Trademark FAQ to the support portal
-+-
 Reporter:  emmapeel |  Owner:  phoul
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Community/Tor Support|Version:
 Severity:  Normal   | Resolution:
 Keywords:  faq, documentation, support portal,  |  duplicate
  docs, trademark, docshackathon |  Actual Points:
Parent ID:  #28549   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ggus):

 * cc: alison (removed)
 * keywords:  faq, documentation, support portal, docs, trademark => faq,
 documentation, support portal, docs, trademark, docshackathon
 * status:  new => closed
 * resolution:   => duplicate


Comment:

 All institutional documentation (financial reports, press, trademark)
 should go to main portal:

 https://dip.torproject.org/web/tpo/issues/25

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31404 [Applications/Tor Browser]: Unsolvable reCAPTCHAs

[Tor Bug Tracker & Wiki]

#31404: Unsolvable reCAPTCHAs
--+--
 Reporter:  antonela  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 anadahz in #tor

 Lately (and more often than before), I have a tremendous difficulty to
 pass any Google CAPTCHAs. I tested a version of Firefox on a torified VM
 to observe if this related to Tor or to the Tor Browser and it seems to be
 the latter, as I can pass Google CAPTCHAs even with the first try. To
 further to test this I used all different variations of Tor Browser's
 security levels and NoScript privileges, I even disabled NoScript but
 still CAPTCHAs were unsolvable or required a decent amount of tries.
 Anyone else experienced similar behavior?

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

Re: [tor-bugs] #28776 [Community/Tor Support]: support: explain *why* it is not good to install new add-ons at https://support.torproject.org/tbb/tbb-14/

[Tor Bug Tracker & Wiki]

#28776: support: explain *why* it is not good to install new add-ons at
https://support.torproject.org/tbb/tbb-14/
-+-
 Reporter:  emmapeel |  Owner:  phoul
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Community/Tor Support|Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation, support,  |  duplicate
  fingerprint, add-on, docshackathon |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ggus):

 * status:  assigned => closed
 * keywords:  documentation, support, fingerprint, add-on => documentation,
 support, fingerprint, add-on, docshackathon
 * resolution:   => duplicate


Comment:

 https://dip.torproject.org/web/support/issues/6

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

Re: [tor-bugs] #27285 [Community/Tor Support]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server.

[Tor Bug Tracker & Wiki]

#27285: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory
server.
---+--
 Reporter:  Miyukii|  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  user disappeared
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by ggus):

 * status:  new => closed
 * resolution:   => user disappeared


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

Re: [tor-bugs] #30923 [Community]: Create irc help entry in support.torproject.org

[Tor Bug Tracker & Wiki]

#30923: Create irc help entry in support.torproject.org
---+---
 Reporter:  antonela   |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords:  docshackathon  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by ggus):

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


Comment:

 Ticket moved to: https://dip.torproject.org/web/support/issues/5

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

Re: [tor-bugs] #30923 [Community]: Create irc help entry in support.torproject.org

[Tor Bug Tracker & Wiki]

#30923: Create irc help entry in support.torproject.org
---+--
 Reporter:  antonela   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docshackathon  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by ggus):

 * keywords:   => docshackathon
 * cc: alison (removed)


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

Re: [tor-bugs] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+--
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 I was able to reproduce this after updating Tor Browser. The client worked
 fine before the update:

 {{{
 2019/08/12 15:25:00 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/08/12 15:25:01 Traffic Bytes (in|out): 543 | 543 -- (1 OnMessages, 1
 Sends)
 2019/08/12 15:25:07 Traffic Bytes (in|out): 1086 | 1086 -- (2 OnMessages,
 2 Sends)
 2019/08/12 15:25:10 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/08/12 15:25:12 Traffic Bytes (in|out): 543 | 1600 -- (1 OnMessages, 2
 Sends)
 2019/08/12 15:25:18 Traffic Bytes (in|out): 1086 | 1086 -- (2 OnMessages,
 2 Sends)
 2019/08/12 15:25:18 WebRTC: closing DataChannel
 2019/08/12 15:25:18 ConnectLoop: stopped.
 2019/08/12 15:25:18 copy loop ended
 2019/08/12 15:25:18  Handler: closed ---
 2019/08/12 15:25:18 WebRTC: DataChannel.OnClose [locally]
 2019/08/12 15:25:18 WebRTC: closing PeerConnection
 2019/08/12 15:25:18 WebRTC: Closing
 2019/08/12 15:25:18 WebRTC: melted all 1 snowflakes.
 2019/08/12 15:25:18 SOCKS listening...
 2019/08/12 15:25:18 snowflake is done.
 }}}

 But afterwards, I got repeated behaviour where data is going out but no
 data is coming back in:
 {{{
 2019/08/12 [scrubbed] Received Answer.
 2019/08/12 [scrubbed] WebRTC: DataChannel.OnOpen
 2019/08/12 [scrubbed] Buffered 1057 bytes --> WebRTC
 2019/08/12 [scrubbed] Traffic Bytes (in|out): 0 | 1057 -- (0 OnMessages, 1
 Sends)
 2019/08/12 [scrubbed] Buffered 543 bytes --> WebRTC
 2019/08/12 [scrubbed] Traffic Bytes (in|out): 0 | 543 -- (0 OnMessages, 1
 Sends)
 2019/08/12 [scrubbed] Buffered 543 bytes --> WebRTC
 2019/08/12 [scrubbed] WebRTC: No messages received for 30 seconds --
 closing stale connection.
 2019/08/12 [scrubbed] WebRTC: closing DataChannel
 2019/08/12 [scrubbed] WebRTC: DataChannel.OnClose [locally]
 2019/08/12 [scrubbed] WebRTC: closing PeerConnection
 2019/08/12 [scrubbed] WebRTC: Closing
 2019/08/12 [scrubbed] Traffic Bytes (in|out): 0 | 543 -- (0 OnMessages, 1
 Sends)
 2019/08/12 [scrubbed] Buffered 543 bytes --> WebRTC
 2019/08/12 [scrubbed] Traffic Bytes (in|out): 0 | 543 -- (0 OnMessages, 1
 Sends)
 2019/08/12 [scrubbed] Buffered 543 bytes --> WebRTC
 2019/08/12 [scrubbed] Traffic Bytes (in|out): 0 | 543 -- (0 OnMessages, 1
 Sends)
 2019/08/12 [scrubbed] Buffered 543 bytes --> WebRTC
 2019/08/12 [scrubbed] Traffic Bytes (in|out): 0 | 543 -- (0 OnMessages, 1
 Sends)
 2019/08/12 [scrubbed] Buffered 1571 bytes --> WebRTC
 }}}

 This could be either a bug at the client or just by chance that the pre-
 update version got a good proxy.

 I also just made #31403 because our over-zealous log scrubber fix and the
 guards against large reads haven't made their way into Tor Browser 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

[tor-bugs] #31403 [Applications/Tor Browser]: Bump snowflake to cd650fa009

[Tor Bug Tracker & Wiki]

#31403: Bump snowflake to cd650fa009
--+---
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  snowflake
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Looks like we don't have the over-zealous log scrubber fix deployed for
 the client yet. Just bumping this to the most recent client fixes.

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

Re: [tor-bugs] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 The patch looks good to me, also tested in 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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--

Comment (by antonela):

 Thanks for the review folks!

 - Agreed about to keep the same strings so we can rely on our translation
 memory. Although, we could have a brief description for bridges and add
 the helper text at the learn more link which will go to the tor
 manual/support.tpo entry.

 - I think is better to have a different/specific section than General for
 Network Settings. Since we are Tor Browser, `Tor Network Settings` is a
 good name. Should we use the onion icon to refer to the Tor Network as
 well? or do we prefer a different icon? Currently,
 [https://design.firefox.com/icons/viewer/#, Firefox Icons] don't have a
 Network one.

 - If we keep Firefox's Network Settings in General Preferences, do we
 still need local proxy settings in `Tor Network Settings`?

 Based on your feedback, I made some mockups to visualize these settings:

 [A] shows an initial state without inline settings.

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/31286/A-about%3Apreferences%23network.png, 700px)]]

 [B] shows an initial state with inline settings disabled.

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/31286/B-about%3Apreferences%23network.png, 700px)]]

 [C] shows Tor Network Settings with Bridges selected. Should we open MOAT
 in an overlay? Should we have inline settings for `Provide a bridge I
 know`?

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/31286/C-about%3Apreferences%23network.png, 700px)]]

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

Re: [tor-bugs] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--
Changes (by antonela):

 * Attachment "B-about:preferences#network.png" 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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--
Changes (by antonela):

 * Attachment "C-about:preferences#network.png" 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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--
Changes (by antonela):

 * Attachment "B-about:preferences#network.png" 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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
+--
 Reporter:  gk  |  Owner:  pospeselr
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908, ff68-esr  |  Actual Points:
Parent ID:  #10760  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--
Changes (by antonela):

 * Attachment "A-about:preferences#network.png" 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] #29461 [Metrics/CollecTor]: Add a Snowflake module

[Tor Bug Tracker & Wiki]

#29461: Add a Snowflake module
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-august, anti-|  Actual Points:
  censorship-roadmap-september   |
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
 |  Sponsor28
-+-

Comment (by cohosh):

 Replying to [comment:5 karsten]:
 > Where would I find the spec? I found
 [https://github.com/cohosh/snowflake/pull/3/files#diff-
 c8ef7ba143d251e41b143b2ab02f3733 this comment] which is fine for me to
 start write some metrics-lib code. But we'll have to link to something
 more permanent once we start collecting these statistics; ideally tor-
 spec.git. Thanks!

 I'll work on adding it to tor-spec.git. Right now the source code is the
 ground truth on the spec.

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

Re: [tor-bugs] #31140 [Applications/Tor Browser]: Tor Browser for Android 60.8.0 crash on aarch64

[Tor Bug Tracker & Wiki]

#31140: Tor Browser for Android 60.8.0 crash on aarch64
-+-
 Reporter:  j3tracey |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  TorBrowserTeam201907   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 `08-12 12:59:25.396 12092 12125 I Gecko   : console.log: "Setting
 intl.accept_languages to en-us,en"`
 bug

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

Re: [tor-bugs] #31232 [Internal Services/Tor Sysadmin Team]: Migrate default snowflake broker (and bridge?) to TPA machines

[Tor Bug Tracker & Wiki]

#31232: Migrate default snowflake broker (and bridge?) to TPA machines
-+-
 Reporter:  cohosh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cohosh):

 Replying to [comment:9 anarcat]:
 > > Yes, let's go ahead on this. Can we get a snowflake-
 broker.torproject.net domain and a snowflake.torproject.net domain for the
 broker and bridge, respectively?
 >
 > Sure, where do you want those to point at?
 {{{
 $ host snowflake-broker.bamsoftware.com
 snowflake-broker.bamsoftware.com has address 37.218.240.96
 $ host snowflake.bamsoftware.com
 snowflake.bamsoftware.com has address 37.218.242.151
 snowflake.bamsoftware.com has IPv6 address
 2a00:c6c0:0:151:4:8f94:69f5:7c01
 }}}

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

Re: [tor-bugs] #31232 [Internal Services/Tor Sysadmin Team]: Migrate default snowflake broker (and bridge?) to TPA machines

[Tor Bug Tracker & Wiki]

#31232: Migrate default snowflake broker (and bridge?) to TPA machines
-+-
 Reporter:  cohosh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 > Yes, let's go ahead on this. Can we get a snowflake-
 broker.torproject.net domain and a snowflake.torproject.net domain for the
 broker and bridge, respectively?

 Sure, where do you want those to point at?

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

Re: [tor-bugs] #31232 [Internal Services/Tor Sysadmin Team]: Migrate default snowflake broker (and bridge?) to TPA machines

[Tor Bug Tracker & Wiki]

#31232: Migrate default snowflake broker (and bridge?) to TPA machines
-+-
 Reporter:  cohosh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cohosh):

 Replying to [comment:7 anarcat]:
 > would it be possible to split the snowflake architecture in two parts,
 the same way bridgedb and bridges authority are separate, and would that
 help us here?
 >
 That would be difficult to do with the way snowflake currently works. It
 won't happen in the near future and it seems unlikely overall.
 > also: i'm not sure what the next step is, but if you need a
 torproject.net domain, just let me know. :)
 Yes, let's go ahead on this. Can we get a snowflake-broker.torproject.net
 domain and a snowflake.torproject.net domain for the broker and bridge,
 respectively?

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

Re: [tor-bugs] #31140 [Applications/Tor Browser]: Tor Browser for Android 60.8.0 crash on aarch64

[Tor Bug Tracker & Wiki]

#31140: Tor Browser for Android 60.8.0 crash on aarch64
-+-
 Reporter:  j3tracey |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  TorBrowserTeam201907   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Excitingly, the debug build does crash, but it crashes at a different
 (later) location with an assert. I suspect this is a different bug, and
 it's fixed upstream. I'll test it anyway (because "crashing later" may
 simply be a result of the debug build being slower).

 {{{
 08-12 12:57:52.640 12092 12125 I Gecko   : Destroying context 0x7cfd98a980
 surface 0x7ce5cb5e00 on display 0x1
 08-12 12:57:53.703 12092 12125 I nsScreenManagerAndroid:
 nsScreenManagerAndroid: add PRIMARY screen
 08-12 12:58:03.645 12092 12125 I nsScreenManagerAndroid:
 nsWindow[0x7ced782c00]::Create 0x0 [0 0 100 100]
 08-12 12:58:03.647 12092 12125 I Gecko   : ++DOCSHELL 0x7cf13a9800 == 1
 [pid = 12092] [id = {46a6ea06-6df3-4c4f-b59e-75a2624084cd}]
 08-12 12:58:03.684 12092 12125 I Gecko   : ++DOMWINDOW == 1 (0x7cef287800)
 [pid = 12092] [serial = 1] [outer = 0x0]
 08-12 12:58:04.065 12092 12125 I Gecko   : ++DOMWINDOW == 2 (0x7cef288400)
 [pid = 12092] [serial = 2] [outer = 0x7cef287800]
 08-12 12:58:18.425 12092 12125 I nsScreenManagerAndroid:
 nsWindow[0x7cef28fc00]::Create 0x0 [0 0 1 1]
 08-12 12:58:18.426 12092 12125 I Gecko   : ++DOCSHELL 0x7ceeba0800 == 2
 [pid = 12092] [id = {5821e818-d8b1-4cdd-99cc-4d1ac4d56b2b}]
 08-12 12:58:18.427 12092 12125 I Gecko   : ++DOMWINDOW == 3 (0x7cef29)
 [pid = 12092] [serial = 3] [outer = 0x0]
 08-12 12:58:18.517 12092 12125 I Gecko   : ++DOMWINDOW == 4 (0x7cef290800)
 [pid = 12092] [serial = 4] [outer = 0x7cef29]
 08-12 12:58:22.385 12092 12125 I Gecko   : ++DOMWINDOW == 5 (0x7cee85d000)
 [pid = 12092] [serial = 5] [outer = 0x7cef287800]
 08-12 12:58:24.172 12092 12125 I Gecko   : [12092, Main Thread] WARNING:
 Attempting to get a displayport from a content with no primary frame!:
 file /home/android/tor-browser/layout/base/nsLayoutUtils.cpp, line 927
 08-12 12:58:24.237 12092 12125 I nsScreenManagerAndroid:
 nsWindow[0x7cef28fc00]::Resize [0.00 63.00 1080.00
 1731.00] (repaint 0)
 08-12 12:58:24.237 12092 12125 I nsScreenManagerAndroid: nsWindow:
 0x7cef28fc00 OnSizeChanged [1080 1731]
 08-12 12:58:25.315 12092 12125 I nsScreenManagerAndroid:
 nsWindow[0x7cef28fc00]::Resize [0.00 63.00 1080.00
 1731.00] (repaint 0)
 08-12 12:58:26.563 12092 12125 W ResourceType: Too many attribute
 references, stopped at: 0x01010099
 08-12 12:59:01.886 12092 12125 D GeckoThread: State changed to RUNNING
 08-12 12:59:02.036 12092 12125 I GeckoSession: zerdatime 66406478 - chrome
 startup finished
 08-12 12:59:13.836 12092 12125 I Gecko   : console.log: "browser.js:
 loading Firefox Accounts WebChannel"
 08-12 12:59:16.341 12092 12125 D GeckoFxAccounts: FxAccountsWebChannel
 registered: account_updates with origin https://accounts.firefox.com
 08-12 12:59:18.813 12092 12092 D MediaControlService: initialize
 08-12 12:59:19.488 12092 12092 D MediaControlService: HandleIntent, action
 = action_init, mediaState = STOPPED
 08-12 12:59:21.996 12092 12125 I nsScreenManagerAndroid:
 nsWindow[0x7cef28fc00]::Show 1
 08-12 12:59:22.146 12092 12125 I Gecko   :
 AndroidBridge::GetScreenOrientation
 08-12 12:59:24.341 12092 12125 I Gecko   : console.log: "Locale:OS: en-US"
 08-12 12:59:24.465 12092 12125 I Gecko   : console.log: "New OS locale."
 08-12 12:59:24.723 12092 12125 I Gecko   : console.log: "Default
 intl.accept_languages = en-US, en"
 08-12 12:59:25.396 12092 12125 I Gecko   : console.log: "Setting
 intl.accept_languages to en-us,en"
 08-12 12:59:33.072 12092 12125 D GeckoDistribution: Custom distribution
 directory not found.
 08-12 12:59:34.774 12092 12125 I Gecko   : ++DOCSHELL 0x7c9de85000 == 3
 [pid = 12092] [id = {bd496ae9-7ec6-45ce-b90f-ae93c79cfbd3}]
 08-12 12:59:34.777 12092 12125 I Gecko   : ++DOMWINDOW == 6 (0x7c9df07c00)
 [pid = 12092] [serial = 6] [outer = 0x0]
 08-12 12:59:43.536 12092 12125 I Gecko   : ++DOMWINDOW == 7 (0x7c9df11800)
 [pid = 12092] [serial = 7] [outer = 0x7c9df07c00]
 08-12 12:59:49.389 12092 12125 D GeckoScreenOrientation: unlocking
 08-12 13:00:02.086 12092 12125 I Gecko   : ++DOMWINDOW == 8 (0x7cee85ac00)
 [pid = 12092] [serial = 8] [outer = 0x7c9df07c00]
 08-12 13:0

Re: [tor-bugs] #31232 [Internal Services/Tor Sysadmin Team]: Migrate default snowflake broker (and bridge?) to TPA machines

[Tor Bug Tracker & Wiki]

#31232: Migrate default snowflake broker (and bridge?) to TPA machines
-+-
 Reporter:  cohosh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 would it be possible to split the snowflake architecture in two parts, the
 same way bridgedb and bridges authority are separate, and would that help
 us here?

 also: i'm not sure what the next step is, but if you need a torproject.net
 domain, just let me know. :)

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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Do a reachability check before polling for clients

[Tor Bug Tracker & Wiki]

#31391: Do a reachability check before polling for clients
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Replying to [comment:5 cypherpunks]:
 > Replying to [comment:4 cohosh]:
 > > The snowflake proxy doesn't need to reach directory servers or
 torproject.org to work. It needs to reach the snowflake bridge(s) it knows
 about, and the snowflake broker though.
 > I know but it's a good metric of knowing whether one is in a censored
 region since there tp.org and directory servers are usually blocked (one
 can even add a "proceed anyway?" option in case the bridge can be
 accessed).

 We should be careful about how we message this since there could be many
 reasons for network failure that aren't related to censorship.

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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Do a reachability check before polling for clients (was: Block censored countries from running snowflakes)

[Tor Bug Tracker & Wiki]

#31391: Do a reachability check before polling for clients
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by cohosh:

Old description:

> I'm looking at
> https://trac.torproject.org/projects/tor/attachment/ticket/29461/example_metrics.log
> and I've seen one `TR=2` and another `TR=5` record. I'm not aware of the
> current situation in TR but as far as I remember Tor was censored there
> (it is even stated in the Torlauncher).
>
> I propose to add a geoip check after the WebRTC check, and inform users
> in a list of censored countries that they can't run a snowflake proxy.

New description:

 I'm looking at
 
https://trac.torproject.org/projects/tor/attachment/ticket/29461/example_metrics.log
 and I've seen one `TR=2` and another `TR=5` record. I'm not aware of the
 current situation in TR but as far as I remember Tor was censored there
 (it is even stated in the Torlauncher).

 We can have a snowflake do a reachability check of the bridge(s) and
 broker (and maybe Tor domains/dirauths) before trying to poll for clients.
 If this check fails, we should display a user-facing error message or
 warning and hold off on polling while the bridge is unreachable

--

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

Re: [tor-bugs] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+--
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * owner:  (none) => cohosh
 * status:  reopened => assigned


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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Block censored countries from running snowflakes

[Tor Bug Tracker & Wiki]

#31391: Block censored countries from running snowflakes
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 Replying to [comment:4 cohosh]:
 > The snowflake proxy doesn't need to reach directory servers or
 torproject.org to work. It needs to reach the snowflake bridge(s) it knows
 about, and the snowflake broker though.
 I know but it's a good metric of knowing whether one is in a censored
 region since there tp.org and directory servers are always blocked (one
 can even add a "proceed anyway?" option in case the bridge can be
 accessed).

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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Block censored countries from running snowflakes

[Tor Bug Tracker & Wiki]

#31391: Block censored countries from running snowflakes
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Replying to [comment:3 cypherpunks]:
 > I was thinking about a "can it reach torproject.org? can it reach the
 directory servers?" as a metric indicative of whether it's in a censored
 region (which would even catch the cases when a snowflake is in a non-
 censored country but a censored network), but even that approach has its
 fair share of problems.

 The snowflake proxy doesn't need to reach directory servers or
 torproject.org to work. It needs to reach the snowflake bridge(s) it knows
 about, and the snowflake broker though.

 I like this idea. Changing the snowflake logic to test a connection to the
 bridge before polling and to disable if it is unreachable would solve some
 problems before they affect the client. And the snowflake of course won't
 get any clients at all if it can't reach the broker. We could also add
 some user-facing error message to let the operator know in the case
 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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Block censored countries from running snowflakes

[Tor Bug Tracker & Wiki]

#31391: Block censored countries from running snowflakes
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 I was thinking about a "can it reach torproject.org? can it reach the
 directory servers?" as a metric indicative of whether it's in a censored
 region (which would even catch the cases when a snowflake is in a non-
 censored country but a censored network), but even that approach has its
 fair share of problems.

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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Block censored countries from running snowflakes

[Tor Bug Tracker & Wiki]

#31391: Block censored countries from running snowflakes
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Replying to [comment:1 cypherpunks]:
 > There are even Iranian snowflakes, and guess what, they work.

 Yep, and it's not surprising that snowflakes would work in places that
 block Tor. Many places that block access to public Tor relays don't
 effectively block pluggable transports.

 There are a lot of challenges with doing something like the ticket
 describes. Keep in mind that:
 - the geoip database we use isn't perfect
 - keeping track of which proxies do and do not work in different regions
 is very difficult and as long as we have a lot of diverse snowflakes we
 probably don't need to do this (see
 https://trac.torproject.org/projects/tor/ticket/30350#comment:8)

 It might make sense to have some logic at the client to make sure they
 aren't connecting to a proxy within their own censored region for safety
 purposes, but a widespread rejection of snowflakes in all regions that
 censor public Tor relays seems both unnecessary and unfeasible. There are
 many reasons why an individual snowflake won't work well for a client in
 addition being run in a place that blocks the bridge IP:
 - the snowflake could be maliciously or due to bugs unreliable
 - the snowflake could be outside the censored region but on an IP address
 blocked by the censor

 We are working on other solutions to handle all of these problems (see
 #25429, #25723). We're going for quantity and overall quality here and
 hoping that we can have a solution for the instances in which individual
 quality suffers.

 That being said, we might say something on the web store to the effect
 that if you reside in a region that censors Tor, your snowflake probably
 won't be very useful.

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

Re: [tor-bugs] #31375 [Core Tor/Tor]: hs: Crash in token_bucket_ctr_refill() of the INTRO2 DoS defense

[Tor Bug Tracker & Wiki]

#31375: hs: Crash in token_bucket_ctr_refill() of the INTRO2 DoS defense
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, crash, regression, nickm-|  Actual Points:
  merge  |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

 * keywords:  tor-hs, crash, regression => tor-hs, crash, regression, nickm-
 merge


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

Re: [tor-bugs] #31361 [Metrics]: Remove Cobertura from our build process

[Tor Bug Tracker & Wiki]

#31361: Remove Cobertura from our build process
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me. It is not easy to run this in the CI without the
 metrics-base commit already being pushed, but I duplicated the CI locally
 (it just runs in Docker) and ran it manually and it worked.

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

Re: [tor-bugs] #31397 [Core Tor/Tor]: Appveyor: pacman.exe : error: msys: signature … is invalid

[Tor Bug Tracker & Wiki]

#31397: Appveyor: pacman.exe : error: msys: signature … is invalid
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Critical | Resolution:
 Keywords:  041-must, tor-ci-fail, ci-   |  Actual Points:
  environment, appveyor, Windows |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_information


Comment:

 It looks like this issue only failed builds for a few minutes - it may
 have been a network issue.

 We have had one successful build since that time.
 I have just restarted the 4 failed builds, I'll check them in the morning.

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

Re: [tor-bugs] #31164 [Circumvention]: Set up default bridge at Karlstad University

[Tor Bug Tracker & Wiki]

#31164: Set up default bridge at Karlstad University
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-bridges|  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by pulls):

 Replying to [comment:2 arma]:
 > Replying to [comment:1 pulls]:
 > > fully on board with replacing our relay with a default bridge
 >
 > Replacing? Why choose? :)

 Bandwidth is precious! :) Maybe the relay will find its way back later if
 there's room.

 I got an OK to use 1 gbit of our link. Will upgrade the hardware of the
 box (lacked AESNI) this week. To use the full link, should the box run
 more than one instance of tor? Something else to keep in mind? Appreciate
 any help 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] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-+-
 Reporter:  arma |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:  6
  roadmap-august |
Parent ID:  #2   | Points:  7
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by asn):

 Replying to [comment:26 nickm]:
 > I think this code looks okay but before we merge it, I think we should
 have a patch for tor-spec that explains the new behavior of the replay
 cache.  We should also have a quick proposal that explains why it's safe
 to allow replays, since I've usually thought of them as a way to mount
 active traffic analysis attacks.

 Here is a torspec patch:
 
https://github.com/asn-d6/torspec/commit/f0fbcf3d606b8fb8ec49b1ba8f790607725dbd8b
 https://github.com/asn-d6/torspec/tree/bug26294

 We actually had not heard that replay caches are there to protect against
 traffic analysis attacks. How does the attack work? I considered that
 identical INTRO2 cells could be used as a signal to the HS guard, but
 since they are end-to-end encrypted the singal should not be visible,
 right?

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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Block censored countries from running snowflakes

[Tor Bug Tracker & Wiki]

#31391: Block censored countries from running snowflakes
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 There are even Iranian snowflakes, and guess what, they 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] #29461 [Metrics/CollecTor]: Add a Snowflake module

[Tor Bug Tracker & Wiki]

#29461: Add a Snowflake module
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-august, anti-|  Actual Points:
  censorship-roadmap-september   |
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
 |  Sponsor28
-+-

Comment (by karsten):

 Where would I find the spec? I found
 [https://github.com/cohosh/snowflake/pull/3/files#diff-
 c8ef7ba143d251e41b143b2ab02f3733 this comment] which is fine for me to
 start write some metrics-lib code. But we'll have to link to something
 more permanent once we start collecting these statistics; ideally tor-
 spec.git. 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