You are not logged in.
Pages: 1
Hi,
I'm new to xfce but loving it so much after Unity.
I have one gripe, about Clipman and it's persistence of cached data to disk. This seems like a security issue if sensitive data like a password is copied and pasted (we all do it) and it would be good if the mechanism was more obvious and there was a standard way to wipe the contents.
I haven't experimented yet, but this thread suggests it's not straight forward...
Is there a reliable way to do this? Just unlinking ./.cache/xfce4/clipman/textsrc doesn't count as secure in my reckoning.
Is there an alternative clipboard manager that doesn't write contents to disk?
Cheers,
bitrat
Last edited by bitrat (2023-07-19 19:39:43)
Offline
Hello and welcome.
These bug reports may be of interest:
Don't save history as plaintext - closed with suggestion to encrypt home directory.
Honour password hint - pending development.
As another option, you could set the immutable flag on ~/.cache/xfce4/clipman/textsrc so that the plugin isn't able to write to the file. This should prevent writing to the file (or deleting it as is done by the plugin when history is cleared) so that on fresh login, the history will be blank. However, the history will still be available as long as you are logged in:
sudo chattr +i ~/.cache/xfce4/clipman/textsrc
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Thanks ToZ!
I can try making the cache file read only, but it seems a bit hacky, Also, while it's tempting to encrypt /home, I prefer not to...
Passwords don't usually go into bash history because the CLI applications that use them (eg: ssh) generally or optionally read them directly from stdin, using a password prompt with echo off or obscured, not via the shell's interpreter. There are exceptions but it probably wouldn't be difficult to make a wrapper script to add this behaviour. I'm more worried about the persistent clipboard data, tbh. It isn't a behaviour I need or want. :-)
Is there any real reason why XFCE or Clipman doesn't honour the x-kde-passwordManagerHint MIME type? Could the problem be alleviated by optionally disabling persistence to disk?
Also, what API would need to be addressed to replace Clipman? I know next to nothing about desktop manager internals.
Cheers,
bitrat
Last edited by bitrat (2023-07-20 06:12:44)
Offline
Is there any real reason why XFCE or Clipman doesn't honour the x-kde-passwordManagerHint MIME type? Could the problem be alleviated by optionally disabling persistence to disk?
Possibly. It just hasn't been programmed into the plugin yet.
Also, what API would need to be addressed to replace Clipman? I know next to nothing about desktop manager internals.
Personally, I'm not sure about the API - or whether one is even required, as opposed to just coding in the options. There are a couple of issues here - honoring the password hint and disabling disk persistence. The former has an open a bug report and the latter a closed bug report. Feel free to post to both those bug reports if you would like the developers to bring the issues to the developers.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Looks like it's there after all!
Settings -> Clipboard Manager Settings -> Clipman Settings | History
:-)
As reported elsewhere, turning off history appears to delete ./.cache/xfce4/clipman/textsrc, but if the history is turned back on, the content reappears, maybe cached in memory. So it's not possible to securely delete the cache file...
Not sure if the cached content disappears after reboot, but I'll test next boot and report back.
Last edited by bitrat (2023-07-20 21:55:11)
Offline
I totally missed that setting. wow.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
As reported elsewhere, turning off history appears to delete ./.cache/xfce4/clipman/textsrc, but if the history is turned back on, the content reappears, maybe cached in memory. So it's not possible to securely delete the cache file...
Fixed in https://gitlab.xfce.org/panel-plugins/x … 94603c7e74 , to be released in 1.6.4 soon.
Offline
bitrat wrote:As reported elsewhere, turning off history appears to delete ./.cache/xfce4/clipman/textsrc, but if the history is turned back on, the content reappears, maybe cached in memory. So it's not possible to securely delete the cache file...
Fixed in https://gitlab.xfce.org/panel-plugins/x … 94603c7e74 , to be released in 1.6.4 soon.
I see, so setting the property to false also clears the memory cache. Rather than read the rest of the code, can I assume that, if save_on_quit is unset, clipboard data will never be written to disk? One day I'll set up a virtual machine and do some hacking myself, but a bit too busy right now...
Last edited by bitrat (2023-07-27 09:26:34)
Offline
I totally missed that setting. wow.
Offline
Rather than read the rest of the code, can I assume that, if save_on_quit is unset, clipboard data will never be written to disk?
Yes, bearing in mind that a bug is always possible, and that this plugin isn't particularly aimed at data security/privacy.
Offline
this plugin isn't particularly aimed at data security/privacy.
Given that the clipboard mediates otherwise independent tasks and processes, it could be worth revising that priority.
Last edited by bitrat (2023-07-27 22:34:34)
Offline
Pages: 1
[ Generated in 0.012 seconds, 9 queries executed - Memory usage: 566.78 KiB (Peak: 584.06 KiB) ]