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

[Jacopo De Simoi]

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

Correct, however if I remember correctly there is no signal such as "accessibilityChanged" which is catched by the dataengine to trigger a status change, since the object referred by the engine is not the one that requested the setup. 

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

No, indeed; moreover these signals are indeed quite useless if they are not emitted for all object referring to the same device. We would need to have those for all such objects to make good use of them. I'll post a new thread about this eventually.

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

This is the workaround implemented in 4.4 for the dataengine

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

Currently implemented in 4.4.

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

The exception has been granted and the strings appear now in 4.4