I use KDE in a more or less stock OS install. I was noticing after closing a VeraCrypt volume that dolphin (in a subdir of .local) kept a full history of the directory structure (not individual files) of the volume. I think this is a pretty troubling leakage because if there are descriptive names in any directory names you browse with dolphin - they are apparently kept long-term. Is there a user function which removes this history? Dolphin didn’t want me to simply delete the contents of .local. I’m thinking along the lines of “delete clipboard history” - but maybe for local directory navigation history?
Does anyone here know of a best practice to deal with this? Have the Dolphin developers thought about this? (I’m sure they have.)
Please do not assume that we do all the time the same things that you do. Where do you see that history. I see no history tab in my Dolphin. Which does not mean there isn’t something like a history, but where?
OTOH, when there is indeed something like a history in Dolphin, why should Dolphin (as an end-user program) have any knowledge about which of those directories are inside a encrypted file system? End users programs only see the complete (and only) Unix/Linux directory tree. Nothing about the different file systems that tree is build from.
My apologies to everyone - I didn’t try to come off rudely. To see that stuff, I used kfind… I went searching for some files and noticed that they turned up as some sort of “record” under the **.local **folder - basically, the full path of the file I’d opened. I can try to reproduce.
We need a way to find out if a local path is actually a path to an encrypted volume or folder.
And that confirms my remark above. A user program normally does not bother if a file is from an encrypted area or not. There is no difference for a program to read/write a file in an encrypted area or not.
I am afraid that your quest only starts here. Many programs keep lists of “recently opened files” for the benefit of the user.
As an interim measure you could create a bash script to delete the relevant “top level” directory (or directories) below “~/.local/share/dolphin/view_properties/”, which KDE runs on logout. (Place the script at “~/.config/plasma-workspace/shutdown/”, then from “System Settings -> Startup & Shutdown -> Autostart” set it to run on logout).
Ty!!
(oops… need 10 characters << me playing a 7-string Conklin groove tool.jpg >>)
Well, now that I think about it - I could maybe have some sort of search script (based on kfind?) search non-binary files for “/veracrypt/” or some such string and overwrite the path… Ugh - is that even possible?
Wow - thanks for the link. I’m glad to see I’m not crazy. Following Krebs and Schneier periodically. Security probably should be the focus of the next decade in computers. (All credentialed software comes to mind.)
Also, as I’ve mentioned b4 - I think there should be a “security” subforum on the OS forum, although I don’t know how one would deal with miscreants showing up there.
With Dolphin Version 20.04.2 on Leap 15.2, I’m not seeing any history being written to directories below ‘~/.local/share/dolphin/view_properties/’ – but, I’m not using VeraCrypt …
Possibly, this is an issue specific to VeraCrypt rather than Dolphin …
[HR][/HR]If you’re planning to remove everything that Dolphin wrote during a login session to the ‘~/.local/share/’ directory by means of a logout script, may I suggest that, the remove be limited to the sub-directory VeraCrypt is using …
Whether or not, VeryCrypt will function correctly at the next login session is a moot point – test carefully …
I’m under LEAP 15.1 - I am planning on updating to 15.2. I’ll also attempt to more carefully document what is saved. It seems REALLY odd if veracrypt itself were leaking this information - as they are information-leak-phobic… I just assumed that since Dolphin/KDE was being used, then whatever was hitting the screen was fair game for storage by KDE.
I should say, whatever was “hitting the screen” in a standard KDE app (Konsole, dolphin, etc.) seems like it’s fair-game for storage by KDE (possibly for efficiency/speed/convenience reasons?). Or maybe even baloo? Anyway, I’m taking a fresh look at this with 15.4 right now. I created a dir and a file on a veracrypt volume, opened them, then unmounted the volume. Now I’m using kfind on ~ to see if there’s any plaintext storage of the names of these…
EDIT: It’s more of a KDE problem than a dolphin problem, per se. Although the files/dirs didn’t show up in the “Recent files” menu item, one did show up in the katemetainfo storage: [file:///media/veracrypt11/00_Dummy.txt]
BTW: that’s in ~/.config/katemetainfos - 00_Dummy.txt is a file I edited with the default KDE editor (kate) directly to the mounted veracrypt volume.
This constitutes a “memory leak” of information contained in an encrypted file. I mean, it’s not KDE’s fault per se, but it is what it is. Folks who do security (even garden-variety folks like me) should know about these things. (And linux is kinda secure by default.)
