SUMMARY *** Kate (editor) leaks directory/file info in (~/.config/katemetainfos) from encrypted volume after dismount (veracrypt) *** STEPS TO REPRODUCE 1. mount a veracrypt volume 2. use Kate to create and edit a text file on the veracrypt volume 3. save/close kate, dismount veracrypt volume 4. use kfind to search "for text within files" on ~ for the name of the text file created by Kate 5. will find a hit in ~/.config/katemetainfos OBSERVED RESULT A hit in ~/.config/katemetainfos leaks that a verycrypt volume was mounted and edited, and also leaks part of the directory structure and where the veracrypt volume was mounted in / - Unknown how many other leaks may exist in Kate. Example hit: [file:///media/veracrypt7/Dummydir/Dummyfile.txt] EXPECTED RESULT No record that an encrypted volume was mounted or used. A secure encryption will leak no information. (D. Boneh [2015]) SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: LEAP 15.4 (available in About System) KDE Plasma Version: 5.24 KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
If maximum privacy is a concern for you, I would recommend globally disabling all apps from saving information about recently-opened files in System Settings > Workspace Behavior > Recent Files. Does that work for you?
OS-based encryption (e.g., luks and ...?), at least, should be modified (in the kernel?) to automatically prevent storing path/file/content information in plaintext, either in user or system directories, for such Volumes - and should autopurge memory at dismount. (but major problems still reside in parts of linux - like OpenSSH in 2016...) A solution then would be that apps like veracrypt could be added to "a list" to use such a kernel-based encrypted-volume-security-fix after it is implemented? (but I'm no Wizard, Guru, or Lord High Fixer - I don't understand Deep Magic or Heavy Wizardry ;^) Different folks view encryption security differently (Boneh/Krebs/Schneier) and some aren't concerned - I'm just careful, not paranoid, not really; but it seems very responsible to trust academics about encryption (Boneh) when supporting a global-class OS. I would have to test your proposed solution, but it seems drastic, and I'm not sure of side consequences in the UI. Previously (with dolphin) I had suggested an option to "flush history" (and now in kate) as stopgap security measures - but I realize that would involve separate development teams, and it's not clear what other apps in the repos store such info in plaintext. (Baloo comes to mind...) In particular, only path/file-content data actually seem to be important at this point.
BTW: THANK YOU for the reply and the suggestion! :^)
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!