more on read_s2k() for GnuTLS 2.4.1 (including "GNU dummy S2K")

[Simon Josefsson]

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> After reading Nikos' assessment of the state of OpenCDK in handling
> enciphered subpackets, i've backed off from my original goal of
> actually decrypting secret keys.  I'd like GnuTLS to be able to do
> that at some point, but i don't understand OpenCDK's filter model well
> enough yet to actually implement the cipher needed to decrypt locked
> secret keys.

Ouch.  FWIW, I think your goal is fine and it should be supported
eventually.

> For example, you might want to provide a TLS service with the
> Authentication subkey for the host's key, but not provide it with the
> unlocked primary key itself.  Presented with a keyset like this
> (locked primary key, unlocked subkey), and asked to use the subkey,
> GnuTLS will currently fail to operate despite having access to all the
> information needed.

Good example, I agree.

> However, it isn't difficult to actually import such a key (and to
> ensure that such a packet conforms to the flavor emitted by GPG).  The
> attached patch is an update to my earlier read_s2k implementation and
> is capable of interpreting the gnu-dummy S2K extension.  As a GNU
> project, this seems like a worthwhile step to me.
>
> Is there any objection to including this GNU extension in the event
> that a 2.4.2 release is made?
>
> I'd be happy to implement the same thing for the 2.5.x branch as well,
> if there are no objections.
>
> As always, i welcome feedback!

I'm not sure this can go into 2.4.x, it seems like a somewhat large
addition, although I'll let Nikos comment as well.  Maybe it could go
in.

However, this certainly seems appropriate for 2.5.  Please create a
patch for it, and I'll apply it.

Btw, I want to get the 2.6.x release process started, I think we have
enough new features in 2.5.x to be ready for a new stable release.  So
maybe it isn't that important to get into 2.4.x if 2.6.x is release
relatively soon.

/Simon