[Bug][gpgme] mess with file descriptors

jbar jeanjacquesbrucker at gmail.com
Thu Nov 6 12:10:22 CET 2014


 I have meet strange behaviour of gpgme when having a listenning socket
on the STDOUT_FILENO(=1) file descriptor.

 Can gpgpme not mess with file descriptors used by the calling program,
 or like syslog with openlog(), create one when calling gpgme_new() and
 use only it with the gpgpme context created ?

 My app is thttpgd which is linked to libgpgme-pthread, this is an
 HTTP and HKP server which may sign on-the-fly its HTTP responses*.

 U may try for example :
  - on an HKP request:
  $ curl -v -H "Accept: multipart/msigned" \
  "http://node1.openudc.org/pks/lookup?search=brucker"

  - on a standard file: 
  $ curl -v -H "Accept: multipart/msigned" \
  "http://node1.openudc.org/_open-udc%40muc.jappix.com_/2014/11/06.txt"

This thttpgpd (version 0.3.5) server is linked with
libgpgme11_1.2.0-1.4+deb7u1. And you may see that concerning the second
requests, such strange GNUPG trace are included in the gpgme_data_t
containing the signature :

 [GNUPG:] GOOD_PASSPHRASE
 [GNUPG:] PROGRESS -&6 ? 0 0
 [GNUPG:] BEGIN_SIGNING
 [GNUPG:] PROGRESS -&6 ? 602 0
 [GNUPG:] SIG_CREATED D 1 2 00 1415269682
 53D97DACE2B01EAB4409418E9007C80B71361973

When linking the same thttpgpd (version 0.3.5 and lower) with
libgpgme11_1.3.0 and greater (I did try different versions of gpgpme,
compiled from different tag on your git sources), the second request
didn't sign at all. 

Technically: the call to gpgme_op_sign() in my httpd_parse_resp(), did
return an error, and gpgme_strerror() said "General Error". (If you
build my thttpgpd software to test all yourself, take care to
(clean) the signature's cache used for regular files.)

I found a workaround to that bug, by assigning the STDOUT_FILENO fd
(the n°1) to /dev/null, instead of closing it and so using it later for
a listening socket.
 https://github.com/Open-UDC/thttpgpd/commit/e07fd56d7b5364d658a951688e41bfa295cd0bf5#diff-eac80394dcd9b3636b0c8a47e128d1e6
(I did also assigning STDERR_FILENO to /dev/null, just in case, even if
I didn't notice it changed gpgme's behaviour).

 But I do think it seems there is a vicious bug in gpgme, or a lack of
 documentation to make gpgme user's avoid such bug.

 In the documentation maybe can you also cite now GPGME_DEBUG
 environment variable and that STDERR_FILENO is used to display TRACEs
 when GPGME_DEBUG > 0. :-)


To finish, i hope i am not out-of-topic, but BIG CONGRATULATION for
GnuPG 2.1.0 ! ^^

             ^ _...._      ^
             .'      '.  _...._
        ^   /          \'      '.
            |X        /          \
          -. \        |X         |  ^
        .-. |'.-.   .' \        /
           \;/  `/\`    '.    .'
           / \   (        `/\`
          /   \   \    ^    `)
      ^  /     \   )        (     ^
        /'-...-'\ (          \
       /-.__ __.-\            )
  jgs '._   `   _.'  ^       /
         `"""""` 

-----------------------------------------------------
   _                             .-.
  / )  .-.    ___          __   (   )
 ( (  (   ) .'___)        (__'-._) (
  \ '._) (,'.'               '.     '-.
   '.      /  "\               '    -. '.
     )    /   \ \   .-.   ,'.   )  (  ',_)    _
   .'    (     \ \ (   \ . .' .'    )    .-. ( \
  (  .''. '.    \ \|  .' .' ,',--, /    (   ) ) )
   \ \   ', :    \    .-'  ( (  ( (     _) (,' /
    \ \   : :    )  / _     ' .  \ \  ,'      /
  ,' ,'   : ;   /  /,' '.   /.'  / / ( (\    (
  '.'      "   (    .-'. \       ''   \_)\    \
                \  |    \ \__             )    )
              ___\ |     \___;           /  , /
             /  ___)                    (  ( (
  PN         '.'                         ) ;) ;
                                        (_/(_/
----------------------------------------------------


Notes:
* I plan also to implement OpenPGP HTTP authentication, as
  specified in this draft :
  https://raw.githubusercontent.com/Open-UDC/open-udc/master/docs/HTTP_OpenPGP_Authentication.draft.txt


-- 
Jean-Jacques BRUCKER
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: not available
URL: </pipermail/attachments/20141106/d0ed3a8a/attachment-0001.sig>


More information about the Gnupg-devel mailing list