[vlc-devel] [PATCH 1/4] add vlc_keystore API
remi at remlab.net
Thu Nov 26 13:31:17 CET 2015
Le 2015-11-26 13:39, Thomas Guillem a écrit :
> OK, we may then remove user as input for http, but there are other
> protocol that can use an user as input like smb (user can be
> via command line arguments).
I must disagree. SMB and FTP are no different than HTTP.
The credentials are the pair of the username and password.
Besides username in URL is deprecated and discouraged for all
>> > +#define KEY_PROTOCOL "protocol"
>> > +#define KEY_PORT "port"
>> > +#define KEY_SERVER "server" /* use it for KEY_HOST */
>> > +#define KEY_DOMAIN "domain"
>> > +#define KEY_REALM "realm"
>> > +#define KEY_PATH "path"
>> This seems more convoluted than necessary and less generic than
>> and the authentication type is missing.
> Maybe I'll add some http/smb/ftp helpers that will use the
> vlc_keystore_dict_store and these keys.
That's logically impossible. HTTP(S) needs an auth type, a realm, an
URL, and hypothetically some auth type specific scoping parameters. Type
and type-specific parameters can conceivably be coded in the output
rather than the input. But there is no URL in the key set above.
I think it is _not_ reasonable to require the back-end have such level
of abstraction, unless we actually need that abstraction. I still fail
to see any justification for the generic dictionary thing. I don't want
to have reverse abstraction and subtle differences and bugs in the
I note that kwallet indexes by URL, not by dictionary. It's probably
>> While I would agree that a key store API should support deleting
>> manually, I doubt that it will be:
>> 1/ accessible/useful in VLC,
>> 2/ universally supported by all back-ends.
>> That would rather seem to belong in the password manager
> Yes, I hesitated too for this one, but I thought maybe we'll add a
> libvlc_keystore api to use this function.
We should leave it up to the back-end whether the secrets are shared
with LibVLC apps, and with other apps, IMHO, deletion belongs in the
back-end-specific manager, _not_ belong in the media player, especially
>> Same here.
> That's the function that retrieve the secret from a found entry.
> With libsecret (And I hope with others modules too), you can search
> items without unlocking the keyring, and without fetching the secret.
> This function will unlock the keyring (if not unlocked), and fetch
> password from the service. Because you don't want to unlock a keyring
> (and ask the user for the master password) for nothing if no items
You can't know what's inside the key ring if you don't unlock it.
I would argue that your back-end sucks very much if it even allows
listing entries while locked.
More information about the vlc-devel