Bug 374937

Summary:	Ark should have option to shred temporarily extracted files on close
Product:	[Applications] ark	Reporter:	Greg <greg.b.kde>
Component:	general	Assignee:	Elvis Angelaccio <elvis.angelaccio>
Status:	CONFIRMED ---
Severity:	wishlist	CC:	rthomsen6
Priority:	NOR
Version First Reported In:	16.08.3
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Greg 2017-01-12 00:26:58 UTC

When working with encrypted archives, opening a file causes a temporary extraction to a randomly-named directory in /tmp.  However, when Ark is closed, it only removes the temporarily extracted files; it does not shred them.  A stolen or infected computer (for example) would then present a risk of that file's disclosure even though the archive is encrypted.

Proposed solution:  add an option in preferences to shred *temporarily* extracted files prior to their automatic removal.

Discussion point:  should this be the default behavior?  Some viewer applications may be confused by the file's overwrite while the viewer still has the file open but Ark has been closed.  Perhaps Ark can detect this condition and respond to it, but that itself may be problematic or too complex.

Comment 1 Elvis Angelaccio 2017-01-12 10:15:24 UTC

If you really need this level of protection, I think you should consider mounting your /tmp on a tmpfs, so that nothing is ever written on disk. What do you think?

Comment 2 Greg 2017-01-12 21:06:09 UTC

(In reply to Elvis Angelaccio from comment #1)
> If you really need this level of protection, I think you should consider
> mounting your /tmp on a tmpfs, so that nothing is ever written on disk. What
> do you think?

Thanks, Elvis -- tmpfs is a great tool (which I use), and is typically the default these days, but as it is swap-backed it doesn't guarantee the data isn't written to disk unless the machine has -no- swap (but of course that applies, perhaps to a lesser extent, to the memory pages used by the viewer too).

My reason for this feature request is mainly so Ark's behavior can be consistent with the data that it is handling -- if encrypted data is being viewed without the user's intention to actually "extract" the data, it makes sense to minimize the persistence of the decrypted copy.  Using tmpfs as well would be a defense-in-depth choice.

Comment 3 Elvis Angelaccio 2017-01-12 23:58:02 UTC

(In reply to Greg from comment #2)
> (In reply to Elvis Angelaccio from comment #1)
> > If you really need this level of protection, I think you should consider
> > mounting your /tmp on a tmpfs, so that nothing is ever written on disk. What
> > do you think?
> 
> Thanks, Elvis -- tmpfs is a great tool (which I use), and is typically the
> default these days, but as it is swap-backed it doesn't guarantee the data
> isn't written to disk unless the machine has -no- swap (but of course that
> applies, perhaps to a lesser extent, to the memory pages used by the viewer
> too).

Right, I don't use swap so that didn't cross my mind :p

> 
> My reason for this feature request is mainly so Ark's behavior can be
> consistent with the data that it is handling -- if encrypted data is being
> viewed without the user's intention to actually "extract" the data, it makes
> sense to minimize the persistence of the decrypted copy. 

Note that if the archive is a zip with pkware encryption, everything is lost anyway. An attacker who has physical access to the disk can crack that archive in minutes.
So shreding the temp files would only help with rar or 7z archives with AES encryption.
Well, patches welcome :)

Comment 4 Greg 2017-01-13 07:31:12 UTC

(In reply to Elvis Angelaccio from comment #3)
> Note that if the archive is a zip with pkware encryption, everything is lost
> anyway. An attacker who has physical access to the disk can crack that
> archive in minutes.
> So shreding the temp files would only help with rar or 7z archives with AES
> encryption.

Correct.  7zAES in this case.

> Well, patches welcome :)

I probably won't have time to code a patch anytime soon, but will keep it in mind. :)