Tails

#1 Updated by intrigeri 2018-06-17 07:52:24

• Description updated

#2 Updated by intrigeri 2018-06-17 09:03:31

• related to Bug #15602: Fix EFAIL added

#3 Updated by intrigeri 2018-06-17 15:00:22

• Status changed from Confirmed to In Progress

Applied in changeset commit:8ef9cb8d34569d59a4c42a927fbfc20d6573293b.

#4 Updated by Anonymous 2018-08-16 10:45:58

• related to Bug #15600: Upgrade to Torbirdy 0.2.5 added

#5 Updated by intrigeri 2018-11-17 14:48:12

• Target version changed from Tails_4.0 to Tails_3.12

Actually, torbirdy 0.2.6 made its way into stretch-backports and we have APT pinning in place to fetch it from there, so this might bite us earlier than planned.

#6 Updated by intrigeri 2018-11-17 14:48:29

• blocks Feature #15506: Core work 2018Q4: Foundations Team added

#9 Updated by intrigeri 2018-12-02 21:55:01

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

#10 Updated by intrigeri 2018-12-02 21:55:19

• blocked by deleted (Feature #15506: Core work 2018Q4: Foundations Team)

#11 Updated by intrigeri 2018-12-03 15:47:35

• Assignee deleted (intrigeri)

#12 Updated by hefee 2019-01-04 15:43:57

• Assignee set to hefee

#13 Updated by hefee 2019-01-14 09:43:03

• Feature Branch set to hefee/bugfix/16186-disable-autocrypt+force-all-tests

#14 Updated by hefee 2019-01-14 10:40:09

• QA Check set to Ready for QA

Moved torbidy’s tails configuration into /etc/xul-ext/torbirdy.js and remove the patches.

Tests done on vm by hand:

• register a new account, make sure that the wizard is used
• download one key from keyring via enigmail
• sent an encrypted mail and make sure that the subject is not encrypted.

I bundled Feature #15661, Feature #16299, Feature #15657 and Feature #16222, as a new enigmail version and a new torbirdy version made sense to test together.

#15 Updated by intrigeri 2019-01-14 10:54:47

• Assignee changed from hefee to intrigeri

#16 Updated by intrigeri 2019-01-14 11:54:08

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

Typo: torbridy

Will now test!

#17 Updated by hefee 2019-01-14 12:31:23

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

fixed typo.

#18 Updated by intrigeri 2019-01-14 14:54:53

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

I’ve upgraded a 3.11 USB stick that had a persistent Thunderbird profile + email account already.

The intended version of Torbirdy is installed: 0.2.6-1~bpo9+1. I can still check and send email.

I see two weird things:

• In the Add-ons Manager it claims to be 0.2.5. Same issue for Enigmail, will report on Feature #15657. extensions.json has stuff about 0.2.5 but not about 0.2.6.
• There’s no Torbirdy UI in the status bar while my Thunderbird on sid, with Torbirdy 0.2.6, has it.

But they might be caused by Feature #16222#note-13. Can you reproduce that after fixing that bug?

#19 Updated by hefee 2019-01-14 17:25:58

• QA Check changed from Info Needed to Ready for QA

intrigeri wrote:
> I’ve upgraded a 3.11 USB stick that had a persistent Thunderbird profile + email account already.
>
> The intended version of Torbirdy is installed: 0.2.6-1~bpo9+1. I can still check and send email.
>
> I see two weird things:
>
> * In the Add-ons Manager it claims to be 0.2.5. Same issue for Enigmail, will report on Feature #15657. extensions.json has stuff about 0.2.5 but not about 0.2.6.

With a fresh installation this is not the case.

> * There’s no Torbirdy UI in the status bar while my Thunderbird on sid, with Torbirdy 0.2.6, has it.

I see successfully the status line with a fresh installation. And I do not find anything with the version written to user_prefs, so no idea what is going on here.

> But they might be caused by Feature #16222#note-13. Can you reproduce that after fixing that bug?

not even before with a fresh installation.:D

#20 Updated by hefee 2019-01-14 17:45:13

• Assignee changed from hefee to intrigeri

#21 Updated by intrigeri 2019-01-14 19:44:16

• QA Check changed from Ready for QA to Info Needed

>> * In the Add-ons Manager it claims to be 0.2.5. Same issue for Enigmail, will report on Feature #15657. extensions.json has stuff about 0.2.5 but not about 0.2.6.

> With a fresh installation this is not the case.

Good. I did not expect this would be the case (a fresh installation has simply never heard of Torbirdy 0.2.5).

I’ve reproduced this problem (profile created on 3.11 then upgraded to your branch) with the latest version of your branch.

>> * There’s no Torbirdy UI in the status bar while my Thunderbird on sid, with Torbirdy 0.2.6, has it.

> I see successfully the status line with a fresh installation. And I do not find anything with the version written to user_prefs, so no idea what is going on here.
>
>> But they might be caused by Feature #16222#note-13. Can you reproduce that after fixing that bug?

> not even before with a fresh installation.:D

Same here, reproduced. I don’t remember seeing this problem in the past but I did not check.

What I mean is: it looks like we might have an upgrade problem. Since we do support upgrades, this could be worth looking into: this could mean that the code Enigmail and Torbirdy may have to upgrade existing profiles, when the add-on is upgraded, is not triggered. Both Feature #15657 and this ticket were about dealing with add-on upgrades, so I thought this would be relevant here. But if you don’t want to look into this, that’s totally fine. Please just let me know and either file a ticket about it or ask me to :)

Either way, I confirm that memory hole is not enabled \o/ ⇒ I would set “QA Check = Pass”, the only reason I don’t do this yes is that I’d like to make sure we won’t forget about the issue I reported above.

#22 Updated by intrigeri 2019-01-14 19:48:26

• Assignee changed from intrigeri to hefee
• % Done changed from 0 to 90

#23 Updated by intrigeri 2019-01-14 19:56:17

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

Applied in changeset commit:tails|c293b92386617399021f7ddfbf745ac9307c99e9.

#24 Updated by intrigeri 2019-01-14 19:57:17

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

#25 Updated by hefee 2019-01-14 20:30:52

• Assignee deleted (hefee)
• % Done changed from 90 to 0
• QA Check changed from Info Needed to Dev Needed

intrigeri wrote:
> >> * In the Add-ons Manager it claims to be 0.2.5. Same issue for Enigmail, will report on Feature #15657. extensions.json has stuff about 0.2.5 but not about 0.2.6.
>
> > With a fresh installation this is not the case.
>
> Good.

I wanted to really make sure, that the plugin itself extract the correct version ;D

> I did not expect this would be the case (a fresh installation has simply never heard of Torbirdy 0.2.5).
>
> I’ve reproduced this problem (profile created on 3.11 then upgraded to your branch) with the latest version of your branch.
>
> >> * There’s no Torbirdy UI in the status bar while my Thunderbird on sid, with Torbirdy 0.2.6, has it.

> What I mean is: it looks like we might have an upgrade problem. Since we do support upgrades, this could be worth looking into: this could mean that the code Enigmail and Torbirdy may have to upgrade existing profiles, when the add-on is upgraded, is not triggered. Both Feature #15657 and this ticket were about dealing with add-on upgrades, so I thought this would be relevant here. But if you don’t want to look into this, that’s totally fine. Please just let me know and either file a ticket about it or ask me to :)

Me is very short on time, so I’d like to give it to someone else.

So far I figured out, there is no upgrade scripts for torbirdy and only one place of the version in install.rdf form the package.

For Enigmail there is a upgrade script in package/configure.jsm triggered by package/core.jsm:462. Enigmail stores it version in prefs.js in extensions.enigmail.configuredVersion. This pref is also not upgrade.

I seems, like we broke the upgrade mechanism somehow. intrigeri mentioned, that for his sid installation torbirdy and enigmail upgrade worked.

#26 Updated by intrigeri 2019-01-27 10:59:12

• Assignee set to hefee
• Target version changed from Tails_3.12 to Tails_3.13

OK, we won’t manage to deal with this in time for 3.12. I hope it won’t break important use cases, fingers crossed. Are you up to tackling this for 3.13?

#28 Updated by hefee 2019-02-28 11:11:57

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

I’m blocked on that ticket, as I need to know how I can debug the plugins/javascript in Thunderbird. Is it any Tails specific setting, that the jsconsole is not working?

#29 Updated by Anonymous 2019-02-28 14:20:50

• Assignee changed from intrigeri to hefee

@hefee what means “not working” exactly?

#30 Updated by hefee 2019-02-28 15:19:12

• Assignee deleted (hefee)

u wrote:
> @hefee what means “not working” exactly?

The jsconsole (Crtl-Shift-j) stays empty all the time and I can’t enable/disable categories or start via thunderbird —jsconsole. Like I can do on my sid system. At least this jsconsole looks like the tool to debug plugins in Thunderbird. Enigmail is using a EnigmailLog in its code - maybe this is not the jslog?

#31 Updated by Anonymous 2019-02-28 17:21:27

• Assignee set to hefee

Torbirdy is supposed to disable JS.
Did you check the preferences → config editor if there is a preference that disables the console?
I don’t think we disable the JS console, but you could check in tails.git: fgrep -r thunderbird | grep -v ^wiki

#32 Updated by hefee 2019-03-04 16:35:17

• Assignee deleted (hefee)

u wrote:
> Torbirdy is supposed to disable JS.

well JS in mails as all addons are JS, that can’t be disabled completly.

> Did you check the preferences → config editor if there is a preference that disables the console?

there is no setting for this.

> I don’t think we disable the JS console, but you could check in tails.git: fgrep -r thunderbird | grep -v ^wiki

@intrigeri: The only thing that I can image is Apparmor.

#34 Updated by intrigeri 2019-03-05 12:26:01

• Assignee set to hefee

> * I created a fresh Thunderbird profile with 3.11 and than updated to 3.12.1. After upgrade I checked the Addons-page and it lists me the correct versions 2.0.8 and 0.2.6. Also extensions.json show the correct versions.

I did the same test (Freshly installed 3.11, created brand new persistence there, restarted Tails, enabled persistence, started Thunderbird, configured email account, shut down. Started Tails again, accepted automatic upgrade to 3.12.1, restarted on 3.12.1, enabled persistence, started Thunderbird.) ⇒ and indeed I can’t reproduce the bug anymore. Case closed!

> The only thing I found is that extensions.enigmail.configuredVersion is still 2.0.7.

Reproduced. Related: config/chroot_local-includes/usr/local/bin/thunderbird (where we set this pref once to skip the wizard, but we do this in a way that supposedly lets Enigmail update it itself later). Looks like this does not work so well if it’s still 2.0.7 after starting Thunderbird on Tails 3.12.1. But maybe it’s expected behavior actually: in my own test I did not configure Enigmail for the email account I’ve set up (neither on 3.11 when I created it, nor on 3.12.1). So maybe that’s why Enigmail won’t update its “configured version”. I would say retry the same test procedure except after setting up the persistent Thunderbird email account, while still running 3.11, configure Enigmail for that account. I suspect that Enigmail will then correctly update extensions.enigmail.configuredVersion after Thunderbird is started post-upgrade-to-3.12.1.

> Unfortuantely the jsconsole does not work (is this disabled somehow in Tails?), so I can’t debug the javascript to check if it reaches configure.js.

FTR anonym confirmed that what you’ve seen (and what I see) is not the expected behavior of the JS console (even if there’s no log to show at all). anonym has tried and reproduced this bug. He says he was using that console in Tails in the past and back then it was working ⇒ that’s a bug, needs a ticket if it indeed blocks other work of ours.

#35 Updated by hefee 2019-03-05 16:58:18

• related to Bug #16529: Thunderbird: jsconsole is broken added

#36 Updated by hefee 2019-03-05 17:22:03

• Assignee changed from hefee to intrigeri

intrigeri wrote:
> > * I created a fresh Thunderbird profile with 3.11 and than updated to 3.12.1. After upgrade I checked the Addons-page and it lists me the correct versions 2.0.8 and 0.2.6. Also extensions.json show the correct versions.
>
> I did the same test (Freshly installed 3.11, created brand new persistence there, restarted Tails, enabled persistence, started Thunderbird, configured email account, shut down. Started Tails again, accepted automatic upgrade to 3.12.1, restarted on 3.12.1, enabled persistence, started Thunderbird.) ⇒ and indeed I can’t reproduce the bug anymore. Case closed!

Great!

> > The only thing I found is that extensions.enigmail.configuredVersion is still 2.0.7.
>
> Reproduced. Related: config/chroot_local-includes/usr/local/bin/thunderbird (where we set this pref once to skip the wizard, but we do this in a way that supposedly lets Enigmail update it itself later). Looks like this does not work so well if it’s still 2.0.7 after starting Thunderbird on Tails 3.12.1. But maybe it’s expected behavior actually: in my own test I did not configure Enigmail for the email account I’ve set up (neither on 3.11 when I created it, nor on 3.12.1). So maybe that’s why Enigmail won’t update its “configured version”. I would say retry the same test procedure except after setting up the persistent Thunderbird email account, while still running 3.11, configure Enigmail for that account. I suspect that Enigmail will then correctly update extensions.enigmail.configuredVersion after Thunderbird is started post-upgrade-to-3.12.1.

I tried this but still configuredVersion is still 2.0.7. But after entering the enigmail settings and change one thing the prefs now have the correct value for “configured version”. So yes the configured.jsm has some logic to postpone to trigger the update the value. Well access to EnigmailLog would help to understand more details…

As we both can’t reproduce the issue anymore I would propose to close this bug. Or have I forgotten any loosen end?

#37 Updated by intrigeri 2019-03-06 07:59:21

• Status changed from In Progress to Resolved

> I tried this but still configuredVersion is still 2.0.7. But after entering the enigmail settings and change one thing the prefs now have the correct value for “configured version”. So yes the configured.jsm has some logic to postpone to trigger the update the value. Well access to EnigmailLog would help to understand more details…

Thanks for testing :)

> As we both can’t reproduce the issue anymore I would propose to close this bug.

Fully agreed!