Encryption stuff in need of solutions

[Lamarque V. Souza]

Em Thursday 19 January 2012, Ivan Čukić escreveu:
> 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.

	Well, best effort: if it is a private activity show a dialog with Ok and 
dismiss buttons. If the password is wrong, ask again and again until it is 
right or the user clicks on dismiss. The dismiss operation tries to find a 
non-private activity, if none is found then present a new dialog with "Create 
new activity" and shutdown buttons :-)
 
> 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.

	You say that because you are going to move the ask password dialog to 
activity switcher?
 
> What about having the activity browser shown if no activity is
> current? (and, this is for both active and desktop)

	It's Ok for me.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120119/a01defa8/attachment.html>