Encryption stuff in need of solutions

[Ivan Čukić]

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.

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???)

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.

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)



-- 
Cheerio,
Ivan

--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun