Commit graph

6984 commits

Author SHA1 Message Date
Daniel Kahn Gillmor
f2a85904f1 Correct doxygen framing for libnotmuch.h
Apparently doxygen needs its comments formatted in a specific way to
notice that the group is closed.

Without this fix, with doxygen 1.8.16-2 we see:

```
doxygen ./doc/doxygen.cfg
…/notmuch/lib/notmuch.h:2322: warning: end of file while inside a group
```

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2020-03-19 21:56:05 -03:00
Daniel Kahn Gillmor
b27b23a7f9 mime-node: Pass the correct flags to g_mime_multipart_signed_verify
GMIME_ENCRYPT_NONE and GMIME_VERIFY_NONE have the same value, but they
are different enumerated types.  So in C, this is a cosmetic change,
but it is technically correct if we only had stricter typing.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2020-03-19 21:55:41 -03:00
Daniel Kahn Gillmor
1c39065245 tests/smime: fix typo in README
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseaman.net>
2020-03-19 21:55:20 -03:00
Daniel Kahn Gillmor
13f2027101 configure: Check GMime version properly
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2020-03-19 21:55:04 -03:00
Daniel Kahn Gillmor
018ad3703b Drop deprecated/unused crypto.gpg_path
crypto.gpg_path was only used when we built against gmime versions
before 3.0.  Since we now depend on gmime 3.0.3 or later, it is
meaningless.

The removal of the field from the _notmuch_config struct would be an
ABI change if that struct were externally exposed, but it is not, so
it's safe to unilaterally remove it.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2020-02-19 08:17:49 -04:00
Peter Wang
c17fca40e2 sprinter: change integer method to use int64_t
In particular, timestamps beyond 2038 could overflow the sprinter
interface on systems where time_t is 64-bit but 'int' is a signed 32-bit
integer type.
2020-02-13 19:10:42 -04:00
Peter Wang
e091427d98 test: add known broken test with timestamp beyond 2038 2020-02-13 19:08:56 -04:00
Daniel Kahn Gillmor
aba7fb375b doc: clean up manpage description of "notmuch-config list" output
The escaping in the description of the output of "notmuch-config list"
appears to have been inherited from some previous attempts at
documentation.  It leaked out in the actual generated manpage
documentation, where it looks like this:

       list   Every  configuration  item is printed to stdout, each on a
              separate line of the form:

                 *section*.\ *item*\ =\ *value*

This simplification cleans up the overescaping.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2020-01-16 06:38:29 -04:00
Daniel Kahn Gillmor
0a0413f514 debian: add Build-Depends-Package for libnotmuch5.symbols
See lintian informational tag
symbols-file-missing-build-depends-package-field for hints about this
minor metadata update.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2020-01-09 22:18:31 -04:00
Steven Allen
92a7f26fac emacs: don't start processes stopped
It causes this function to fail with:

    let: Wrong type argument: null, t

Support for this was removed from Emacs in April
2019 (5c5e309527e6b582e2c04b83e7af45f3144863ac) because it never
worked correctly (apparently).

This also shouldn't be necessary as sentinels will not be called
unless emacs is idle or waiting for input. Therefore, the
`process-put' calls immediately following the `make-process' call
should always complete before the sentinel is first called.
2020-01-08 21:14:47 -04:00
Daniel Kahn Gillmor
fd9a951249 legacy-display: drop tests that try to match headers in a Legacy Display part
These tests were an attempt to establish that the content of the
"Legacy Display" part is the same as the actual protected headers of
the message.  But this is more conservative than we need to be.

https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
section 5.3 makes clear that the Legacy Display part is purely
decorative, and section 5.2.1 clarifies that the detection can be done
purely by MIME structure and Content-Type alone.

Furthermore, now that we're accepting text/plain Legacy Display parts,
it's not clear the lines in the Legacy Display part should be
interpreted as needing an exact string match (e.g. "real" headers are
likely to be RFC 2047 encoded, but the text/plain Legacy Display part
probably should not be).

The concerns that motivated this test in the past were twofold: that
we might accidentally hide some information from the reader of the
message that they should have available to them, or that we could
introduce a covert channel that would be invisible to other clients.

I no longer think these are significant concerns:

 a) There will be no accidental misidentification of a Legacy Display
    part.  The identification of the Legacy Display part is
    unambiguous due to MIME structure and Content-Type.  MIME
    structure MUST be the first child part of a two-part
    multipart/mixed Cryptographic Payload. And the
    protected-headers=v1 content-type parameter must be present on
    both the cryptographic payload and the legacy display part, so no
    one would accidentally generate this structure and have it be
    accidentally matched.

 b) As for creating a covert channel, many such channels already
    exist.  For example, non-standard e-mail headers, custom MIME
    types, unusual MIME structures, etc, all make it possible to ship
    some content in a message that will be visible in some MUAs but
    not in others.  This doesn't make the situation demonstrably
    worse.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2020-01-08 21:12:12 -04:00
Daniel Kahn Gillmor
5aa60342c8 legacy-display: accept text/plain legacy display parts
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
Makes it clear that the "Legacy Display" part of an encrypted message
with protected headers can (and indeed, should) be of content-type
text/plain, though some clients still generate the Legacy Display part
as content-type text/rfc822-headers.  Notmuch should recognize the
part whichever of the two content-types it uses.

See also discussion in
https://github.com/autocrypt/protected-headers/issues/23 for why the
community of implementers is moving in the direction of text/plain.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2020-01-08 21:09:21 -04:00
Daniel Kahn Gillmor
cedc6db19d debian: Override lintian suggestion to move elpa-notmuch to Section: lisp
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-25 11:43:17 +09:00
Daniel Kahn Gillmor
93cc4b99df python/notmuch2: fix typo for "destroyed"
Another fix to the docstrings, this time for the English part of the
docstrings, not the Python class name.  No functional changes here.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-24 07:13:09 +09:00
Daniel Kahn Gillmor
34c5233894 python/notmuch2: fix typo for ObjectDestroyedError
There is no functional change here, just a fix to a typo in the
docstrings.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-24 07:12:51 +09:00
Daniel Kahn Gillmor
b5db6aa127 debian: move packaging to dh 12 2019-12-21 08:59:47 +09:00
Daniel Kahn Gillmor
a2ecab4762 debian elpa-notmuch: ship elisp and .png from "make install"
Rather than ship from the source directories, ship these files from
where they're installed by "make install".

This doesn't resolve all the dh_missing warnings yet (due to #946142),
but it leaves the last bit of that problem in the hands of the dh-elpa
package, and it's not due to notmuch's packaging any longer.

Note that notmuch-pkg.el is only relevant for elpa, so it was not
installed by "make install", and has to be extracted deliberately from
the source tree.

Note also that we now don't ship make-deps.el or rstdoc.el, as these
are build tools and don't belong in the deployed package.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-21 08:59:36 +09:00
Daniel Kahn Gillmor
a24006d62f debian: ship info files in the standard location
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-21 08:59:02 +09:00
Daniel Kahn Gillmor
bfa9971383 debian: record upstream files which should not be installed by the package
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-21 08:58:40 +09:00
Daniel Kahn Gillmor
cc62d33c07 debian: Remove python2 detritus
Since we removed python-notmuch, we do not need to retain this file
any longer.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-21 08:56:00 +09:00
Daniel Kahn Gillmor
dbb8e420c1 debian: ship notmuch-setup(1) as a copy of notmuch(1)
This was being shipped by "make install", but we weren't shipping it
in the debian package.  Thanks to dh_missing for noticing!

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-21 08:55:33 +09:00
Daniel Kahn Gillmor
dc0650f5f5 debian: install notmuch(3) manpage in libnotmuch-dev
dh_missing noticed that we are building this manpage but not shipping
it in debian.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-21 08:55:08 +09:00
Daniel Kahn Gillmor
158dc389e9 debian: ship notmuch-emacs-mua.desktop from "make install" copy
This helps dh_missing know what's going on.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-21 08:54:37 +09:00
Daniel Kahn Gillmor
7ebb2f5509 debian: return an error if debian snapshot build fails
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-21 08:54:11 +09:00
Örjan Ekeberg
757ed001aa test: extend test of attachment warnings
Check that attachment warnings are not raised when the word
"attach" only occurs in a forwarded message.
2019-12-14 07:29:00 -04:00
Örjan Ekeberg
1d9ec88d87 emacs: limit search for attachment to stop at first mime-part
This commit changes the behaviour of notmuch-mua-attachment-check
so that it stops searching for notmuch-mua-attachment-regexp when a
new mime-part is reached.  This avoids false warnings when matching
words occur inside forwarded messages.
2019-12-14 07:28:42 -04:00
David Bremner
6cd47227de test: add a known broken test for S/MIME decryption
This should serve to clarify this feature is not implimented in
notmuch yet.
2019-12-14 07:25:06 -04:00
David Edmondson
a7884929d5 emacs: Improve the reporting of key activity
Improve the information provided about key retrieval and key validity.
2019-12-14 07:23:42 -04:00
David Edmondson
d137afface emacs: Add notmuch-crypto-gpg-program and use it
Allow the user to specify the gpg program to use when retrieving keys,
etc., defaulting to the value of `epg-gpg-program'.
2019-12-14 07:23:29 -04:00
David Edmondson
50f0cbcc4d emacs: Minor refactoring of crypto code 2019-12-14 07:23:06 -04:00
David Edmondson
a1d6e406f6 emacs: Asynchronous retrieval of GPG keys
Rather than blocking emacs while gpg does its' thing, by default run
key retrieval asynchronously, possibly updating the display of the
message on successful completion.
2019-12-14 07:22:53 -04:00
Tomi Ollila
eb1f799892 configure: fix reference to possibly undefined $PKG_CONFIG_PATH
In case zlib not found by pkg-config(1) the pkg-config information
is resolved by attempting to print ZLIB_VERSION from from zlib
installation if it exists anyway.

If above done successfully compat/zlib.pc is written for forthcoming
pkg-config execution.

Since `set -u` is in effect (since 124a67e96, 2016-05-06),
expanding unset $PKG_CONFIG_PATH (would have) failed whenever tried.

Now it is changed to set as "$PKG_CONFIG_PATH:compat" if PKG_CONFIG_PATH
is set and is non-empty string, plain "compat" otherwise.
2019-12-09 16:24:37 -04:00
Daniel Kahn Gillmor
e712b91f46 wrap-and-sort -ast
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-04 08:06:19 -04:00
Daniel Kahn Gillmor
fe66c3048a Add debian/upstream/metadata (for DEP-12)
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-03 19:11:15 -04:00
Daniel Kahn Gillmor
20bd613261 debian/copyright: use secure git URL
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-03 19:09:38 -04:00
Daniel Kahn Gillmor
7ffff7927c Rules-Requires-Root: no (we do nothing as root during package build)
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-03 19:09:06 -04:00
Daniel Kahn Gillmor
575f207b3d Standards-Version: bump to 4.4.1 (no changes needed)
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-12-03 19:08:11 -04:00
Oliver Kiddle
2044c7aad9 configure: Install zsh completions where zsh will find them.
Zsh searches in the $fpath array for completion functions. By default
this includes $(prefix)/share/zsh/site-functions but not the existing
value. The prefix for zsh and notmuch isn't guaranteed to be the same
but it normally will be making this a better default for
zsh_completion_dir.
2019-12-03 08:25:55 -04:00
David Bremner
3185830e3a python-cffi: use shutil.which
I was supposed to amend the original patch that added this function,
but somehow I botched that. The original version runs, so make an
extra commit for the tidying.
2019-12-03 08:12:30 -04:00
Floris Bruynooghe
1e072204cd Move from _add_message to _index_file API
This moves away from the deprecated notmuch_database_add_message API
and instead uses the notmuch_database_index_file API.  This means
instroducing a class to manage the index options and bumping the
library version requirement to 5.1.
2019-12-03 08:12:30 -04:00
Floris Bruynooghe
e2df30f7a9 Rename package to notmuch2
This is based on a previous discussion on the list where this was more
or less seen as the least-bad option.
2019-12-03 08:12:30 -04:00
Floris Bruynooghe
a950aa2844 Show which notmuch command and version is being used
This add the notmuch version and absolute path of the binary used
in the pytest header.  This is nice when running the tests
interactively as you get confirmation you're testing the version you
thought you were testing.
2019-12-03 08:12:30 -04:00
David Bremner
fbb8e1f430 debian: add python3 dependencies for the new python bindings
These should generally match those in .travis.yml
2019-12-03 08:12:30 -04:00
David Bremner
a48ccb5ef8 switch travis to bionic
This should solve the problem with pytest versions. Drop the notmuch
PPA, as (hopefully) we don't need those packages in bionic
2019-12-03 08:12:30 -04:00
David Bremner
af8c069194 travis: add python3-{cffi,pytest,setuptools}, libpython3-all-dev
These are needed for building and testing the new python bindings.
2019-12-03 08:12:30 -04:00
David Bremner
85adc756c9 tests: run python-cffi tests
The entire python-cffi test suite is considered as a single test at
the level of the notmuch test suite. This might or might not be ideal,
but it gets them run.
2019-12-03 08:12:30 -04:00
David Bremner
46e9615621 build: optionally build python-cffi bindings
Put the build product (and tests) in a well known location so that we
can find them e.g. from the tests.
2019-12-03 08:12:30 -04:00
David Bremner
3aaa8cfe94 configure: check for python cffi and pytest modules
This is needed to build the new python bindings, and run their tests.
2019-12-03 08:12:30 -04:00
David Bremner
e8cb7c7f60 bindings/python-cffi: preserve environment for tests
We'll need this e.g. to pass PATH to the pytest tests

Based on the suggested approach in id:87d0eljggj.fsf@powell.devork.be
2019-12-03 08:12:30 -04:00
Floris Bruynooghe
83c2d15898 Introduce CFFI-based python bindings
This introduces CFFI-based Python3-only bindings.
The bindings aim at:
- Better performance on pypy
- Easier to use Python-C interface
- More "pythonic"
  - The API should not allow invalid operations
  - Use native object protocol where possible
- Memory safety; whatever you do from python, it should not coredump.
2019-12-03 08:12:30 -04:00