<feed xmlns='http://www.w3.org/2005/Atom'>
<title>notmuch/test/T350-crypto.sh, branch nmweb</title>
<subtitle>thread-based email index, search, and tagging</subtitle>
<id>https://git.notmuchmail.org/git/notmuch/atom?h=nmweb</id>
<link rel='self' href='https://git.notmuchmail.org/git/notmuch/atom?h=nmweb'/>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/'/>
<updated>2023-07-21T10:41:50Z</updated>
<entry>
<title>test: support testing notmuch as installed</title>
<updated>2023-07-21T10:41:50Z</updated>
<author>
<name>David Bremner</name>
<email>david@tethera.net</email>
</author>
<published>2023-04-09T14:26:26Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=ec26eeaeec87781dee7dbf720103a5bc9b6bba5d'/>
<id>urn:sha1:ec26eeaeec87781dee7dbf720103a5bc9b6bba5d</id>
<content type='text'>
We put some effort into testing the built copy rather than some
installed copy. On the other hand for people like packagers, testing
the installed copy is also of interest.

When NOTMUCH_TEST_INSTALLED is set to a nonempty value, tests do not
require a built notmuch tree or running configure.

Some of the tests marked as broken when running against installed
notmuch are probably fixable.
</content>
</entry>
<entry>
<title>test: compute expected keyid from fingerprint</title>
<updated>2022-09-20T01:19:35Z</updated>
<author>
<name>Justus Winter</name>
<email>justus@sequoia-pgp.org</email>
</author>
<published>2022-09-09T16:12:50Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=acb31939bb01b68dbcd90f6657f859ba35b74e7c'/>
<id>urn:sha1:acb31939bb01b68dbcd90f6657f859ba35b74e7c</id>
<content type='text'>
</content>
</entry>
<entry>
<title>emacs: use cached encoded copy for fcc</title>
<updated>2022-01-26T11:22:09Z</updated>
<author>
<name>David Bremner</name>
<email>david@tethera.net</email>
</author>
<published>2022-01-20T03:22:07Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=da302e1cbaaab89b2bbb32c0f59e1aa6ee708455'/>
<id>urn:sha1:da302e1cbaaab89b2bbb32c0f59e1aa6ee708455</id>
<content type='text'>
This fixes the bug reported by dkg in [1]. The movement of the call to
n-m-setup-message-for-saving is so the cleanup of Fcc headers happens
in the encoded version (otherwise Fcc headers may be saved to disk).

[1]: id:87k1zm225v.fsf@fifthhorseman.net
</content>
</entry>
<entry>
<title>test/emacs: known broken test for matching fcc and sent message</title>
<updated>2022-01-26T11:22:09Z</updated>
<author>
<name>David Bremner</name>
<email>david@tethera.net</email>
</author>
<published>2022-01-20T01:23:30Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=8179c3d1146b6b19c64200f0617c4a1ba7588569'/>
<id>urn:sha1:8179c3d1146b6b19c64200f0617c4a1ba7588569</id>
<content type='text'>
Based on the method outlined by Daniel Kahn Gillmor in
id:87k1zm225v.fsf@fifthhorseman.net.  With a delay of 0.2 seconds the
test becomes flaky on my machine. With a 1 second delay it fails
consistently for more than 1600 iterations.
</content>
</entry>
<entry>
<title>cli/show: produce "email" element in sigstatus</title>
<updated>2021-06-26T16:07:47Z</updated>
<author>
<name>Daniel Kahn Gillmor</name>
<email>dkg@fifthhorseman.net</email>
</author>
<published>2021-05-27T01:44:58Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=8c29a5da096b0314c6cca8889b740b79a9a548ed'/>
<id>urn:sha1:8c29a5da096b0314c6cca8889b740b79a9a548ed</id>
<content type='text'>
When the certificate that signs a message is known to be valid, GMime
is capable of reporting on the e-mail address embedded in the
certificate.

We pass this information along to the caller of "notmuch show", as
often only the e-mail address of the certificate has actually been
checked/verified.

Furthermore, signature verification should probably at some point
compare the e-mail address of the caller against the sender address of
the message itself.  Having to parse what gmime thinks is a "userid"
to extract an e-mail address seems clunky and unnecessary if gmime
already thinks it knows what the e-mail address is.

See id:878s41ax6t.fsf@fifthhorseman.net for more motivation and discussion.

Signed-off-by: Daniel Kahn Gillmor &lt;dkg@fifthhorseman.net&gt;
</content>
</entry>
<entry>
<title>test: source $NOTMUCH_SRCDIR/test/test-lib-emacs.sh</title>
<updated>2021-06-03T12:29:27Z</updated>
<author>
<name>Tomi Ollila</name>
<email>tomi.ollila@iki.fi</email>
</author>
<published>2021-05-23T07:34:43Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=572af2795007464ffbf9cd4656e0e5736d78d362'/>
<id>urn:sha1:572af2795007464ffbf9cd4656e0e5736d78d362</id>
<content type='text'>
Sourcing test-lib.sh will cd to TMP_DIRECTORY, so
relative path in $0 will not work in previous version
 . $(dirname "$0")/test-lib-emacs.sh

Now individual test scripts -- e.g. ./test/T310-emacs.sh
will work.
</content>
</entry>
<entry>
<title>test: split emacs functionality to its own file</title>
<updated>2021-05-17T10:29:04Z</updated>
<author>
<name>Felipe Contreras</name>
<email>felipe.contreras@gmail.com</email>
</author>
<published>2021-05-15T20:47:44Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=92454bc0935604f4a623e75dec9506c0283eee70'/>
<id>urn:sha1:92454bc0935604f4a623e75dec9506c0283eee70</id>
<content type='text'>
This way it's easier to identify the tests that do require emacs stuff.

Signed-off-by: Felipe Contreras &lt;felipe.contreras@gmail.com&gt;
</content>
</entry>
<entry>
<title>test: add external prereqs to many emacs tests</title>
<updated>2021-05-02T00:15:27Z</updated>
<author>
<name>Felipe Contreras</name>
<email>felipe.contreras@gmail.com</email>
</author>
<published>2021-05-01T11:54:16Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=fe9616aef19a1584de550ea536dfc7b42a13636a'/>
<id>urn:sha1:fe9616aef19a1584de550ea536dfc7b42a13636a</id>
<content type='text'>
The tests fail otherwise.

Signed-off-by: Felipe Contreras &lt;felipe.contreras@gmail.com&gt;
</content>
</entry>
<entry>
<title>cli/show: emit new whole-message crypto status output</title>
<updated>2019-05-26T11:20:23Z</updated>
<author>
<name>Daniel Kahn Gillmor</name>
<email>dkg@fifthhorseman.net</email>
</author>
<published>2019-05-25T18:04:06Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=4cb789aa090fb6ba3c7897584ecbcc0a547b2f81'/>
<id>urn:sha1:4cb789aa090fb6ba3c7897584ecbcc0a547b2f81</id>
<content type='text'>
This allows MUAs that don't want to think about per-mime-part
cryptographic status to have a simple high-level overview of the
message's cryptographic state.

Sensibly structured encrypted and/or signed messages will work fine
with this.  The only requirement for the simplest encryption + signing
is that the message have all of its encryption and signing protection
(the "cryptographic envelope") in a contiguous set of MIME layers at
the very outside of the message itself.

This is because messages with some subparts signed or encrypted, but
with other subparts with no cryptographic protection is very difficult
to reason about, and even harder for the user to make sense of or work
with.

For further characterization of the Cryptographic Envelope and some of
the usability tradeoffs, see here:

   https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
</content>
</entry>
<entry>
<title>test/crypto: add_gnupg_home should have ultimate trust on "its own" key</title>
<updated>2019-05-07T09:42:21Z</updated>
<author>
<name>Daniel Kahn Gillmor</name>
<email>dkg@fifthhorseman.net</email>
</author>
<published>2019-05-04T21:33:28Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=7d48604157477054624d010fca496f7eb0d1168b'/>
<id>urn:sha1:7d48604157477054624d010fca496f7eb0d1168b</id>
<content type='text'>
The typical use case for gpg is that if you control a secret key, you
mark it with "ultimate" ownertrust.

The opaque --import-ownertrust mechanism is GnuPG's standard mechanism
to set up ultimate ownertrust (the ":6:" means "ultimate", for
whatever reason).

We adjust the test suite to match this change, inverting the sense of
one test: since the default is now that the user ID of the suite's own
key is valid, we change the test to make sure that the user ID is not
emitted when it is *not* valid.

Signed-off-by: Daniel Kahn Gillmor &lt;dkg@fifthhorseman.net&gt;
</content>
</entry>
</feed>
