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

[James Bottomley]

On Thu, 2020-03-26 at 09:44 -0400, Daniel Kahn Gillmor wrote:
> 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.

There are actually more details in the email that's stuck in moderation
if you can unstick it ... it's only about 40k over the list limit.

> 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?

It must be ... and it's something to do with the sequence, not just
individual signatures.  All the test cases I constructed so far using
exactly the same data as zypper pass just fine.

> 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.

I can check ... I just have to set up a corrupt repo, hang on.

> 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.

It's in the missing email ... if you can't free it from moderation, I
can break it up.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200326/e737dccc/attachment.sig>