Tails

#1 Updated by anonym 2017-06-09 14:14:03

• Status changed from Confirmed to In Progress
• Assignee changed from anonym to intrigeri
• Target version changed from Tails_3.0 to Tails_3.2
• % Done changed from 0 to 30
• QA Check set to Info Needed
• Type of work changed from Test to Code

I’ve run Tor Browser 7.0 as-is (on testing) while looking at the network activity via tcpdump. No network activity occurs when the audit permission issue for UpdateInfo is logged. Also, the About -> Tor Browser dialog’s “Check for updates” button doesn’t work — we should get progress feedback in the GUI when the check is performed, but we get nothing.

If I create that folder, then I can see network traffic related to the update and the GUI does show the expected progress spinner. I still don’t see any automatic update check on start, so presumably there’s some other code path that makes sure that this directory exists on start, without issuing an actual update check.

This suggests to me that blocking the creation of that directory is an extra, hardcore way to disable updates, and a very casual look at the Tor Browser source code didn’t turn up anything opposing this theory.

So, IMHO we’re good for 3.0 => post-poning (intrigeri, please just ACK me and reassign back, unless you disagree).

So what are the next step? Do we want to support the About Tor Browser dialog’s manual update check (which leads to failure)? I guess not, so that’s no a regression then. Ideally I guess we’d want to hide that button too, but I don’t think it’s high prio. If we want to make the journal less noisy we should instead just explicitly deny that directory in the AppArmor profile so we don’t get this audit log entry each start.

#2 Updated by intrigeri 2017-06-09 14:52:12

• Assignee changed from intrigeri to anonym

> So, IMHO we’re good for 3.0 => post-poning (intrigeri, please just ACK me and reassign back, unless you disagree).

ACK

> So what are the next step? Do we want to support the About Tor Browser dialog’s manual update check (which leads to failure)?

No.

> I guess not, so that’s no a regression then. Ideally I guess we’d want to hide that button too, but I don’t think it’s high prio.

That’s very low-prio indeed.

> If we want to make the journal less noisy we should instead just explicitly deny that directory in the AppArmor profile so we don’t get this audit log entry each start.

Yes, please :)

#3 Updated by intrigeri 2017-06-10 14:45:10

• Parent task deleted (Feature #12635)

#4 Updated by intrigeri 2017-06-29 10:33:11

• blocks Feature #13234: Core work 2017Q3: Foundations Team added

#5 Updated by intrigeri 2017-09-07 08:40:16

• Status changed from In Progress to Resolved
• % Done changed from 30 to 100

So we’re done here. I’ve created Bug #14606 to track the next action.