Project

General

Profile

Bug #13340

Thunderbird stores temporary files (included decrypted attachements) indefinitely

Added by goupille 4 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
Start date:
07/01/2017
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
bugfix/13340-clean-thunderbird-tmp-dir
Type of work:
Code
Blueprint:
Easy:
Affected tool:
Email Client

Description

Thunderbird is storing attachements that the user wanted to 'open' without 'downloading' them, and the content of the clipboard, in /home/amnesia/.thunderbird/profile.default/tmp/, and never erase them (I found files created in september in here).

At least, I think that Thunderbird should not keep those files from one session to another, and that encrypted attachements should not be stored in clear, even until the end of the session.


Related issues

Blocks Tails - Feature #13234: Core work 2017Q3: Foundations Team Resolved 06/29/2017

Associated revisions

Revision 9c78103d (diff)
Added by intrigeri 3 months ago

On Thunderbird startup, empty its temporary directory (refs: #13340).

Revision f547a41e
Added by bertagaz 3 months ago

Merge remote-tracking branch 'origin/bugfix/13340-clean-thunderbird-tmp-dir' into stable

Fix-committed: #13340

History

#1 Updated by goupille 4 months ago

  • Subject changed from Thunderbird stores temporary files (included cedrypted attachements) indefinitely to Thunderbird stores temporary files (included decrypted attachements) indefinitely

#2 Updated by geb 4 months ago

Hi,

If this bug is not Tails specific, maybe it should be kept private.

Usul, any opinion ? (I added you to the watchers)

#3 Updated by goupille 4 months ago

I think it is Tails specific : in debian, Thunderbird is using /tmp.

#4 Updated by intrigeri 3 months ago

  • Target version set to Tails_3.1

I think it is Tails specific : in debian, Thunderbird is using /tmp.

Right, we use a custom $TMPDIR to avoid having to grant Thunderbird access (once we confine it with AppArmor eventually) to all kinds of files in /tmp owned by the amnesia user.

So, it seems that Thunderbird relies on the OS to clean up the temporary directory it uses regularly, which happens for /tmp on most systems. I think that's a bug, i.e. Thunderbird should delete temporary files once it doesn't need them anymore, and worst case when the app is closed. Keeping such files around for potentially weeks doesn't make much sense to me. I'll check if this problem is known upstream, and will report it if not.

Worst case we'll clean up the content of ~/.thunderbird/profile.default/tmp/ ourselves as a temporary workaround in our Thunderbird wrapper script… even though we try to avoid messing with the user' data when we can avoid it.

@Usul: if you want to keep following this ticket, fine; otherwise just say the word and I'll remove you from the watchers list :)

#6 Updated by intrigeri 3 months ago

#7 Updated by intrigeri 3 months ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/13340-clean-thunderbird-tmp-dir
  • Type of work changed from Research to Code

#8 Updated by intrigeri 3 months ago

  • Assignee changed from intrigeri to bertagaz
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

#9 Updated by bertagaz 3 months ago

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

While testing I found out that the files in TMPDIR gets deleted when Thunderbird is closed. Any leftovers there are probably appearing when one shutdown Tails without closing Thunderbird first (or it segfaults). I does not remove how relevant this branch is though, so I've merged it.

#10 Updated by intrigeri 3 months ago

While testing I found out that the files in TMPDIR gets deleted when Thunderbird is closed. Any leftovers there are probably appearing when one shutdown Tails without closing Thunderbird first (or it segfaults). I does not remove how relevant this branch is though, so I've merged it.

Yeah, makes sense to merge it anyway since we have no other mechanism to clean up stray files in there when there are any. Thanks for the careful testing!

#11 Updated by bertagaz 2 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF