[Authentication] Spec review (part 1)

[Michael Leupold]

Hi Stef,

2010/9/21 Stef Walter <stefw at gnome.org>:
>>> 2) On the other hand, encryption introduces a lot of ugliness. Secrets are put
>>> on the bus as byte arrays, at the moment it isn't even specified how
>>> (decrypted) byte arrays translate to strings afterwards. Getting rid of
>>> encryption allows to use the D-Bus type system. Two possibilities:
>>> a) secrets are D-Bus variants ("v")
>>> b) overloading for several common types (like "s", "ay" and "a{ss}")
>>
>> I agree that this is a bit of a mess and an oversight on my part. I
>> think we should specify how those secrets are encoded. I see two ways:
>>
>> 1. Add an extra property to detail how the secret of an item is
>> encoded. Possible values and encodings have to be specified.
>>
>> 2. Specify that the decrypted secret IS a D-Bus variant.
>
> So this would be like a 'content-type' sort of property on the secret?

Yes, that was my thought. I guess 2. would be a bit messy. I don't
think we need all types the D-Bus system provides and reimplementing
D-Bus variants might be messy.

So this leaves us with either:

a) A "Type" property
b) An optional "Type" attribute
c) A "type" member in the Secret-struct

I like a) for its simplicity, b) seems kinda awkward with the only
benefit being that you could search/filter items by type, c) seems to
be the cleanest solution. It provides consistency as you'd always
get/set the actual value and its type in one go. I'd be in favour of
c).

The types KDE's KWallet currently uses are:
 - Unknown/raw data/array of bytes (could be set on all existing
items for backwards compatibility)
 - UTF-8 string
 - Dict<String, String> (serialization would still have to be decided upon)

We basically need this for backwards compatibility and I also believe
that being able to figure out how a secret has to be interpreted is
really necessary.

>>> 3) Since the spec says that items can be locked / unlocked individually, a
>>> "Locked" property for the collection makes no sense.
>>
>> We talked about this and I'm actually not really sure about what this
>> means either.
>>
>> @Stef: Was this supposed to mean that all items in the collection are
>> unlocked or that the collection itself is ready for change (adding
>> items/changing properties)? How did you implement it?
>
> You're right. I implemented it so that when all the items are unlocked,
> the collection becomes unlocked. But I can see why it might be confusing.
>
> We specifically want the spec to treat items on their own as far as
> locking and unlocking, even if the daemon unlocks everything in a
> collection as a side effect of unlocking one item.
>
> This is because in the future when we have support for identifying
> applications securely (see above about security contexts), then we can
> unlock certain items for certain apps. Apps that don't have access to an
> item, would see it as locked, while another app can see that same item
> as unlocked.

I agree. Keeping unlocked Items and Collections separate is a good
thing. But how is an application supposed to know when it can change a
collection's label? Should it just unlock the collection and try? Or
try to set the Label without unlocking and do that when it receives an
IsLocked error?

>>> 5) Unlocking of the secret storage might take some time without ever creating
>>> a prompt (e.g. hardware needed takes some time to initialize, etc). I suggest
>>> to rename Prompt to Job.
>>
>> I don't think renaming it is worth it, even if it might make sense
>> semantically. After all there's already software out there which uses
>> the spec.
>
> Out of interest, how many implementations are there that you know of?

Well, there's gnome-keyring and iirc Michael Albinus is/was working on
a lisp/emacs implementation.

Regards,
Michael