[GPGME PATCH] core: Enable extraction of session keys.

[Werner Koch]

On Tue, 15 Nov 2016 13:32, dkg at fifthhorseman.net said:

> not be used by code compiled with a header for the newer API", are you
> implying that there's mechanism to enforce that?  I don't think "tinkers

If you build software using a new header we can assume that the it is
also linked to the matching version of the library.  The SO minor number
will be bumped up for the release (but not in the git version).  By
tinkering with the build system I mean to force linking against an older
SO; that is installing just the application but not the library and
hoping that everything works.

> with the choice of using gpgme_set_ctx_flag instead of
> gpgme_set_export_session_keys, we don't have any exported symbol to
> catch errors when the dynamic linker runs.

We have

 gpgme_set_sender                NEW.
 gpgme_get_sender                NEW.
 gpgme_op_query_swdb             NEW.
 gpgme_op_query_swdb_result      NEW.
 gpgme_query_swdb_result_t       NEW.
 gpgme_get_ctx_flag              NEW.

however they are most likely not used.  That is the same as with
gpgme_set_export_session_keys.

> versioning in the associated package as a result (we track which version
> a new symbol was added).  I don't think we have any way to do that

Well, we have new exported symbols.  And the SO minor will be bumbed.
So both mechanismn are in place; the Debian thing and the proper thing
all libraries should do.

> If this is intended to be an example for how others should use this
> feature, it's a bit dangerous to not check the error return value from
> gpgme_set_ctx_flag, no?

Okay, I thought I could leave that out because we don't have a way to
check whether the override works in gpg.  But, okay for education I add
an error check.

> It would be good to have a bit of documentation that ensures that the
> user at least tests that the flags have been properly set.

We are extending the result structures for more than 10 years.  I am not
aware of any problems related to this.  Granted, some of these changes
are merely new bits taken from a reserved bit field variable but often
enough we added new pointer fields.

> +You must not try to access this member of the struct unless
> + at code{gpgme_set_ctx_flag (ctx, "export-session-key")} returns
> + at code{GPG_ERR_NO_ERROR} or @code{gpgme_get_ctx_flag (ctx,

We would need to add such requirments to a lot of other fucntions as
well.  For example the TOFU stuff also adds new fields to the result
structure which _may_ only be set when GPGME_KEYLIST_MODE_WITH_TOFU is
used.

> another (hacky) advantage of this is that compliant reliant code might
> make use of the newly-introduced symbols gpgme_get_ctx_flag(), which
> would give us the exposed symbol indicators that debian (and similar
> systems) could use for dependency tracking :)

For backward compatible changes on glibc systems we bump the minor SO
number - what's wrong with this approach?  Just because some projects
don't do proper ABI tracking we shall fallback to such hacks as tracking
new symbol names?

If you really really want it, I guess we could add extra code on glibc
systems to detect broken installations.  But is it really worse the
trouble and extra bugs just due to this code?  We used such magic in
GNOME more than 15 years ago.  Can you point me to any bug reported
related to GPGME caused by such improper use?  I only recall problems
with off_t and off64_t for which we added detection code to gpgme.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161115/4807bbb0/attachment.sig>