[Kde-hardware-devel] Status of encrypted devices in Plasma / Solid

Jacopo De Simoi wilderkde at gmail.com
Mon Dec 7 18:00:05 CET 2009


Dear plasma-devs, hardware-devs
 looking forward to check the validity of a bug regarding the device notifier and encrypted devices (containers) I noticed several issues with them in the current implementation of 
the dataengines 
The imporant thing to know about them is that they show up in solid as a StorageVolume such that StorageVolume.usage is 'Encrypted'. When they are "mounted" 
solid asks for a password and if the password is correct, then the partitions which are stored inside the device pop up and are correctly collected by the hotplug dataengine.
Then the user can use them normally; the encrypted device (container) is closed (i.e. cannot be used anymore without providing the password again) by "unmounting" it.

A few issues arise in this situation:
1) Solid cannot provide us with a signal when an encrypted container is correctly "mounted" or "opened"
2) The encrypted containers are currently shown by the dataengine since they match the "open with file manager" predicate, however
    this action does really nothing, since a container simply contains partitions, so we can't really open the file manager on unmounted partitions.
    Moreover, there is no real static action we can associate with them.
3) The user is (imHo) misled by strings such as "mount/unmount" and icons such as "mounted/unmounted/eject"

My proposed solutions:
1) A solution (bad, but that's all we can do) to solve issue #1 is to let the hotplug engine check if a newly added or removed device is inside an
    encrypted container and trigger an update of the status of the container accordingly.  If new devices are added it means that the container has been opened
    if they are removed, it means that the container has been closed. 
2) Rather than cheating giving a completely fake action we could implement an exception for the hotplug engine, letting it populate devices with encrypted devices
    even if they have no action associated with them.  This of course need adjustments to the two (that I know) users of the dataengine (device notifier and solid runner)
    to make sure they don't assume the existence of at least one action and in order for them to properly handle such situation. 
    A less pervasive solution would be to let the engine add dynamic action (open/close the container) if it detects an encrypted device. In this case the adjustments to the 
    notifier and to the runner would be less pervasive, but still we need to treat the special action in a different way than the others, unless, we rely on soliduiserver::showActionsDialog
    itself accepting these two as special actions.
3) Nuno already kindly provided emblems/icons for the open/close status (locked/unlocked); as for the strings I already asked for an exception for string freeze regarding 
    solid::Device::description() which should say "encrypted container" instead of "removable media". I might as well ask for an exception to 
     add "Lock the container" and "unlock the container" if felt needed. If string freeze exceptions for these are not granted I'd rather leave descriptions empty rather than 
     providing false information..

Awaiting for your comments and suggestions 
Thanks

 --J


More information about the Kde-hardware-devel mailing list