comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]

[Gabor Toth]

>>>>> On Tue, 15 Jan 2013 09:31:25 -0500, Dan Winship <danw at gnome.org> said:

> dconf uses a model where any process can mmap the database file directly
> to read it, but writes have to go through a central server. (I think
> every time you do a write, it creates a new copy of the database and
> atomically overwrites the old one, and then the clients all reopen the
> file. Which is reasonable if reads are frequent and writes are rare.)

> (Actually... we could just use dconf even... It only depends on glib and
> dbus, and the dconf package itself is pretty tiny...)

Looked into dconf, it would be suitable for storing pinning information. Allows
concurrent reads and writes by multiple applications of the same user. Writes
are handled by a DBus service, which is automatically started if not running.

It also supports layered databases, which can be used to store pre-configured
pins in a system-wide read-only database, upon which the writable user dbs are
layered.

Records for peers with pinning information for the different pinning protocols
could be stored under /system/tls/pinning/peers/$host/$proto/$port/$record_id/
where the type field of a record refers to the pinning protocol that defines the
structure of the record.

-tg