https://bugs.kde.org/show_bug.cgi?id=411919

Alexis Kauffmann <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #60 from Alexis Kauffmann <[email protected]> ---
(In reply to Nate Graham from comment #53)
> I still think this is what we should do even if $HOME is encrypted. Because
> even if it is, there is still a  data leak of cached content from one
> encrypted location to a location outside of it. Yes, $HOME being encrypted
> protects against thieves who steal your laptop, but it does not protect
> against other local users with physical access (e.g. when you step away to
> use the bathroom, or whatever), which is currently a thing you can use
> Vaults to protect against. But if cached thumbnails are leaked outside of
> the vault, that protection is diminished.

As a non-IT-professional but somewhat experienced Linux user (since 2009) who
is highly concerned about security and privacy, I agree with Nate Graham in
this point: no encrypted information should ever be available in plain text in
your hard drive after closing the encryption vault. But I also understand that
operating systems and desktop environments are complex nets of assumptions and
decisions and, as such, one apparently small change in one place might cause
serious consequences elsewhere.

Therefore, after reading every comment in this thread, I thought: “why not
encrypt the ~/.cache/thumbnails folder itself every time I access my file
vaults”? It’s not convenient, but not really hard to implement and test it
myself.

After reviewing my options, I decided to use gocryptfs
(https://github.com/rfjakob/gocryptfs) a very secure and easy to use (free and
open source!) command line encryption system available on Debian/Ubuntu repos.
If you don’t have it, you need first install it with

sudo apt install gocryptfs

After installation, create an encrypted folder to hold your encrypted thumbnail
files. 

I called my folder “thumbnailscry” just to make it easy to remember. But if you
are really paranoid, you could use a random sequence of characters valid for
filenames generated by KeepassXC or other password/random characters generator.

First, I created my “thumbnailscry” subfolder:

mkdir ~/.cache/thumbnailscry

I saw no reason for that folder not be in the ~/.cache folder itself. If anyone
here objects to this choice, I will be happy to learn from you.

Then I encrypted that folder with gocryptfs:

gocryptfs -init ~/.cache/thumbnailscry

Don’t forget to provide a heavily secure password generated by KeepassXC or any
other reliable tool like pwgen.

After that, I activated my encrypted ~/.cache/thumbnails folder using

gocryptfs -nonempty ~/.cache/thumbnailscry ~/.cache/thumbnails

The -nonempty option allows you to overwrite a non-empty folder with your
unencrypted data.

After that, I opened my file vaults and monitored the thumbnail generation. As
expected, all thumbs were loaded in RAM only, while the files themselves were
only written in encrypted form.

When I finished working with the vault, all I had to do was unmount the
~/.cache/thumbnails folder with this simple command:

fusermount3 -u ~/.cache/thumbnails

And, voilá! All I had was an empty thumbnails folder!

For convenience purposes, I added the mount/unmount commands as alias to my
~/.bashrc:

alias cryptthumbs = 'gocryptfs -nonempty /home/USER/.cache/thumbnailscry
/home/alexei/.cache/thumbnails'
alias decryptthumbs = 'fusermount3 -u /home/USER/.cache/thumbnails'

WARNING: For this workaround to properly protect you, you must remember to
mount the encrypted thumbnails folder BEFORE accessing your vault and only
unmount it AFTER closing your vault!

Does it add a little inconvenience to your vault use? Sure! But people who are
SERIOUSLY concerned about security usually don’t care about a little hassle
here and there.

In time: this type of solution could be embedded in encryption software, thus
avoiding the complexities and risks of rewriting your desktop environment code.
The developers could add it as an option, like “Do you want to encrypt your
thumbnails folder during this session? Yes-No”.

Finally: in my tests, it did not slow down my computer and didn’t disrupt
thumbnail generation from other applications. The system kept running as
smoothly as before.

Hope it helps. Happy 2026 to everyone!

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to