fleshing out the XML result of gpgme-tool's KEYLIST command

[Werner Koch]

On Thu, 20 Sep 2012 19:13, wking at tremily.us said:
> The current keylist XML of gpgme-tool is not very useful:

It depends on what you expect.  After all gpgme-tool is a debugging tool
to present the GPGME API using an Assuan interface.

>   C: KEYLIST 2F73DE2E
>   S: D key:B2EDBE0E771A4B8708DD16A7511AEDA64332B6E3%0A
>   S: OK

Here you get the output of the keylist operation.

>   C: RESULT 2F73DE2E
>   S: D <?xml version="1.0" encoding="UTF-8" standalone="yes"?>%0A\x00
>   S: D <gpgme>%0A\x00
>   S: D   <keylist-result>%0A
>   S: D     <truncated value="0x0" />%0A
>   S: D   </keylist-result>%0A
>   S: D </gpgme>%0A\x00
>   S: OK
>   C: BYE
>   S: OK closing connection
>   disconnecting

and here the result values of the last gpgme operation, which in that
case was a gpgme_op_keylist_next.  The result values are a kind of
extended return code.  Don't mix them up with the output of a function.

The result object for the keylist operation is:

  struct _gpgme_op_keylist_result
  {
    unsigned int truncated : 1;
  
    /* Internal to GPGME, do not use.  */
    unsigned int _unused : 31;
  };
  
Thus I can't see what is missing from the result value.

> I'd like the result to include all the information about the requested
> keys (although it doesn't need to recurse through subkeys).  I could

Okay, that is changing the output format.  Makes sense.  In fact the
code remarks that more work is needed.

	  char buf[100];
	  /* FIXME: More data.  */
	  snprintf (buf, sizeof (buf), "key:%s\n", key->subkeys->fpr);
          /* Write data and flush so that we see one D line for each
             key.  This does not change the semantics but is easier to
             read by organic eyes.  */

I don't know how you want to format the output, it might resemble what
"gpg --with-colons --list-keys" does or some XML or SXML format.

> 1. My INPUT/OUTPUT patch has been languishing for five months.

It does not fix the bug you are seeing.

> 2. Deciding on and XML representation for keys may require a lot of
>    bike-shed-level decisions.

Keep me out of this ;-).

> So perhaps it would be better for me to wait and let someone closer to
> the core handle this?  I could also let this sit, and bring it up
> again in six months when people might have more time…

Go ahead.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.