[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Kde-hardware-devel] Status of encrypted devices in Plasma / Solid
From:       Jacopo De Simoi <wilderkde () gmail ! com>
Date:       2010-02-25 23:04:57
Message-ID: 201002260004.59260.wilderkde () gmail ! com
[Download RAW message or body]

> > 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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]