OpenPGP certificate/key management thoughts about function re-organization and cleanup

[Simon Josefsson]

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

> On Mon, Jun 16, 2008 at 12:07 PM, Simon Josefsson <simon at josefsson.org> wrote:
>
>>> Primary Keys vs. Subkeys
>>> ------------------------
>>>
>>> There are currently a lot of duplicated functions which deal with the
>>> subkey and primary keys differently.  For example:
>>>
>>>  gnutls_openpgp_crt_get_pk_algorithm()
>>>  gnutls_openpgp_crt_get_subkey_pk_algorithm()
>>>
>>> These behave exactly the same way, but the primary key is sort of
>>> special-cased out.
>>>
>>> When writing key management code, one often abstracts away the
>>> differences between primary keys and subkeys, and needs to just walk
>>> through each key separately.  Having to call different functions for
>>> the subkey than for the primary key is awkward and makes for a lot of
>>> code duplication, which is room for error.
>>>
>>> We could significantly reduce the number of functions exposed by
>>> GnuTLS if we were to collapse these pairs of functions into a single
>>> function which takes a key index.  Key index 0 would be the primary
>>> key, key index 1 would be the first subkey, etc.  This would allow
>>> much simpler looping constructs over a keyset, and would make the
>>> documentation easier to scan and understand.
>>
>> I think this suggestion makes sense, although I'm not an OpenPGP expert.
>> I have also found the number of APIs related to keys+subkeys rather
>> overwhelming.
>
> Actually the idea was to replace them completely. But since we wanted
> backwards compatibility, this is the reason of the
> non subkey functions still existing. A change would still be possible
> by deprecating the non subkey functions and adding functionality to
> the subkey ones so they handle primary keys as well. However this is a
> big change for last minute change. (although I like this change).
>
> If this is to occur I'd suggest to delay the release for another 1-2
> months and merge with the other development branch. Otherwise with
> these changes merging would be impossible.

I think we shouldn't loose the opportunity to do a stable release now,
we are in pretty good state.  There are many users that don't care about
the OpenPGP stuff, and delaying things would just because it is possible
to do things better would delay us indefinitely.

>> I think the size of the installed base for the OpenPGP stuff is rather
>> limited, so I'm quite open to improving the API in this area.  We should
>> make an effort to maintain ABI compatibility though.
>
> Well I think currently this is a dilema. It is not easy to have both
> non duplicated functions a backwards compatibility. The previous
> interface was quite limited.
>
>> Hm.  Maybe we can add a libgnutls-openpgp which contains a simplified
>> OpenPGP related API?  Eventually, the old OpenPGP API in libgnutls could
>> be deprecated.
>
> I don't think it is a good idea to offer alternative APIs. I'm in
> favor for either a fix in the library, or a delay until the next ABI
> break.

The duplicated functions would only be there during a transition period,
so I think it could work.  The current API could be re-implemented using
the new API.  I think we are stuck with supporting the current OpenPGP
API for the next few years regardless of what we do.  Isolating those
functions into a "compat" style package could help us avoid ugly code.

I don't have time to work on the OpenPGP stuff actively, so I'm relying
on you, Daniel and others to do the work here.

/Simon