Proposal for a Desktop Neutral Crypto API

[Nate Nielsen]

Mike Hearn wrote:
>>- To allow the various implementors to use different toolkits and
>>   libraries and to avoid implementation details and requirements
>>   leaking. This allows each desktop to implement the API according to
>>   their own coding style. An important factor if this is to gain
>>   traction in the myriad of applications that require encryption
>>   services.
> 
> This does _not_ seem like a good reason. The libdbus API itself has a
> coding style, as all APIs do. Defining an API in terms of DBUS messages
> does not make it magically acceptable to everybody, or shouldn't do. It is
> just yet another way to write an API.

True.

> I am also a bit concerned by the idea that each desktop (KDE, GNOME, ROX,
> XFCE etc) should implement this themselves. Why is that better than one
> canonical implementation?

The API has more to do with key selection (ie: user interface), high
level encryption (which could imply possibly progress dialogs), and
tight integration with the desktop.

In order to fit in with the user experience, each desktop would want to
have their own implementation.

>>- It's clean and simple. Doesn't bring dependencies into the calling
>>   program. 
> 
> But it does: it requires, at minimum, libdbus and security privileges to
> connect to the bus. That means things like SELinux are affected. It also
> really requires either threads or a libdbus-compatible main loop, unless
> you don't mind blocking for potentially long periods of time.

Correct.

>>             Allows swapping of implementations when the user / admin /
>>   distro requires. 
> 
> 
> But a shared library with a well defined interfaces allows this too.

Let's say my initial implementation does not include LDAP key server
lookups, then later I'd like to add that. Then all of a sudden each
consumer of this shared library gets a dependency on OpenLDAP. Yes, it's
a contrived example, seeing that everyone already has this feature, but
this demonstrates what I was thinking about.

>>Given that many applications and desktops already each have their own
>>encryption solution going, an effort like this needs to be as
>>transparent and simple as possible implementation-wise in order to go
>>anywhere.
> 
> OK, well you seem to have at least thought it through pretty carefully.
> Maybe you should just code it up with an implementation or two and propose
> it for inclusion to GNOME and KDE directly: there seems little reason to
> try and produce a standard first before anybody has real world experience
> with the design.

Yes, point taken. Seahorse will experiment with this API, as it
currently spans several processes (with plugins and the like).

I'm obviously interested in GNOME, but I brought this proposal up so
others could colaborate and perhaps gain these (what I see as) benefits
for their desktops.

Cheers,
Nate