Project

General

Profile

Bug #16024

Maybe fix getTorBrowserUserAgent

Added by anonym about 1 month ago. Updated 8 days ago.

Status:
Fix committed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
10/03/2018
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
bugfix/16024-remove-getTorBrowserUserAgent
Type of work:
Code
Blueprint:
Starter:
Affected tool:


Related issues

Blocks Tails - Feature #15506: Core work 2018Q4: Foundations Team Confirmed 04/08/2018
Blocked by Tails - Bug #15912: Deal with getTorBrowserUserAgent not being reliable anymore Resolved 09/05/2018

Associated revisions

Revision 9c9aeab1 (diff)
Added by segfault 20 days ago

Remove packages which were needed for getTorBrowserUserAgent (refs: #16024)

Revision e8b0ab9e (diff)
Added by segfault 20 days ago

Update test to check content of /etc/default/htpdate.user-agent (refs: #16024)

Revision c07a205e
Added by intrigeri 8 days ago

Merge remote-tracking branch 'origin/bugfix/16024-remove-getTorBrowserUserAgent' into stable (Fix-committed: #16024)

History

#1 Updated by anonym about 1 month ago

#2 Updated by intrigeri about 1 month ago

  • Assignee set to intrigeri

I'll take a look.

#3 Updated by intrigeri about 1 month ago

  • Related to Bug #15912: Deal with getTorBrowserUserAgent not being reliable anymore added

#4 Updated by segfault about 1 month ago

Let's just duplicate the Tor Browser user-agent string, which hasn't
changed for years (and likely won't for a loooooong time).

Actually, it did change in Tor Browser 8 and then was reverted in 8.0.2, see https://trac.torproject.org/projects/tor/ticket/26146.

#5 Updated by intrigeri about 1 month ago

I dislike the fact 333e74ae56a67e310dcf6c1a1b6baebca47474ef hard-codes a value without setting up a process to update it. But whatever, let's first discuss on #15912 what we want to do with that script.

#6 Updated by intrigeri about 1 month ago

  • Assignee changed from intrigeri to segfault
  • QA Check set to Info Needed

Same as #15912, I'll let segfault decide what's best.

#7 Updated by anonym about 1 month ago

intrigeri wrote:

I dislike the fact 333e74ae56a67e310dcf6c1a1b6baebca47474ef hard-codes a value without setting up a process to update it.

Sorry, I needed a fast solution and thought opening this ticket would be enough as opposed to device a full solution on the spot.

#8 Updated by intrigeri about 1 month ago

intrigeri wrote:

I dislike the fact 333e74ae56a67e310dcf6c1a1b6baebca47474ef hard-codes a value without setting up a process to update it.

Sorry, I needed a fast solution and thought opening this ticket would be enough as opposed to device a full solution on the spot.

Sure, fully understood, and thanks for opening a ticket so this remains on our radar! :)

By the way, just curious: to what problem did this solve?

#9 Updated by anonym about 1 month ago

intrigeri wrote:

intrigeri wrote:

I dislike the fact 333e74ae56a67e310dcf6c1a1b6baebca47474ef hard-codes a value without setting up a process to update it.

Sorry, I needed a fast solution and thought opening this ticket would be enough as opposed to device a full solution on the spot.

Sure, fully understood, and thanks for opening a ticket so this remains on our radar! :)

I now realize how defensive I sounded. My intention was just to explain my reasoning, which always is patchable. :)

By the way, just curious: to what problem did this solve?

It's pretty bad actually! htpdate (or just its systemd unit file) failed to start with an empty user-agent string set in /etc/default/htpdate.user-agent, which is pretty serious in itself since it breaks parts of our time syncing, but it also breaks all automated tests depending the Tor is ready step (which was how I detected it).

#10 Updated by intrigeri about 1 month ago

It's pretty bad actually! htpdate (or just its systemd unit file) failed to start with an empty user-agent string set in /etc/default/htpdate.user-agent, which is pretty serious in itself since it breaks parts of our time syncing, but it also breaks all automated tests depending the Tor is ready step (which was how I detected it).

Aaaah, that's why htpdate was failing. I somewhat guessed your commit fixed that but I was not sure.

#11 Updated by segfault 30 days ago

  • Related to deleted (Bug #15912: Deal with getTorBrowserUserAgent not being reliable anymore)

#12 Updated by segfault 30 days ago

  • Blocked by Bug #15912: Deal with getTorBrowserUserAgent not being reliable anymore added

#13 Updated by intrigeri 29 days ago

I think there'll be nothing to do here once #15912 is merged.

#14 Updated by intrigeri 21 days ago

  • Target version changed from Tails_3.10.1 to Tails_3.11

#15 Updated by segfault 21 days ago

  • Status changed from Confirmed to Resolved
  • Assignee deleted (segfault)
  • Target version deleted (Tails_3.11)
  • QA Check deleted (Info Needed)

I think this was solved by #15912, no?

#16 Updated by intrigeri 21 days ago

  • Status changed from Resolved to In Progress
  • Assignee set to segfault
  • Target version set to Tails_3.11

segfault wrote:

I think this was solved by #15912, no?

Almost! We're still shipping getTorBrowserUserAgent but during the manual testing session, it was reported that it does not work anymore => one needs to:

  • check whether this script is still used anywhere and if not, drop it
  • update the corresponding manual test to check that the content of /etc/default/htpdate.user-agent matches Tor Browser's user agent

#17 Updated by segfault 20 days ago

  • Assignee changed from segfault to intrigeri
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/16024-remove-getTorBrowserUserAgent

We're still shipping getTorBrowserUserAgent

Actually, no, I already removed it in fed6918f2c33cb5abb758ec8aeac009929d7403e.

update the corresponding manual test to check that the content of /etc/default/htpdate.user-agent matches Tor Browser's user agent

I did this on the feature branch. I also removed the unzip package, which was needed by getTorBrowserUserAgent, and at least a git grep suggests that it isn't used anywhere else.

#18 Updated by segfault 20 days ago

  • Assignee changed from intrigeri to segfault
  • QA Check deleted (Ready for QA)

Let's see whether the test suite passes without unzip before passing this to QA

#19 Updated by segfault 8 days ago

  • Assignee changed from segfault to intrigeri
  • QA Check set to Ready for QA

test suite passes

#20 Updated by intrigeri 8 days ago

segfault wrote:

I also removed the unzip package, which was needed by getTorBrowserUserAgent, and at least a git grep suggests that it isn't used anywhere else.

Confirmed (grep'ed for each executable shipped by the unzip package, verified that unzip does not pull any dependency on which we ourselves depend).

#21 Updated by intrigeri 8 days ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 0 to 100

#22 Updated by intrigeri 8 days ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

Also available in: Atom PDF