Encryption stuff in need of solutions

[Marco Martin]

On Thursday 19 January 2012, Ivan Čukić wrote:
> So, as you know, we have had some different issues mainly surrounding
> the integration between plasma's activities and kamd. (isn't it always
> the case :) )
> 
> I've been looking at the possibilities to have some secure way of
> sharing the password between plasma and kamd so that plasma can ask
> for it, check whether it is correct, and then pass it to kamd, but
> secure IPC isn't really plausible without some lower level security
> mechanism like SElinux-enabled d-bus.
> 
> So, I think we need to have kamd ask for the password, since it is the
> one setting up the encryption.

that means also would not be possible to use the screen locker to unlock an 
activity.

we probably can live with an ugly ish dialog for now, it makes more difficult 
to have other things like graphical input tough

> The only way that I see (and planning to take it) to avoid the following
> issues: - activities being opened in plasma even if the user types the
> wrong password - blocking kamd (and probably plasma) until the user types
> the password in is to have another activity state called Locked or
> similar. (it seems that the currently existing 'Starting' state might be
> used or
> misused???)

or you could ask to kamd to change activity then from the outside nothing will 
change until you entered the right password, so plasma wouldn't even try to 
switch

> This means that plasma-* will need a little bit more logic not to
> listen only for which is the current activity, but also to listen for
> the state of the current activity. If the state is not 'Started' then
> it should not show the current activity. Though I have no idea what to
> show (showing previous activity is not a complete solution - the user
> might want to boot into a private activity - and there is no previous
> one then.

uhm, plasma should be able to start with no containments... that seems a bit 
invasive, but could be needed also when the screen is blocked on a locked 
activity

> If the user doesn't know the password, it should be possible to go to
> a public activity. But that raises more problems - if kamd asks for
> the password, would it mean that kamd should have ui for the activity
> switcher as well... security is a messy thing.
> 
> What about having the activity browser shown if no activity is
> current? (and, this is for both active and desktop)

that could make sense, remains to see what exactly "no current activity" 
means, not having any activity seems to clach quite a bit with the design

-- 
Marco Martin