Re: [tor-bugs] #32754 [Core Tor/Tor]: X-Ufhash NNTP header when using win-tor

[Tor Bug Tracker & Wiki]

#32754: X-Ufhash NNTP header when using win-tor
+--
 Reporter:  hack-4-freedom  |  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: 0.4.2.5
 Severity:  Normal  | Resolution:  invalid
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

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


Comment:

 This doesn't seem to be a question about the Tor program; this seems to be
 something to do with your usenet setup.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32754 [Core Tor/Tor]: X-Ufhash NNTP header when using win-tor

[Tor Bug Tracker & Wiki]

#32754: X-Ufhash NNTP header when using win-tor
+--
 Reporter:  hack-4-freedom  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.2.5|   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Hi, all

 I'v been using win-tor as a proxy to Thunderbird for posting on
 newsgroups/usenet and trying to figure out how to query the X-Ufhash NNTP
 header that returns a long encrypted string to get meaningfull info
 X-Ufhash :
 
ZaQJEMf5JdvcWEOleKoXo4ljK0hv5rauvinj9qfPFH9gkEPA9vOw7Jqtkzj1SWuX6Q8ZeGvPfoGqFZipnXALeUtU8QLJQ513NMFAEVrNG2z3xZ48ksSy%2BKsEFCn6UJps8tZrNOrMiMKF%2FNofAzkyepiHCjV5CTN9PZ%2BV54b86ugEh9hPoGwPMgxFJJ8naz5uHr%2BHog6zUm4qfvxfrhgiuz17g%2BMO07eqsGuJ

 is there some kind of way to decode ?
 any ideas ?

 thank's in advance

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

Re: [tor-bugs] #32741 [Applications/Tor Browser]: CMake repository moved

[Tor Bug Tracker & Wiki]

#32741: CMake repository moved
+--
 Reporter:  sysrqb  |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201912R  |  Actual Points:  0.25
Parent ID:  | Points:
 Reviewer:  gk  |Sponsor:
+--
Changes (by sysrqb):

 * actualpoints:   => 0.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

Re: [tor-bugs] #32460 [Webpages/Website]: download page has confusing flow, especially with donate banner

[Tor Bug Tracker & Wiki]

#32460: download page has confusing flow, especially with donate banner
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by opara):

 Just an idea, it would be useful if an {{{id="choose-platform"}}}
 attribute was added to the "Defend yourself" text. That way when someone
 has difficulty downloading the browser, someone can point them to
 "https://www.torproject.org/download/#choose-platform"; and the page will
 automatically scroll to the correct location. It doesn't solve some of the
 usability problems above, but might provide a simple way to help users
 while bigger changes are being worked on.

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

Re: [tor-bugs] #32629 [Core Tor/Tor]: Re-enable 1 or 2 more macOS jobs in Travis

[Tor Bug Tracker & Wiki]

#32629: Re-enable 1 or 2 more macOS jobs in Travis
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-immediately, tor-  |  Actual Points:  0.3
  ci, ipv6, macos, 029-backport, 035-backport,   |
  040-backport, 041-backport, 042-backport   |
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by nickm):

 Pending releases are out; feel free to merge at your convenience.

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

Re: [tor-bugs] #32672 [Core Tor/Tor]: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE BEFORE 2020] (was: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version())

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Changing title to reduce the odds of an accidental early 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] #32753 [Core Tor/Tor]: Tor should lower-case its BridgeDistribution string

[Tor Bug Tracker & Wiki]

#32753: Tor should lower-case its BridgeDistribution string
+--
 Reporter:  arma|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  backport easy anticensorship-wants  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:   => backport easy anticensorship-wants
 * milestone:   => Tor: 0.4.3.x-final


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

Re: [tor-bugs] #32751 [Applications/Tor Browser]: Setting var/sign_build to 1 should sign the sha256sums-unsigned-build.incrementals.txt file too

[Tor Bug Tracker & Wiki]

#32751: Setting var/sign_build to 1 should sign the sha256sums-unsigned-
build.incrementals.txt file too
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:  .1
  TorBrowserTeam201912R  |
Parent ID:  #32750   | Points:
 Reviewer:  gk   |Sponsor:
-+-
Changes (by boklm):

 * status:  needs_revision => needs_review
 * keywords:  tbb-rbm, tbb-update, TorBrowserTeam201912 => tbb-rbm, tbb-
 update, TorBrowserTeam201912R


Comment:

 Replying to [comment:4 gk]:
 > I guess we should add the incremental part to
 > {{{
 >   ### The var/sign_build_gpg_opts option can be used to define some gpg
 >   ### options to select the key to use to sign the sha256sums-unsigned-
 build.txt
 >   ### file.
 > }}}
 > ?

 Thanks, I did that in `bug_32751_v3`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_32751_v3&id=adf23abdceb488864de0639fc74affd3556eb2fc

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

Re: [tor-bugs] #30608 [Internal Services/Tor Sysadmin Team]: Have a SMTP out only server

[Tor Bug Tracker & Wiki]

#30608: Have a SMTP out only server
-+-
 Reporter:  dgoulet  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> I do use my @tpo email address for many communications outside torproject
> lists or @tpo people.
>
> Lately, I discovered that many of my emails were silent drop by the
> remote server or put in SPAM. And that was because the person came back
> to me asking where was my email. For instance, gmail sometimes put it in
> the SPAM still because we lack DKIM/SPF so it hurts our reputation.
>
> Th reason why is quite simple: I use my own SMTP server to send the
> emails while forging the `From` address.
>
> It would honestly be of a great help if we could simply have an
> authenticated SMTP server that I could use with let say my LDAP account
> for sending emails with my @tpo and not being worried that it gets
> dropped...
>
> 
>
> The steps required for this change are:
>
>  1. [x] create a new field (`emailPassword`?) in the LDAP schema (done)
>  2. [ ] setup a separate email server to accept submissions and keep mail
> servers aware that not only eugeni sends email
>  3. [ ] hook up the password field as authentication in Postfix in the
> server (probably through ud-generate?)
>  4. [ ] test with TPA users that can modify their own password directly
> through LDAP
>  5. [ ] update the web interface (to support changing the field as well?)
>  6. [ ] optionally, update the mail gateway to support changes to the
> field
>  7. [ ] do tests with the users in this ticket, and if this works,
> propagate to all current LDAP users
>  8. [ ] create LDAP accounts for more users who want to use the system
>
> We should also make a design document to follow along.

New description:

 I do use my @tpo email address for many communications outside torproject
 lists or @tpo people.

 Lately, I discovered that many of my emails were silent drop by the remote
 server or put in SPAM. And that was because the person came back to me
 asking where was my email. For instance, gmail sometimes put it in the
 SPAM still because we lack DKIM/SPF so it hurts our reputation.

 Th reason why is quite simple: I use my own SMTP server to send the emails
 while forging the `From` address.

 It would honestly be of a great help if we could simply have an
 authenticated SMTP server that I could use with let say my LDAP account
 for sending emails with my @tpo and not being worried that it gets
 dropped...

 

 The steps required for this change are:

  1. [x] create a new field (`emailPassword`?) in the LDAP schema (done)
  2. [x] setup a separate email server to accept submissions and keep mail
 servers aware that not only eugeni sends email
  3. [ ] hook up the password field as authentication in Postfix in the
 server (probably through ud-generate?)
  4. [ ] test with TPA users that can modify their own password directly
 through LDAP
  5. [ ] update the web interface (to support changing the field as well?)
  6. [ ] optionally, update the mail gateway to support changes to the
 field
  7. [ ] do tests with the users in this ticket, and if this works,
 propagate to all current LDAP users
  8. [ ] create LDAP accounts for more users who want to use the system
  9. [ ] add monitoring loops, with (say) Google, Hotmail, Yahoo and Riseup
 to ensure delivery works across servers
 We should also make a design document to follow along.

--

Comment (by anarcat):

 just setup submit-01.torproject.org to test the deployment. added a todo
 for monitoring.

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

Re: [tor-bugs] #32729 [Core Tor/Tor]: "hs_circuitmap_init: Assertion !the_hs_circuitmap failed" when repeating failed tests on Android

[Tor Bug Tracker & Wiki]

#32729: "hs_circuitmap_init: Assertion !the_hs_circuitmap failed" when repeating
failed tests on Android
--+
 Reporter:  eighthave |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Android backport? crash?  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by eighthave):

 I'm still seeing this crash occasionally when running the `TorService`
 test suite with multiple Tor start/stops (e.g. first running
 `testOverridingDefaultsTorrc` then `testBindService`).   I added logging
 of `hs_circuitmap_init` and `hs_circuitmap_free_all`, as well as the
 "clear between test runs" to the Android test runner:
 {{{
 // The following argument makes the Android Test Orchestrator run
 its
 // "pm clear" command after each test invocation. This command
 ensures
 // that the app's state is completely cleared between tests. This
 is required
 // since there is no way to unset
 URL.setURLStreamHandlerFactory().
 testInstrumentationRunnerArguments clearPackageData: 'true'
 }}}

 Attached is the crash log from `adb logcat`, it does not seem to show
 double calls to `hs_circuitmap_init` or `hs_circuitmap_free_all`.  I think
 we might have to consider that Android will kill Tor without warning and
 reuse the process.

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

Re: [tor-bugs] #32729 [Core Tor/Tor]: "hs_circuitmap_init: Assertion !the_hs_circuitmap failed" when repeating failed tests on Android

[Tor Bug Tracker & Wiki]

#32729: "hs_circuitmap_init: Assertion !the_hs_circuitmap failed" when repeating
failed tests on Android
--+
 Reporter:  eighthave |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Android backport? crash?  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by eighthave):

 * Attachment "crashlog.txt" added.


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

[tor-bugs] #32753 [Core Tor/Tor]: Tor should lower-case its BridgeDistribution string

[Tor Bug Tracker & Wiki]

#32753: Tor should lower-case its BridgeDistribution string
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 See comment:8 in #32547, where phw tells a bridge operator that they need
 to set BridgeDistribution to "none", because using "None" is not right.

 That isn't a good user experience, and it's easy to fix.

 One option is that inside check_bridge_distribution_setting() when we do
 {{{if (!strcmp(bd, RECOGNIZED[i]))}}} we should do strcasecmp instead.
 That is, don't complain if it's a recognized value and the only issue is
 that it's not all lowercase.

 But a better option imo is that we lowercase it in place first, so that if
 the user types None, bridgedb still sees none.

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

Re: [tor-bugs] #32751 [Applications/Tor Browser]: Setting var/sign_build to 1 should sign the sha256sums-unsigned-build.incrementals.txt file too

[Tor Bug Tracker & Wiki]

#32751: Setting var/sign_build to 1 should sign the sha256sums-unsigned-
build.incrementals.txt file too
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:  .1
  TorBrowserTeam201912   |
Parent ID:  #32750   | Points:
 Reviewer:  gk   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * reviewer:   => gk
 * keywords:  tbb-rbm, tbb-update, TorBrowserTeam201912R => tbb-rbm, tbb-
 update, TorBrowserTeam201912


Comment:

 I guess we should add the incremental part to
 {{{
   ### The var/sign_build_gpg_opts option can be used to define some gpg
   ### options to select the key to use to sign the sha256sums-unsigned-
 build.txt
   ### file.
 }}}
 ?

 Otherwise looks good.

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

Re: [tor-bugs] #32750 [Applications/Tor Browser]: Sign nightly sha256sums files with gpg

[Tor Bug Tracker & Wiki]

#32750: Sign nightly sha256sums files with gpg
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:  .1
  TorBrowserTeam201912R  |
Parent ID:  #18867   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-rbm, tbb-update, TorBrowserTeam201912 => tbb-rbm, tbb-
 update, TorBrowserTeam201912R
 * status:  assigned => needs_review
 * points:  .25 => .1
 * actualpoints:   => .1


Comment:

 There is a patch for review in branch `bug_32750_v2`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_32750_v2&id=f803f711462092c3858a8c0b28aa7f2ea782050f

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

Re: [tor-bugs] #32730 [Internal Services/Service - git]: Status of dip.torproject.org and migration from ansible to the omnibus package

[Tor Bug Tracker & Wiki]

#32730: Status of dip.torproject.org and migration from ansible to the omnibus
package
-+
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gitlab   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by anarcat):

 * keywords:   => gitlab


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32752 [Internal Services/Service - lists]: request to create email list onion-advis...@lists.torproject.org

[Tor Bug Tracker & Wiki]

#32752: request to create email list onion-advis...@lists.torproject.org
---+-
 Reporter:  isabela|  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 hi,

 Could someone create the list:
  onion-advis...@lists.torproject.org

 I can be the admin of it.

 The list should not have public archives - but should have archive.
 Only members should be able to write to the list as well.

 thanks

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

Re: [tor-bugs] #32743 [Core Tor/Tor]: Remove tor-spec requirement of initiator-side V1 and V2 link handshakes

[Tor Bug Tracker & Wiki]

#32743: Remove tor-spec requirement of initiator-side V1 and V2 link handshakes
+
 Reporter:  opara   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by opara):

 I think we might be talking about two slightly different things here? This
 ticket is about changing tor-spec to match tor, with no changes to the tor
 code itself. So v1 and v2 handshakes would still be supported by
 responders (as they are now), but since v1 and v2 handshakes are no longer
 supported by initiators in the tor code, only that initiator requirement
 would be removed from tor-spec. It seems like you might be discussing
 dropping support for v1 and v2 altogether (which would require changes to
 the tor code)?

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

Re: [tor-bugs] #32751 [Applications/Tor Browser]: Setting var/sign_build to 1 should sign the sha256sums-unsigned-build.incrementals.txt file too

[Tor Bug Tracker & Wiki]

#32751: Setting var/sign_build to 1 should sign the sha256sums-unsigned-
build.incrementals.txt file too
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:  .1
  TorBrowserTeam201912R  |
Parent ID:  #32750   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 I pushed a new revision of the patch in branch `bug_32751_v2` to also
 update the README file and comment in `rbm.local.conf.example`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_32751_v2&id=6986e3a96ca782ec3cd090f51cfaf3c363800ab1

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

Re: [tor-bugs] #32735 [Internal Services/Tor Sysadmin Team]: Please remove my access to staticiforme and ability to push Tor Browser releases and add sysrqb instead

[Tor Bug Tracker & Wiki]

#32735: Please remove my access to staticiforme and ability to push Tor Browser
releases and add sysrqb instead
-+-
 Reporter:  gk   |  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:  accepted => closed
 * resolution:   => fixed


Comment:

 i added the tb-release group to sysrq and removed it from you, i hope
 that's alright?

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

Re: [tor-bugs] #32735 [Internal Services/Tor Sysadmin Team]: Please remove my access to staticiforme and ability to push Tor Browser releases and add sysrqb instead

[Tor Bug Tracker & Wiki]

#32735: Please remove my access to staticiforme and ability to push Tor Browser
releases and add sysrqb instead
-+-
 Reporter:  gk   |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


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

Re: [tor-bugs] #32751 [Applications/Tor Browser]: Setting var/sign_build to 1 should sign the sha256sums-unsigned-build.incrementals.txt file too

[Tor Bug Tracker & Wiki]

#32751: Setting var/sign_build to 1 should sign the sha256sums-unsigned-
build.incrementals.txt file too
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:  .1
  TorBrowserTeam201912R  |
Parent ID:  #32750   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * actualpoints:   => .1


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

Re: [tor-bugs] #32751 [Applications/Tor Browser]: Setting var/sign_build to 1 should sign the sha256sums-unsigned-build.incrementals.txt file too

[Tor Bug Tracker & Wiki]

#32751: Setting var/sign_build to 1 should sign the sha256sums-unsigned-
build.incrementals.txt file too
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:
  TorBrowserTeam201912R  |
Parent ID:  #32750   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-rbm, tbb-update, TorBrowserTeam201912 => tbb-rbm, tbb-
 update, TorBrowserTeam201912R
 * status:  new => needs_review


Comment:

 There is a patch for review in my branch `bug_32751`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_32751&id=cfc6a4187862e58a2b6b8a16e089fb809bc902cb

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

Re: [tor-bugs] #32743 [Core Tor/Tor]: Remove tor-spec requirement of initiator-side V1 and V2 link handshakes

[Tor Bug Tracker & Wiki]

#32743: Remove tor-spec requirement of initiator-side V1 and V2 link handshakes
+
 Reporter:  opara   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 I've asked Roger for stats on moria, and he reports that v1 connections
 received are only around .008% of total connections received, but v2
 connections are about 3% of connections received.  That latter is big
 enough that we should make sure that zombie v2 clients don't overwhelm the
 network.

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

Re: [tor-bugs] #32732 [Core Tor/Tor]: Add __future__ imports to every tor python file

[Tor Bug Tracker & Wiki]

#32732: Add __future__ imports to every tor python file
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:  0.1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 LGTM; CI passes.  Merging.

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

Re: [tor-bugs] #32743 [Core Tor/Tor]: Remove tor-spec requirement of initiator-side V1 and V2 link handshakes

[Tor Bug Tracker & Wiki]

#32743: Remove tor-spec requirement of initiator-side V1 and V2 link handshakes
+
 Reporter:  opara   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * keywords:   => needs-proposal


Comment:

 This is worth doing, but it needs a proposal; see
 "proposals/001-process.txt" for more information on the proposal process.

 One reason it needs a proposal is that we need to avoid a so-called "fast
 zombies" problem; see proposal 266 for an introduction to that one.  (But
 proposal 266 is from back in 2016, and should be superseded by proposals
 264 and 272.)

 We will have substantially more latitude here once 0.2.9 becomes
 unsupported in early 2020.

 Would you be interested in working on an updated proposal here to try to
 figure out how to manage the transition here without causing a zombie
 swarm of old clients?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32751 [Applications/Tor Browser]: Setting var/sign_build to 1 should sign the sha256sums-unsigned-build.incrementals.txt file too

[Tor Bug Tracker & Wiki]

#32751: Setting var/sign_build to 1 should sign the sha256sums-unsigned-
build.incrementals.txt file too
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, tbb-update,
 Severity:  Normal   |  TorBrowserTeam201912
Actual Points:   |  Parent ID:  #32750
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When setting `var/sign_build` to `1`, the file `sha256sums-unsigned-
 build.txt` is getting signed automatically at the end of a build. The
 `sha256sums-unsigned-build.incrementals.txt` file however currently does
 not get signed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32750 [Applications/Tor Browser]: Sign nightly sha256sums files with gpg

[Tor Bug Tracker & Wiki]

#32750: Sign nightly sha256sums files with gpg
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, tbb-update,
 Severity:  Normal   |  TorBrowserTeam201912
Actual Points:   |  Parent ID:  #18867
   Points:  .25  |   Reviewer:
  Sponsor:   |
-+-
 We should sign the nightly build sha256sums with gpg.

 This can be done by creating a key on the nightly build machine, and
 setting `var/sign_build` to `1` in `rbm.local.conf`.

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

Re: [tor-bugs] #32547 [Applications/Tor Browser]: Set up default bridge at the University of Minnesota

[Tor Bug Tracker & Wiki]

#32547: Set up default bridge at the University of Minnesota
--+---
 Reporter:  phw   |  Owner:  phw
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-bridges   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:  Sponsor30
--+---

Comment (by jvsg):

 Thanks for pointing that out. I've Corrected the config for the 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

[tor-bugs] #32749 [Applications]: Tor download button on your site does nothing when I click on it

[Tor Bug Tracker & Wiki]

#32749: Tor download button on your site does nothing when I click on it
+--
 Reporter:  get-lead-out.44mag  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Very High   |  Component:  Applications
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I'm on cyberghost vpn and your TOR download button does absolutely nothing
 when I click on it. I have tried turning off firewall, malwarebytes, and
 tried using both Internet Explorer and Firefox browsers but still nothing
 happens when I click on your Tor download button and I can't find any
 search result which give a direct reason and solution to get Tor to
 download on our pc with Windows 8.1

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

Re: [tor-bugs] #32228 [Applications/Tor Browser]: Bookmark TPO support domains in Tor Browser

[Tor Bug Tracker & Wiki]

#32228: Bookmark TPO support domains in Tor Browser
---+--
 Reporter:  ggus   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201912  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by emmapeel):

 yeah, this would be a great feature, i actually have bookmarked this
 places and i use them a lot

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

Re: [tor-bugs] #32228 [Applications/Tor Browser]: Bookmark TPO support domains in Tor Browser

[Tor Bug Tracker & Wiki]

#32228: Bookmark TPO support domains in Tor Browser
---+--
 Reporter:  ggus   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201912  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by antonela):

 I like this idea. We can plan this release after the EOY campaign ends.

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

Re: [tor-bugs] #19757 [Applications/Tor Browser]: Make a menu to add onion and auth-cookie to TB

[Tor Bug Tracker & Wiki]

#19757: Make a menu to add onion and auth-cookie to TB
-+-
 Reporter:  mrphs|  Owner:  brade
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-usability, tor-hs,  |  Actual Points:
  TorBrowserTeam201912   |
Parent ID:  #3   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Thanks for this work team! Looks great.

 Could we have a discussion about how we are calling the
 secret/password/key/token and be consistent with that wording across the
 UI?

 I agree that the string doesn't look like a password or passphrase or
 another familiar word for users. What about using `secret key`? Is that
 secret? Personally, I just like `Key` but i wonder what others think.

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

Re: [tor-bugs] #32720 [Core Tor/Tor]: How much bandwidth does a user use to bootstrap and maintain dir info? How has that changed over time?

[Tor Bug Tracker & Wiki]

#32720: How much bandwidth does a user use to bootstrap and maintain dir info? 
How
has that changed over time?
--+--
 Reporter:  arma  |  Owner:  nickm
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 I had an early crash for unrelated reasons, but I think these results seem
 reasonably straightforward.

 Experiment 1: (master. Bootstrapped, then updated 6 times.)
 {{{
 Dec 12 18:29:22.000 [notice] Heartbeat: Tor's uptime is 6:10 hours, with 5
 circuits open. I've sent 1.63 MB and received 4.01 MB.
 Dec 12 18:29:22.000 [notice] While bootstrapping, fetched this many bytes:
 Dec 12 18:29:22.000 [notice] 516749 (consensus network-status fetch)
 Dec 12 18:29:22.000 [notice] 13402 (authority cert fetch)
 Dec 12 18:29:22.000 [notice] 1824780 (microdescriptor fetch)
 Dec 12 18:29:22.000 [notice] While not bootsrapping, fetched this many
 bytes:
 Dec 12 18:29:22.000 [notice] 212877 (consensus network-status fetch)
 Dec 12 18:29:22.000 [notice] 108170 (microdescriptor fetch)
 }}}

 Experiment 2: (master, UseMicrodescriptors 0. Bootstrapped, then updated 6
 times.)
 {{{
 Dec 12 18:37:22.000 [notice] Heartbeat: Tor's uptime is 5:50 hours, with 5
 circuits open. I've sent 1.94 MB and received 13.02 MB.
 Dec 12 18:37:22.000 [notice] While bootstrapping, fetched this many bytes:
 Dec 12 18:37:22.000 [notice] 7725566 (server descriptor fetch)
 Dec 12 18:37:22.000 [notice] 445783 (consensus network-status fetch)
 Dec 12 18:37:22.000 [notice] 13266 (authority cert fetch)
 Dec 12 18:37:22.000 [notice] While not bootsrapping, fetched this many
 bytes:
 Dec 12 18:37:22.000 [notice] 3209765 (server descriptor fetch)
 Dec 12 18:37:22.000 [notice] 255740 (consensus network-status fetch)
 }}}

 Experiment 3 (no diffs. Bootstrapped, then updated 5 times.):
 {{{
 Dec 12 18:34:22.000 [notice] Heartbeat: Tor's uptime is 5:20 hours, with 5
 circuits open. I've sent 1.56 MB and received 6.34 MB.
 Dec 12 18:34:22.000 [notice] While bootstrapping, fetched this many bytes:
 Dec 12 18:34:22.000 [notice] 517073 (consensus network-status fetch)
 Dec 12 18:34:22.000 [notice] 13266 (authority cert fetch)
 Dec 12 18:34:22.000 [notice] 1832842 (microdescriptor fetch)
 Dec 12 18:34:22.000 [notice] While not bootsrapping, fetched this many
 bytes:
 Dec 12 18:34:22.000 [notice] 2638812 (consensus network-status fetch)
 Dec 12 18:34:22.000 [notice] 94761 (microdescriptor fetch)
 }}}

 Experiment 4 (no zstd or lzma2, only zlib.  Bootstrapped, then updated 5
 times):
 {{{
 Dec 12 18:37:56.000 [notice] Heartbeat: Tor's uptime is 4:40 hours, with 5
 circuits open. I've sent 1.40 MB and received 3.78 MB.
 Dec 12 18:37:56.000 [notice] While bootstrapping, fetched this many bytes:
 Dec 12 18:37:56.000 [notice] 572325 (consensus network-status fetch)
 Dec 12 18:37:56.000 [notice] 13110 (authority cert fetch)
 Dec 12 18:37:56.000 [notice] 1836661 (microdescriptor fetch)
 Dec 12 18:37:56.000 [notice] While not bootsrapping, fetched this many
 bytes:
 Dec 12 18:37:56.000 [notice] 200259 (consensus network-status fetch)
 Dec 12 18:37:56.000 [notice] 84658 (microdescriptor fetch)
 }}}

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

Re: [tor-bugs] #32181 [Core Tor/Tor]: remove custom Android logging, use syslog

[Tor Bug Tracker & Wiki]

#32181: remove custom Android logging, use syslog
--+
 Reporter:  eighthave |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Android, 043-can  |  Actual Points:  .2
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by eighthave):

 Looks good to me.

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

Re: [tor-bugs] #32746 [Internal Services/Service - jenkins]: translations repo and jenkins: reduce builds

[Tor Bug Tracker & Wiki]

#32746: translations repo and jenkins: reduce builds
-+
 Reporter:  emmapeel |  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  lektor, l10n, jenkins|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by emmapeel:

Old description:

> i have been thinking on how to use our resources more wisely regarding
> the translations and the websites.
>
> At this moment we are building many branches anew each time we push
> changes to our translations repository.
>
> This results on a situation when if there is people translating the
> support portal to Malayalam, which is still not published, and therefore
> making changes to the translation repository, the website is rebuild
> several times when there have been no actual changes to it.
>
> On the other hand, the quick updates are very useful for translators, and
> they use the staging version of the site a lot, since most of the
> translators work happens _before_ the website is released.
>
> But the lots of updates from translators and the amount of yet-incomplete
> languages that are built on the staging site causes some trouble to other
> web developers and confuses tehir development, also it makes staging hard
> to update regarding master because of the language configurations, etc.
>
> So I propose the following scheduling in lektor-jenkins-translation
> branches:
>
> master/staging/develop ---> when there is a change on this branches,
> we pull the translation repo and update all
> together
>
> translations   ---> we rebuild when there are changes on the
> branch
> AND changes on the translation repo branch as
> well
>
> If we would want to update the translations in branches
> master/staging/develop, we should be able to do it simply by building
> from the web interface or similar.
>
> This way we can reduce the builds and make development less cumbersome,
> while also providing a quick preview of their changes to active
> translators.
>
> We can also prevent accidentally publishing incomplete languages, or
> removing languages from the 'preview' website.

New description:

 i have been thinking on how to use our resources more wisely regarding the
 translations and the websites.

 At this moment we are building many branches anew each time we push
 changes to our translations repository.

 This results on a situation when if there is people translating the
 support portal to Malayalam, which is still not published, and therefore
 making changes to the translation repository, the website is rebuild
 several times when there have been no actual changes to it.

 On the other hand, the quick updates are very useful for translators, and
 they use the staging version of the site a lot, since most of the
 translators work happens _before_ the website is released.

 But the lots of updates from translators and the amount of yet-incomplete
 languages that are built on the staging site causes some trouble to other
 web developers and confuses tehir development, also it makes staging hard
 to update regarding master because of the language configurations, etc.

 So I propose the following scheduling in lektor-jenkins-translation
 branches:

 master/staging/develop ---> when there is a change on this branches,
 we pull the translation repo and update all
 together

 translations   ---> we rebuild when there are changes on the
 branch
 AND changes on the translation repo branch as
 well

 If we would want to update the translations in branches
 master/staging/develop, we should be able to do it simply by building from
 the web interface or similar.

 This way we can reduce the builds and make development less cumbersome,
 while also providing a quick preview of their changes to active
 translators.

 We can also prevent accidentally publishing incomplete languages, or
 removing languages from the 'preview' website.


 So, for this to be implemented we need to:

 * Make sure that the 'translations' branches are updated when their
 corresponding branch at https://gitweb.torproject.org/translation.git/
 gets updated.
 * Stop building the master/develop/staging builds each time there is a
 commit in  their corresponding
 https://gitweb.torproject.org/translation.git/ branch, and only build when
 a commit is pushed to lektor itself.
 * Remove extra languages in staging and develop, and lea

Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201912  |  Actual Points:
Parent ID:| Points:
 Reviewer:  gk|Sponsor:
--+

Comment (by JeremyRand):

 Updated branch at https://notabug.org/JeremyRand/tor-browser-
 build/src/namecoin-v7 (Git commit hash
 `a1f4951bf1accf446e90423c34b5401b93f1ea3d`).  `SIGINT` and `SIGTERM`
 should now be trapped, and will result in Namecoin's processes being
 killed.  As discussed on IRC, we'll come back to the periodic reconnect
 issue after we've verified that the signal trapping works as expected.

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

Re: [tor-bugs] #32053 [Applications/Tor Browser]: Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM optimization issue)

[Tor Bug Tracker & Wiki]

#32053: Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM
optimization issue)
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  tbb-9.0-must, tbb-9.0-issues, tbb-   |  Actual Points:  14.5
  regression, tbb-9.0.1-can, |
  TorBrowserTeam201912R, GeorgKoppen201912,  |
  tbb-backport   |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-
Changes (by boklm):

 * keywords:
 tbb-9.0-must, tbb-9.0-issues, tbb-regression, tbb-9.0.1-can,
 TorBrowserTeam201912R, GeorgKoppen201912
 =>
 tbb-9.0-must, tbb-9.0-issues, tbb-regression, tbb-9.0.1-can,
 TorBrowserTeam201912R, GeorgKoppen201912, tbb-backport
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Thanks, I merged it to master as commit
 5cafc16c0e5af59f95f685025b487b306c10bd01. I'm adding the tbb-backport
 keyword as we probably want to backport this to the stable branch.

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

Re: [tor-bugs] #32053 [Applications/Tor Browser]: Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM optimization issue)

[Tor Bug Tracker & Wiki]

#32053: Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM
optimization issue)
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  tbb-9.0-must, tbb-9.0-issues, tbb-   |  Actual Points:  14.5
  regression, tbb-9.0.1-can, |
  TorBrowserTeam201912R, GeorgKoppen201912   |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-
Changes (by gk):

 * status:  needs_revision => needs_review
 * reviewer:   => boklm


Comment:

 `bug_32053_v7` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_32053_v7&id=5cafc16c0e5af59f95f685025b487b306c10bd01)
 has the fix, thanks.

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

[tor-bugs] #32748 [Applications/Tor Browser]: Show the Tor Browser version number on f-droid (instead of firefox version)

[Tor Bug Tracker & Wiki]

#32748: Show the Tor Browser version number on f-droid (instead of firefox 
version)
--+
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It seems that some users are confused by the version number that is shown
 on f-droid:
 https://blog.torproject.org/comment/285989#comment-285989

 It looks like the version number that is shown is the Firefox version on
 which it is based, instead of the Tor Browser version.

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

Re: [tor-bugs] #32520 [Applications/Tor Browser]: Output of go project contains nonreproducible datetime values

[Tor Bug Tracker & Wiki]

#32520: Output of go project contains nonreproducible datetime values
+--
 Reporter:  JeremyRand  |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201912R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  boklm   |Sponsor:
+--
Changes (by boklm):

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


Comment:

 Replying to [comment:9 JeremyRand]:
 > Fix at https://notabug.org/JeremyRand/tor-browser-build/src
 /reproducible-go (Git commit hash
 `0ab49005efd962074e80cafb52fe4dd9cb286229`).  Tested to work fine for the
 linux-x86_64 target (builds without errors and the resulting Tor Browser
 connects to obfs4 without issues).  I can't think of any reason it would
 cause problems for other targets, but haven't tested on them yet.  A side
 benefit is that it decreases the size of the `go` project's output by
 circa 34 MiB.

 This looks good to me, thanks. I merged it to master with commit
 0c7a319ca0be61832c3c1d0cec769f0feb089c8d.

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

Re: [tor-bugs] #32739 [Applications/Tor Browser]: Bump clang to 8.0.1

[Tor Bug Tracker & Wiki]

#32739: Bump clang to 8.0.1
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201912R,   |  Actual Points:  0.2
  GeorgKoppen201912  |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-
Changes (by boklm):

 * reviewer:   => boklm


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

Re: [tor-bugs] #32739 [Applications/Tor Browser]: Bump clang to 8.0.1

[Tor Bug Tracker & Wiki]

#32739: Bump clang to 8.0.1
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201912R,   |  Actual Points:  0.2
  GeorgKoppen201912  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 This looks good to me. I merged it to master with commit
 7e179ed051a63e5a1ce163ce4facc0a616f0a99a.

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

Re: [tor-bugs] #32747 [Metrics/CollecTor]: Avoid reprocessing webstats files

[Tor Bug Tracker & Wiki]

#32747: Avoid reprocessing webstats files
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * status:  assigned => needs_review


Comment:

 I spent pretty much the whole week on this ticket to understand what
 exactly the current code is doing, writing tests for it, figuring out why
 tests broke due to using a security manager (!), and finally coding a
 patch that does what this ticket is about.

 I obviously didn't run this code on the server yet, but I expect that
 runtime of this module will shrink from 45 minutes every six hours to
 something around 10 minutes. And maybe we're lucky and it resolves #31901
 for us, though I didn't look into that yet.

 Please review:
  - [https://gitweb.torproject.org/user/karsten/metrics-
 base.git/commit/?h=task-32747&id=264e498f54a20f7d299daaf2533d043f880e6a8b
 metrics-base commit 264e498] which resolves a  rather unexpected issue
 with executing tests,
  -
 
[https://gitweb.torproject.org/user/karsten/collector.git/commit/?h=task-32747&id=d5ca95a2bb74410004f5c4c93270f3fd90475068
 CollecTor commit d5ca95a] which adds some real tests for the webstats
 module, which I found useful before making substantial changes to code I
 didn't write myself, and
  -
 
[https://gitweb.torproject.org/user/karsten/collector.git/commit/?h=task-32747&id=d7117f8c8ee946748eea4d2f2741195d4dbfe056
 CollecTor commit d7117f8] which resolves the actual issue of avoiding to
 reprocess webstats files.

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

Re: [tor-bugs] #32053 [Applications/Tor Browser]: Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM optimization issue)

[Tor Bug Tracker & Wiki]

#32053: Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM
optimization issue)
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  tbb-9.0-must, tbb-9.0-issues, tbb-   |  Actual Points:  14.5
  regression, tbb-9.0.1-can, |
  TorBrowserTeam201912R, GeorgKoppen201912   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  needs_review => needs_revision
 * actualpoints:  11.5 => 14.5


Comment:

 Replying to [comment:53 gk]:
 > `bug_32053_v5` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_32053_v5&id=b3863530eb585d849a1de0e4eba6690e589954e6)
 is up for review.

 There is a typo in the commit message:
 {{{
 the vast majority of different builds we good
 }}}
 good -> got ?

 Other than this, this looks good to me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32747 [Metrics/CollecTor]: Avoid reprocessing webstats files

[Tor Bug Tracker & Wiki]

#32747: Avoid reprocessing webstats files
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Web servers typically provide us with the last 14 days of request logs. We
 shouldn't process the whole 14 days over and over. Instead we should only
 process new logs files and any other log files containing log lines from
 newly written dates.

 In some cases web servers stop serving a given virtual host or stop acting
 as web server at all. However, in these cases we're left with 14 days of
 logs per virtual host. Ideally, these logs would get cleaned up, but until
 that's the case, we should at least not reprocess these files over and
 over.

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

Re: [tor-bugs] #32741 [Applications/Tor Browser]: CMake repository moved

[Tor Bug Tracker & Wiki]

#32741: CMake repository moved
+--
 Reporter:  sysrqb  |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201912R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  gk  |Sponsor:
+--
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201912 => tbb-rbm,
   TorBrowserTeam201912R
 * status:  needs_review => closed
 * resolution:   => fixed
 * reviewer:  boklm => gk


Comment:

 (stealing this from boklm's growing review plate) Looks good to me and
 works. Merged to `master` (commit
 8f723ac38a8b715adcffe978fcfba70c0f499dd0) and cherry-picked to `maint-9.0`
 (commit 13bd5905aca8765316b352478544f16bfdffad48).

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

Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201912  |  Actual Points:
Parent ID:| Points:
 Reviewer:  gk|Sponsor:
--+

Comment (by JeremyRand):

 @gk Okay, so it was pretty easy to fix the issue where Ctrl+C didn't shut
 down Namecoin.  Just had to trap `SIGINT` in `start-tor-browser` to
 terminate the Namecoin processes.  Thanks for catching that.  Before I
 push a fix to a new branch, are there any other signals I should trap
 besides `SIGINT` (so that Namecoin gets shut down properly)?  I'm thinking
 `SIGTERM` would also be a good idea.  Any others I'm missing?

 Regarding the `STREAM` events that are showing up in your log: upstream
 Electrum periodically tries to reconnect to servers if they're down or got
 disconnected.  I'm pretty sure that's what's happening here; the ElectrumX
 server at `ulrichard.ch` is down for maintenance at the moment, and I
 think Electrum-NMC is trying periodically to connect to it in case it's
 come back up.  I'll look at the relevant code shortly and figure out
 whether there's a way we can reduce the impact this has.  That said, some
 initial thoughts:

 * Not reconnecting periodically at all will have bad effects, because
 Electrum-NMC launches before Tor has connected, so all the ElectrumX
 servers will appear to be unreachable when Electrum-NMC initially
 launches.
 * The above condition is probably fairly easy to detect, because *none* of
 the servers will be currently connected when Tor isn't connected yet.  So
 we could plausibly make the reconnect frequency high when no servers are
 connected, but much lower when at least 1 server is already connected.
 * We could also lower the reconnect frequency for a given server if that
 server has failed to connect multiple times while at least 1 other server
 was connected.  This might help us distinguish between a server failing to
 connect due to a bad Tor circuit versus a server failing to connect
 because the server is actually unreachable.
 * I'm not sure what lower reconnect frequency we should fall back to when
 at least 1 connection is already established and a given server has been
 unreachable multiple times.  There's a tradeoff here, because more server
 connections means it's less likely that we'll be fed a bad blockchain, but
 connecting too aggressively will put more load on the Tor network.
 * I'm honestly not sure why upstream Electrum is so aggressive at
 reconnecting (or if maybe I accidentally made it more aggressive while
 patching the network code for Namecoin/Tor purposes)... depending on what
 fixes we go with here, I might submit them upstream to Electrum too.

 Curious what your take is on the above suggested changes, or if you think
 there's some other approach I should look into.

 (FWIW, I can't reproduce the original issue where the domains were
 unreachable.  But let's come back to that after we've got the other issues
 dealt with.)

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

Re: [tor-bugs] #32745 [Internal Services/Service - jenkins]: lektor jenkins builds fail randomly

[Tor Bug Tracker & Wiki]

#32745: lektor jenkins builds fail randomly
-+
 Reporter:  emmapeel |  Owner:  weasel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  lektor, web  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by weasel):

 jenkinks-tools  8ad41b sets HOME for the lektor stuff to a tmpdir.

 Now concurrent builds no longer share the python site-packages info:
 {{{
 # find /tmp/tm*/home
 /tmp/tmp.7UypLqro5b/home
 /tmp/tmp.7UypLqro5b/home/.local
 /tmp/tmp.7UypLqro5b/home/.local/lib
 /tmp/tmp.7UypLqro5b/home/.local/lib/python3.7
 /tmp/tmp.7UypLqro5b/home/.local/lib/python3.7/site-packages
 /tmp/tmp.7UypLqro5b/home/.local/lib/python3.7/site-packages/lektor-txt-to-
 html.egg-link
 /tmp/tmp.7UypLqro5b/home/.local/lib/python3.7/site-packages/easy-
 install.pth
 /tmp/tmp.7UypLqro5b/home/.local/lib/python3.7/site-packages/lektor-xml-to-
 html.egg-link
 /tmp/tmp.9kNUTya0wa/home
 /tmp/tmp.9kNUTya0wa/home/.local
 /tmp/tmp.9kNUTya0wa/home/.local/lib
 /tmp/tmp.9kNUTya0wa/home/.local/lib/python3.7
 /tmp/tmp.9kNUTya0wa/home/.local/lib/python3.7/site-packages
 /tmp/tmp.9kNUTya0wa/home/.local/lib/python3.7/site-packages/lektor-txt-to-
 html.egg-link
 /tmp/tmp.9kNUTya0wa/home/.local/lib/python3.7/site-packages/easy-
 install.pth
 /tmp/tmp.9kNUTya0wa/home/.local/lib/python3.7/site-packages/lektor-xml-to-
 html.egg-link
 /tmp/tmp.RBYYoD4eKB/home
 }}}

 This might fix that issue.

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

Re: [tor-bugs] #32746 [Internal Services/Service - jenkins]: translations repo and jenkins: reduce builds

[Tor Bug Tracker & Wiki]

#32746: translations repo and jenkins: reduce builds
-+
 Reporter:  emmapeel |  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  lektor, l10n, jenkins|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by emmapeel:

Old description:

> i have been thinking on how to use our resources more wisely regarding
> the translations and the websites.
>
> At this moment we are building many branches anew each time we push
> changes to our translations repository.
>
> This results on a situation when if there is people translating the
> support portal to Malayalam, which is still not published, and therefore
> making changes to the translation repository, the website is rebuild
> several times when there have been no actual changes to it.
>
> On the other hand, the quick updates are very useful for translators, and
> they use the staging version of the site a lot, since most of the
> translators work happens _before_ the website is released.
>
> But the lots of updates from translators and the amount of yet-incomplete
> languages that are built on the staging site causes some trouble to other
> web developers and confuses they development.
>
> So I propose the following scheduling in lektor-jenkins-translation
> branches:
>
> master/staging/develop ---> when there is a change on this branches,
> we pull the translation repo and update
> together
>
> translations   ---> we rebuild when there are changes on the
> branch
> AND changes on the translation repo branch as
> well
>
> If we would want to update the translations in branches
> master/staging/develop, we should be able to do it simply by building
> from the web interface or similar.
>

> This way we can reduce the builds and make development less cumbersome,
> while also providing a quick preview of their changes to active
> translators.

New description:

 i have been thinking on how to use our resources more wisely regarding the
 translations and the websites.

 At this moment we are building many branches anew each time we push
 changes to our translations repository.

 This results on a situation when if there is people translating the
 support portal to Malayalam, which is still not published, and therefore
 making changes to the translation repository, the website is rebuild
 several times when there have been no actual changes to it.

 On the other hand, the quick updates are very useful for translators, and
 they use the staging version of the site a lot, since most of the
 translators work happens _before_ the website is released.

 But the lots of updates from translators and the amount of yet-incomplete
 languages that are built on the staging site causes some trouble to other
 web developers and confuses tehir development, also it makes staging hard
 to update regarding master because of the language configurations, etc.

 So I propose the following scheduling in lektor-jenkins-translation
 branches:

 master/staging/develop ---> when there is a change on this branches,
 we pull the translation repo and update all
 together

 translations   ---> we rebuild when there are changes on the
 branch
 AND changes on the translation repo branch as
 well

 If we would want to update the translations in branches
 master/staging/develop, we should be able to do it simply by building from
 the web interface or similar.

 This way we can reduce the builds and make development less cumbersome,
 while also providing a quick preview of their changes to active
 translators.

 We can also prevent accidentally publishing incomplete languages, or
 removing languages from the 'preview' website.

--

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

Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201912  |  Actual Points:
Parent ID:| Points:
 Reviewer:  gk|Sponsor:
--+

Comment (by JeremyRand):

 Interesting @gk.  I'll see if I can reproduce this on my end.  I'm not
 sure if I tested quitting Tor Browser via Ctrl+C; I suspect that's likely
 to be the source of at least some of the breakage you're observing [1].
 I'll report back shortly.

 [1] Of course, the code that's likely to be responsible for that breakage
 will be phased out anyway once we move launching Namecoin to tor-launcher
 instead of the Bash script.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32746 [Internal Services/Service - jenkins]: translations repo and jenkins: reduce builds

[Tor Bug Tracker & Wiki]

#32746: translations repo and jenkins: reduce builds
-+-
 Reporter:  emmapeel |  Owner:  weasel
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  jenkins|   Keywords:  lektor,
 Severity:  Normal   |  l10n, jenkins
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 i have been thinking on how to use our resources more wisely regarding the
 translations and the websites.

 At this moment we are building many branches anew each time we push
 changes to our translations repository.

 This results on a situation when if there is people translating the
 support portal to Malayalam, which is still not published, and therefore
 making changes to the translation repository, the website is rebuild
 several times when there have been no actual changes to it.

 On the other hand, the quick updates are very useful for translators, and
 they use the staging version of the site a lot, since most of the
 translators work happens _before_ the website is released.

 But the lots of updates from translators and the amount of yet-incomplete
 languages that are built on the staging site causes some trouble to other
 web developers and confuses they development.

 So I propose the following scheduling in lektor-jenkins-translation
 branches:

 master/staging/develop ---> when there is a change on this branches,
 we pull the translation repo and update
 together

 translations   ---> we rebuild when there are changes on the
 branch
 AND changes on the translation repo branch as
 well

 If we would want to update the translations in branches
 master/staging/develop, we should be able to do it simply by building from
 the web interface or similar.


 This way we can reduce the builds and make development less cumbersome,
 while also providing a quick preview of their changes to active
 translators.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32745 [Internal Services/Service - jenkins]: lektor jenkins builds fail randomly

[Tor Bug Tracker & Wiki]

#32745: lektor jenkins builds fail randomly
-+-
 Reporter:  emmapeel |  Owner:  weasel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  jenkins|
 Severity:  Normal   |   Keywords:  lektor, web
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 this may be a duplicate of
 https://trac.torproject.org/projects/tor/ticket/30435 but maybe there are
 more reasons why builds fail with 'Undefined error'.

 at the moment there are many errors on the jenkins builds, that are not
 related to the actual pushes to the repo. This amount of false positives
 makes people not to care about broken builds, and I guess it also wastes
 some human and computing resources.

 please see a way to make jenkins not to fail for reasons that are not
 related to the code being submitted.

 i have been saving some of the errors but they seem outdated and
 unaccessible now, i leave them as a grepping example:
 https://pad.riseup.net/p/jenkins-false-positives-keep

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

Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201912  |  Actual Points:
Parent ID:| Points:
 Reviewer:  gk|Sponsor:
--+
Changes (by gk):

 * Attachment "log" added.


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

Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201912  |  Actual Points:
Parent ID:| Points:
 Reviewer:  gk|Sponsor:
--+

Comment (by gk):

 Replying to [comment:49 JeremyRand]:
 > > JeremyRand: Are those domains you mentioned in comment:7 still up and
 running? None of them works for me. If not, where are domains that are
 supposed to be up and working?
 >
 > @gk All 4 of those domains work fine for me as of just now.  Just to
 verify, you're running the GNU/Linux nightly build with the environment
 variable `TOR_ENABLE_NAMECOIN=1`, right?  Are you on x86_64 or i686?  What
 version of Python is installed?  Can you provide the output that you get
 if you run Tor Browser from a terminal with the `--verbose` flag, and then
 try to visit one of the 4 domains I listed?

 That's been with a custom build which is nightly-ish, yes. Python 3.7.5
 with `TOR_ENABLE_NAMECOIN=1`. I try to reproduce the issue but meanwhile
 another problem I've seen is that Namecoin enabled is sometimes hammering
 the Tor network with stream creations like attached in the log which is
 very concerning. The latter at least could be related to Namecoin not
 properly shutting down when I close the browser e.g. by pressing Ctrl+C in
 my terminal. The result is that I can't stop the remaining Python process
 by either pressing Ctrl+C further or closing the terminal. Additionally,
 it has the interesting property that it messes with a newly started Tor
 Browser in a new terminal even though `TOR_ENABLE_NAMECOIN` is *not* set
 there, rendering that Tor Browser non-functional and one can see requests
 to `ulrichard.ch` in that terminal. That's not supposed to happen.

 So, at the end my trouble connecting to a .bit domain might result in the
 above bug but I am not sure yet.

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

Re: [tor-bugs] #21483 [Applications/Tor Browser]: DuckDuckGo Onion should be the default instead of DuckDuckGo

[Tor Bug Tracker & Wiki]

#21483: DuckDuckGo Onion should be the default instead of DuckDuckGo
--+
 Reporter:  lolscreen |  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, TorBrowserTeam202001  |  Actual Points:
Parent ID:| Points:  0.25
 Reviewer:|Sponsor:
--+
Changes (by intrigeri):

 * cc: intrigeri (added)


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

[tor-bugs] #32744 [Applications/Tor Browser]: Torbrowser on Android crashes on visiting a page

[Tor Bug Tracker & Wiki]

#32744: Torbrowser on Android crashes on visiting a page
---+--
 Reporter:  WerHaus|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Applications/Tor Browser
  Version:  sbws: unspecified  |   Severity:  Normal
 Keywords:  tbb-mobile, crash  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 The torbrowser for android in the f-droid guardian repository crashes
 on visiting a page of one of the biggest broadcasters in austria.

 Steps to reproduce:

  * Between 8:00 and 8:15 CET visit the page https://oe1.orf.at/player
  * Wait until the page is loaded
  * Select the news-broadcast of that day 7:00 CET.
  * Torbrowser crashes most of the time while loading the page.

 This is true for the security settings "standard" and "secure".

 This was tested on two mobiles.
 Spec of first mobile:
 - Android 7.1
 - fresh install of "Tor Browser" 68.3.0 (2015620379) arm64-v8a from
 Guardian Project
 - or fresh install of "Tor Browser Alpha" 68.3.0 (2015621155) arm64-v8a
 from Guardian Project

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