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

[Kevin Ottens]

On Monday 7 December 2009 18:00:05 Jacopo De Simoi wrote:
>  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.

Indeed, pretty good summary of the behavior.
 
> A few issues arise in this situation:
> 1) Solid cannot provide us with a signal when an encrypted container is
> correctly "mounted" or "opened"

I'm not sure what makes encrypted containers special in this regard... The 
setupDone() signal is emitted just like for any device supporting the 
StorageAccess interface.

Now if you're talking about the missing {setup,teardown}RequestStarted signal 
which would work accross process boundaries and that we discussed in 
september, yes that's the same issue. But again, just to clarify, it has 
nothing specific to the encrypted case.

> 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.

Indeed nasty, I'd prefer to see it fixed below in the stack.

> 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.

It's definitely my favorite one.

> 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.

Well, it's really about making sure they don't make a (now) wrong assumption. 
As a bonus that would shield them against a misbehaving engine, so that's 
probably not a bad thing.

> 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..

Since I suck and took months to get back to you I guess the string freeze is 
not a problem anymore. :-)
 
Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100220/cacb626c/attachment.sig