Tails

#1 Updated by intrigeri 2019-01-06 07:02:56

• Status changed from New to Confirmed

(Otherwise the ticket land onto Help Desk’s triaging plate and I doubt they’ll be in a better position than you to triage this one :)

#2 Updated by intrigeri 2019-04-02 15:40:30

• Affected tool set to OnionShare

#3 Updated by intrigeri 2019-04-02 15:40:59

• Assignee set to intrigeri

Looks like this is AppArmor stuff.

#4 Updated by intrigeri 2019-04-02 18:51:16

• Status changed from Confirmed to In Progress

Applied in changeset commit:tails|85d3f210804b69d675125b7d9e74753662009065.

#5 Updated by intrigeri 2019-04-02 18:52:39

• Assignee changed from intrigeri to anonym
• % Done changed from 0 to 50
• QA Check set to Ready for QA

Fixed on feature/buster but I’d like a second pair of eyes to take a look, especially @anonym who did the initial OnionShare integration and is the Great Master of the Onion Grater™ :)

#6 Updated by anonym 2019-04-02 20:21:23

• Assignee changed from anonym to intrigeri
• % Done changed from 50 to 80
• QA Check changed from Ready for QA to Info Needed

I briefly checked onion-grater’s --debug mode and the committed changes indeed seem necessary, and the AppArmor profile change is straightforward. So LGTM!

I wonder, how you did you construct onionshare.json? It doesn’t look like the minimal config we could get away with (e.g. close_after_first_download). I’m just thinking that if upstream changes the default of some unrelated option (e.g. close_after_first_download) we’d lose out, which seems like a bad idea.

#7 Updated by intrigeri 2019-04-03 09:18:30

• Assignee changed from intrigeri to anonym
• QA Check changed from Info Needed to Ready for QA

> I wonder, how you did you construct onionshare.json?

I’ve started OnionShare GUI, clicked a couple things needed to make it work in Tails, saved the config, reformatted it a little (by default it’s one single line) and committed.

> It doesn’t look like the minimal config we could get away with

You’re fully right.

> I’m just thinking that if upstream changes the default of some unrelated option (e.g. close_after_first_download) we’d lose out, which seems like a bad idea.

I’ve considered this before committing. I had to balance:

• Hard-coding current defaults ⇒ risk of missing future useful change of defaults, as you said.
• Shipping a minimal configuration ⇒ risk of OnionShare dismissing some of the settings we’ve customized because the config file is not considered to be a complete, valid one.

I had a hard time deciding which one was worse between these 2 risks. I picked the 1st one because:

• The settings we’ve hard-coded here won’t become suddenly wrong because upstream change their mind wrt. what the default behavior should be.
• I’m wary in general of how software behaves when one fiddles manually with its configuration outside of the GUI.
• It would take time to find out what exact minimal config would work and how OnionShare will merge it with the defaults we would not set ourselves. I don’t think it’s worth it considering the risk it introduces vs. the risk it mitigates.

#8 Updated by anonym 2019-04-04 10:35:12

• Status changed from In Progress to Fix committed
• Assignee deleted (anonym)
• % Done changed from 80 to 100
• QA Check changed from Ready for QA to Pass

Sound legit to me. Closing!

#9 Updated by intrigeri 2019-04-05 10:56:12

• Status changed from Fix committed to Resolved