[BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6

[Daniel Kahn Gillmor]

On Thu 2020-03-19 08:25:03 -0700, James Bottomley via Gnupg-devel wrote:
> On Thu, 2020-03-19 at 08:21 -0700, James Bottomley via Gnupg-devel wrote:
>> First reply is stuck in moderation.  This has the compressed gpgme
>> log
>
> I should add for the first reply that when I go in and run gpg manually
> over exactly the directories and files the gpgme code is using,
> verification succeeds, and when I try to do the same thing using a test
> programme built on gpgme everything also succeeds, so whatever is
> happening seems to be something to do with the sequence of prior
> operations zypper did.

Thanks for this log, James.

From the log, there are 5 gpgme invocations: gpgme_op_import,
gpgme_op_keylist, gpgme_op_import, gpgme_op_keylist, gpgme_op_verify.

It looks to me like the failure is in the final call to gpgme_op_verify.

In that call, gpgme is feeding the signature via fd 12 (0xc)
successfully to the spawned gpg process's fd 11.  This is correct, given
the first non-option argument -&11.  But it also needs to send the data
via fd 14 (0xe) to gpg's fd 13, given the second non-option argument
-&13.

However it looks like it feeds it the empty string instead of any data
that might have been signed:

GPGME 2020-03-19 08:19:04 <0x3839>    _gpgme_data_outbound_handler: enter: dh=0x55aada91b5c0, fd=0xe
GPGME 2020-03-19 08:19:04 <0x3839>      gpgme_data_read: enter: dh=0x55aada91b5c0, buffer=0x55aada91b5cc, size=4096
GPGME 2020-03-19 08:19:04 <0x3839>      gpgme_data_read: leave: result=0
GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: enter: fd=0xe
GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: check: fd=0xe, invoking close handler 0x7f1e4272bfe0/0x55aadaa39aa0
GPGME 2020-03-19 08:19:04 <0x3839>        _gpgme_remove_io_cb: call: data=0x55aada9ac5c0, setting fd 0xe (item=0x55aada8d2890) done
GPGME 2020-03-19 08:19:04 <0x3839>      _gpgme_io_close: leave: result=0
GPGME 2020-03-19 08:19:04 <0x3839>    _gpgme_data_outbound_handler: leave


Is it possible that the data object being passed to gpgme is corrupted
somehow?

Also, you say that zypper works if you revert this patch.  have you
tested this "working" configuration against a deliberately tampered
message body?  To test that it is working, it's best to verify both that
a valid message is accepted *and* that a tampered message is rejected.

This is gpg's status response, fwiw:

[GNUPG:] PROGRESS -&11 ? 0 0 B
[GNUPG:] PROGRESS -&11 ? 481 0 B
[GNUPG:] PROGRESS -&13 ? 0 0 B
[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED F17A9BC0C01F2AEE49F779EE668EA451E1B7CFAD 0
[GNUPG:] KEY_CONSIDERED F17A9BC0C01F2AEE49F779EE668EA451E1B7CFAD 0
[GNUPG:] BADSIG 668EA451E1B7CFAD home:jejb1:Tumbleweed OBS Project <home:jejb1:Tumbleweed at build.opensuse.org>
[GNUPG:] VERIFICATION_COMPLIANCE_MODE 23
[GNUPG] FAILURE gpg-exit 33554433


I've looked at the libzypp codebase on
https://github.com/openSUSE/libzypp.git, and it seems that verification
is happening in KeyManagerCtx::Impl::readSignaturesFprsOptVerify in
zypp/KeyManager.cc.

It looks to me like that private function declaration is:

    std::list<std::string> readSignaturesFprsOptVerify( const Pathname & signature_r, const Pathname & file_r = "/dev/null", bool * verify_r = nullptr );

Note the default for file_r !

that's only called by two member functions:

    /** Return all fingerprints found in \a signature_r. */
    std::list<std::string> readSignaturesFprs( const Pathname & signature_r )
    { return readSignaturesFprsOptVerify( signature_r ); }

    /** Tries to verify the \a file_r using \a signature_r. */
    bool verifySignaturesFprs( const Pathname & file_r, const Pathname & signature_r )
    {
      bool verify = false;
      readSignaturesFprsOptVerify( signature_r, file_r, &verify );
      return verify;
    }

which are in turn implementations of
KeyManagerCtx::readSignatureFingerprints and KeyManagerCtx::verify.


Is the failure happening for you in a call to
KeyManagerCtx::readSignatureFingerprints or in a call to
KeyManagerCtx::verify ?  (or maybe KeyRing::readSignatureKeyId or
KeyRing::verifyFileSignature, which wrap those functions) ?

a backtrace of the code around the call to gpgme_op_verify would be
helpful.

Regards,

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200326/15fadc06/attachment.sig>