Tails

#1 Updated by intrigeri 2019-01-12 14:59:21

• related to Bug #16349: Stick to Tor 0.3.4 in Tails 3.12 added

#2 Updated by intrigeri 2019-01-12 15:00:51

• blocks Feature #15507: Core work 2019Q1: Foundations Team added

#3 Updated by intrigeri 2019-01-12 15:18:04

• Status changed from Confirmed to In Progress

Applied in changeset commit:tails|3d88e030ca9aac8348b46d08c4994c19b2bb607e.

#4 Updated by intrigeri 2019-01-13 18:08:59

• Subject changed from Upgrade to Tor 0.3.5 to Upgrade to tor 0.3.5
• Description updated

#5 Updated by hefee 2019-02-06 15:37:47

• Assignee set to hefee

#6 Updated by hefee 2019-02-11 10:27:42

• Feature Branch set to bugfix/16349-tor-0.3.4+force-all-tests

#7 Updated by intrigeri 2019-02-11 11:03:56

• Feature Branch deleted (bugfix/16349-tor-0.3.4+force-all-tests)

#8 Updated by hefee 2019-02-14 12:51:25

• Feature Branch set to hefee/bugfix/16349-tor-0.3.5+force-all-tests

tested with tor 0.3.5.7-1~d90.stretch+1 by hand successfully:
[x] onionshare
[x] gobby
[x] onion circuits
[x] Tor Browser
[x] Thunderbird (only connection via IMAP, not the whole sending, PGP etc.)

#15 Updated by hefee 2019-02-17 14:40:00

• related to Bug #16471: Drop time synchronization hacks that tor 0.3.5 and 0.4.x made obsolete added

#16 Updated by hefee 2019-02-17 14:49:20

• Description updated
• Assignee deleted (hefee)
• QA Check set to Ready for QA

pidgin now successfully connects to IRC and XMPP. So this is ready for QA.

One issue so far:

Jenkins fails for “Time syncing ǂ Clock is one day in the future in bridge mode” but only for build #3:

https://jenkins.tails.boum.org/job/test_Tails_ISO_hefee-bugfix-16349-tor-0.3.5-force-all-tests/lastCompletedBuild/cucumberTestReport/time-syncing/clock-is-one-day-in-the-future-in-bridge-mode/

I created an upstream bugreport for pidgin to fix the need for user/pass:

https://developer.pidgin.im/ticket/17380

(as curl is able to use tor as SOCKS5 proxy without user/pass).

#17 Updated by intrigeri 2019-02-18 15:20:57

• Assignee set to intrigeri

#19 Updated by intrigeri 2019-02-18 16:10:47

• Assignee changed from intrigeri to hefee
• QA Check changed from Ready for QA to Dev Needed

> pidgin now successfully connects to IRC and XMPP. So this is ready for QA.

Glad to see progress here.

A solution based on modifying /etc/skel/.purple/prefs.xml will only avoid breakage for non-persistent Pidgin config and for persistent Pidgin config created with Tails 3.13. But any pre-existing persistent Pidgin config won’t benefit from this change. So our options are:

1. Ideally, find a solution that does not require editing the Pidgin config at all. For example:
   1. Some network software will honor $SOCKS5_USER and $SOCKS5_PASSWORD. I don’t know if that’s the case here but if it can be made to work, this would be ideal.
   2. If this is really a bug in Pidgin (that for some reason is triggered by updating tor, while it worked fine before): fix Pidgin. It hasn’t been updated in stable since the Stretch release so shipping a patched package does not seem too scary in terms of maintenance cost.
   3. Now that you have this additional constraint in mind, perhaps your unleashed imagination will find another workaround :)
2. If (1) is not possible, then evaluate how feasible it is to update persistent Pidgin config the first time it’s unlocked or used, when booting Tails 3.13+. It’s XML which is never trivial to deal with. I know you’d rather not change users’ config without prompting but this opinion does not match what we’ve done in the past in similar cases, so if you really want to prompt users, please check with sajolida before spending time on writing such code.
3. If (1) is not possible and (2) is too expensive — be it technically or socially — the worst case scenario is that we document in the release notes how affected users must edit their config themselves. That’s pretty bad because, well, many users don’t read release notes, so it’ll inevitably add more work to our help desk’s plate. I don’t know how to compare this additional work and users pain with the work needed by (2).

> One issue so far:
> Jenkins fails for “Time syncing ǂ Clock is one day in the future in bridge mode” but only for build #3:

(Bug #11589 i.e. the reason why this test is marked as fragile.)

> I created an upstream bugreport for pidgin […]

Great! \o/

#20 Updated by hefee 2019-02-20 12:35:50

• Assignee changed from hefee to intrigeri
• QA Check changed from Dev Needed to Info Needed

Okay after digging further into pidgin/tor. I stumbled over:
https://github.com/torproject/tor/commit/790150e57a98221fbb4cfdc5c34b3395808416b4#diff-79be88f1aef796da2f29f8e3b7913f26
that leads me to the issue:
https://trac.torproject.org/projects/tor/ticket/29175

So it is actually a tor issue. I can verify, that I see the same logs in the tor journal. Can you tell if, that will be backported to 0.3.5.8?

How to went on from here?

#21 Updated by intrigeri 2019-02-21 08:27:19

• Assignee changed from intrigeri to hefee
• QA Check changed from Info Needed to Dev Needed

Great research!

> Can you tell if, that will be backported to 0.3.5.8?

Reading the ticket you’ve linked to, it seems the fix has already been backported to the 0.3.5.x branch.

> How to went on from here?

Wait for 0.3.5.8 to be released; I’ll send you more info privately.

#26 Updated by hefee 2019-02-28 11:09:06

• Assignee changed from hefee to intrigeri
• QA Check changed from Dev Needed to Info Needed

I need input for descide how to go on for here.

• is the jabber server SRV records a minor issue and we ship the new tor anyways? IMO think, there at least a quite jabber server out there that uses those records, so it is show stopper.

• does “Remote-DNS over SOCKS4” is relevant for Tails, as far I understood the fundamental setup of Tails DNS is anyways tunneled over tor.

Following solutions:

1. update prefs.xml also for persistence to use SOCKS 4/ without “Remote-DNS over SOCKS4”.
2. ignore the issue with server SRV records.
3. make tor aware of this issue and fix it properly in tor for 0.3.5.X.

I also wanted to mentioned, that I spent now 2h on that ticket, so we have raise the boundary.

#28 Updated by intrigeri 2019-03-04 11:37:56

• Assignee changed from intrigeri to anonym

Actually, anonym will look into this tomorrow.

#29 Updated by anonym 2019-03-05 13:08:31

• Assignee changed from anonym to hefee

hefee wrote:
> I need input for descide how to go on for here.
>
> * is the jabber server SRV records a minor issue and we ship the new tor anyways? IMO think, there at least a quite jabber server out there that uses those records, so it is show stopper.

The only context I have for a “SRV records issue” is what I could find in the log you posted above. If that is all this is about, then there is no regression — Tails uses Tor as resolver, and it doesn’t support SRV queries so Pidgin has never gotten these (well, maybe it did years ago when we used ttdnsd).

> * does “Remote-DNS over SOCKS4” is relevant for Tails, as far I understood the fundamental setup of Tails DNS is anyways tunneled over tor.

A DNS leak in Tails is indeed safe since our system resolver is Torified. IMHO it is still good practice to enable remote DNS when using SOCKS4, but since we are gonna keep on using SOCKS5 (per your comment in Feature #16348#note-23) this settings is irrelevant to us, right?

> Following solutions:
>
> 1. update prefs.xml also for persistence to use SOCKS 4/ without “Remote-DNS over SOCKS4”.

See above! I’m confused!

> 2. ignore the issue with server SRV records.

We’re stuck with 2 for now. I agree it isn’t great, e.g. setting up a RiseUp XMPP account in Tails is pretty awkward since you have to manually configure the “Connect server” as xmpp.riseup.net, which the SRV record would have prevented.

> 3. make tor aware of this issue and fix it properly in tor for 0.3.5.X.

They are aware.

#30 Updated by anonym 2019-03-05 13:26:46

• % Done changed from 0 to 40

anonym wrote:
> hefee wrote:
> > * does “Remote-DNS over SOCKS4” is relevant for Tails, as far I understood the fundamental setup of Tails DNS is anyways tunneled over tor.
>
> A DNS leak in Tails is indeed safe since our system resolver is Torified. IMHO it is still good practice to enable remote DNS when using SOCKS4, but since we are gonna keep on using SOCKS5 (per your comment in Feature #16348#note-23) this settings is irrelevant to us, right?
>
> > Following solutions:
> >
> > 1. update prefs.xml also for persistence to use SOCKS 4/ without “Remote-DNS over SOCKS4”.
>
> See above! I’m confused!

Ah, I think I got it now! I had not paid enough attention to what you said in Feature #16348#note-25. So from what I understand, SOCKS4 + remote-dns actually works around the SRV problem. That is cool! And in retrospect it makes a lot of sense! :)

We definitely should consider your proposal, but please open a new ticket for that. Again, the SRV problem is not a regression caused by Tor 0.3.5.x, so solving it is unrelated to this ticket.

So, as far as I can tell, this ticket should now be ready for a review’n’merge, but I’ll hand it back to you first for verifying/disproving my conclusions above.

#31 Updated by hefee 2019-03-05 16:34:57

• Assignee changed from hefee to anonym

hefee wrote:
> I also wanted to mentioned, that I spent now 2h on that ticket, so we have raise the boundary.

intrigeri: We made the rule, that for each ticket have approved 2h. Those are execeded. The new limit is not discussed atm. Is anonym also in charge to raise the the limit?

anonym wrote:
> So, as far as I can tell, this ticket should now be ready for a review’n’merge, but I’ll hand it back to you first for verifying/disproving my conclusions above.

As the 2h limit is exceeded I havn’t merged/rebuilt the branch again. But as it is in the end only about reverting 3d88e030ca9aac8348b46d08c4994c19b2bb607e that should be fine to give it to review’n’merge.

As I don’t except a lot of discussions around the review’n’merge. It should not take me more then 30min in addition as upper limit.

#33 Updated by hefee 2019-03-05 16:51:11

• related to Feature #16528: Allow Pidgin to use SRV records added

#34 Updated by hefee 2019-03-05 16:52:18

• QA Check changed from Info Needed to Ready for QA

#35 Updated by intrigeri 2019-03-06 07:52:06

• Estimated time set to 2 h

#36 Updated by intrigeri 2019-03-06 07:57:39

• Assignee changed from anonym to hefee
• QA Check changed from Ready for QA to Dev Needed

>> I also wanted to mentioned, that I spent now 2h on that ticket, so we have raise the boundary.

> @intrigeri: We made the rule, that for each ticket have approved 2h. Those are execeded. The new limit is not discussed atm.

@hefee: done. Meta/process: when you write something like “I spent now 2h on that ticket, we have raise the boundary”, please tell me how much extra time you’re requesting (I can’t answer anything conclusive to “we have raise the boundary” itself).

> Is @anonym also in charge to raise the the limit?

No, he’s not.

The branch FTBFS on Jenkins. Please fix that (should be a mere matter of merging current stable into your branch) and check that the test suite results look good enough. In case you missed or lost the link I’ve sent you some time ago: https://tails.boum.org/contribute/merge_policy/#submit :)

#38 Updated by hefee 2019-03-13 11:13:52

• Assignee changed from hefee to intrigeri
• QA Check changed from Dev Needed to Ready for QA

Local merge and Jenkins could build my branch, so I ask for review again.

#39 Updated by intrigeri 2019-03-13 11:44:25

• % Done changed from 40 to 50
• Feature Branch changed from hefee/bugfix/16349-tor-0.3.5+force-all-tests to bugfix/16348-tor-0.3.5+force-all-tests

@hefee, thank you!

I’ve cherry-picked the two relevant commits in a new branch forked off stable: your branch was based on devel (used to prepare major releases), our next major release is 7 months away, and we want this in 3.13.

Then I’ve bumped the serial for the torproject APT snapshot to one that has the version of tor we want and still exists (+ bumped its expiration date). See https://tails.boum.org/contribute/APT_repository/time-based_snapshots/ if you’re interested in the details.

I’ll check Jenkins build & test results before merging.

#40 Updated by intrigeri 2019-03-14 13:57:39

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

Applied in changeset commit:tails|b7a86ad32a5861a41eddab64e0c32db628cfa585.

#41 Updated by intrigeri 2019-03-14 13:58:56

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

Everything looks OK on the Jenkins front, except tests that fail almost all the time these days + a new one (Bug #16555, that affects other branches as well, so not tied to tor 0.3.5).

#42 Updated by intrigeri 2019-03-14 13:59:14

• related to deleted (Feature #16528: Allow Pidgin to use SRV records)

#43 Updated by CyrilBrulebois 2019-03-20 14:27:16

• Status changed from Fix committed to Resolved