test failure on git master with decrypt-session-key.scm (and: continuous integration?)

[Justus Winter]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> [ Unknown signature status ]

(Off-topic: I'm using notmuch with the emacs frontend as distributed by
Debian.  In the notmuch-show buffer it says:

[ Good signature by key: 0x38276051EA477FA3E49539321498ADC6C1923237 ]

However, as soon as I hit reply, it says unknown signature status.)

> After a "make check" from git master, i see:
>
> Failed tests: decrypt-session-key.scm 
> Makefile:920: recipe for target 'xcheck' failed
> make: *** [xcheck] Error 1
>
> and decrypt-session-key.scm.log contains:
>
> -----------
> Checking decryption of supplied files using the session key. 
>     > plain-1 gpg: Fatal: can't open '/tmp/gpgscm-20170226T080733-run-tests-v5v0mB/trustdb.gpg': No such file or directory
> : ()
> 0: tests.scm:140: (throw (:stderr result))
> 1: decrypt-session-key.scm:25: (call-popen `(, at gpg --status-fd=1 --decrypt --show-session-key --output ,sink ,filename) "")
> -----------
>
> Using "git bisect", it appears that commit
> effa80e0b5fd8cf9e31a984afe391c2406edee8b ("gpg: Emit new status
> DECRYPTION_KEY") introduces the failure, probably because gpg is now
> trying to learn the trust associated with the key it's emitting.
>
> I'm not sure the right way to fix this.  The simplest way is probably to
> create a trustdb.gpg for the test, but it also seems like gpg --decrypt
> shouldn't fail if the trustdb.gpg file is missing, either.

I dug into this.  The change introduced a status line which includes the
owner trust of the key used to decrypt the message.

The reason why this breaks the tests is that we run all tests (except
for the TOFU test) with --always-trust, hence no trust database is ever
created.  It only breaks this particular test because it is the only
decryption test using --status-fd.

This really highlights two problems: 1/ What should the new status line
say when used with --always-trust?  2/ The code doesn't cope well when
querying / updating the trustdb fails.  This isn't easy to fix
unfortunately.

> Zooming out a bit:
>
> GnuPG has a good test suite, but this commit has been on master for over
> two days now.  I'm a little surprised it hasn't been caught.  Would it
> be possible to set up some sort of continuous integration server that
> would run the test suite on each new commit?

We don't build every revision, but we do builds as post-commit action,
and nightly builds, weekly for the stable branches.

> It'd be nice if commits wouldn't be merged to master without passing a
> continuous integration check like this as well.  This would have caught
> my recent mistake committing Yuri Chornoivan's word replication cleanup,

That is a policy change and needs to be discussed.  Our current
unwritten policy is: please run make check before pushing changes to
catch the most obvious problems, but if problems crop up in distcheck
or on non-Linux platforms, it is ok to fix them afterwards.

> which also broke the test suite because the test suite depends on a
> duplicated word.  Thanks to Gniibe for catching my error and fixing
> it!

Ouch :/


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170228/4ecf7da0/attachment.sig>