Hi all,
I'd like to ask you a pre-review on the following branch:
https://gitorious.org/accounts-sso/signon/commits/keymodel
(the first commit to review is cd7d90398e6df31096496c6eaacbd287265472aa)
I'm saying "pre-review" because the code is totally untested, and I'll be
submitting another iteration of the branch with the changes that I'll most
likely have to apply to make it work properly.
But since this refactoring involves creation of new classes (which will sooner
or later be moved to the libsignon-extension API), it's important at least to
agree on the naming and APIs of the newly introduced classes:
- KeyHandler: this class aggregates information coming from the key managers,
and provides a couple of methods for granting and revoking authorization to
encryption keys.
- AbstractKeyAuthorizer: this class defines the API that will have to be
implemented by plugins who wish to change the logic of deciding whether a new
key must be added to the cryptsetup configuration.
The other added class, UiKeyAuthorizer, is a subclass of AbstractKeyAuthorizer
and will eventually be moved into a dynamically loadable plugin.
My doubts concern especially the meaning of "authorizing a key", which we have
been using in two different contexts:
1) inserting/removing a key into the cryptsetup configuration, so that the key
will be usable to mount the encrypted storage;
2) deciding whether the action in (1) has to be taken.
The AbstractKeyAuthorizer tries to avoid the confusion by calling its API
"queryKeyAuthorization" (and corresponding signal "keyAuthorizationQueried"),
but I wonder if we could find different names for these concepts.
Maybe we could leave the "authorize" word for the action of deciding on the
authorization of the key, and use "trust" to mean that a key is stored into the
cryptsetup configuration?
Ciao,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
