Distribute clearsigned sha256sum file in addition to the detached
signature.
Verifies that use the sha256sum ensure that the thing signed includes
the name of the tarball. This defends the verifier by default against
a freeze, rollback, or project substitution attack.
A verifier can use something like the following (as expressed in
bash):
set -o pipefail
wget https://notmuchmail.org/releases/notmuch-$VERSION.tar.gz{,.sha256.asc}
gpgv --keyring ./notmuch-signers.pgp --output - notmuch-$VERSION.tar.gz.sha256.asc | sha256sum -c -
See id:87r2b8w956.fsf@fifthhorseman.net and other messages in that
thread for discussion.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The SHA256_FILE used to be built automatically because of the makefile
dependencies.
Since b8a8dbed91, it isn't getting made
properly, so the release target would fail.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Without this change, we see this during the build:
sphinx-build -b html -d doc/_build/doctrees -q ./doc doc/_build/html
…/doc/notmuch-emacs.rst:67: WARNING: Unexpected indentation.
…/doc/notmuch-emacs.rst:165: WARNING: Unexpected indentation.
…/doc/notmuch-emacs.rst:306: WARNING: Unexpected indentation.
This source change doesn't seem to have any effect on the generated
HTML, at least.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This should silence some warnings about the jobserver, but also make
it easier to build the docs where GNU make is called something other
than make.
Based on a patch from aidecoe.
Adam Majer pointed out in [1] the way were signing releases was
unusual. Neither Carl nor I could think of a good reason for
explicitely signing the checksum (internally of course that's what GPG
is going anyway).
[1] mid:b3fd556d-c346-7af9-a7a2-13b0f3235071@suse.de
libnotmuch_util.a is supposed to be usable from the library and the
CLI, but much the library is compiled as C++. Add in appropriate
wrapping to prevent symbol mangling. These wrappers already existed in
string-util.h; it seems better to be consistent.
The exact error messages returned by regerror() aren't standardized;
relying on them isn't portable. Thus, add a a prefix to make clear that
the subsequent message is a regexp parsing error, and only look for this
prefix in the test suite, ignoring the rest of the message.
POSIX doesn't specify the flushing behaviour of the STDOUT stream, so
it's invalid to assume a particular order between the stdout and stderr
output. The current test breaks on musl due to this.
In certain conditions the parallel calls to sphinx-build could
collide, yielding a crash like
Exception occurred:
File "/usr/lib/python3/dist-packages/sphinx/environment.py", line 1261, in get_doctree
doctree = pickle.load(f)
EOFError: Ran out of input
I can't figure out how checking the sign of a bool ever worked. The
following program demonstrates the problem (i.e. for me it prints 1).
#include <stdio.h>
#include <stdbool.h>
int main(int argc, char **argv) {
bool x;
x = -1;
printf("x = %d\n", x);
}
This seems to be mandated by the C99 standard 6.3.1.2.
In Python bindings, Message.get_property fails with an AttributeError when trying to fetch a property that doesn't exist.
From d712832ba982085975c27b23bb502af82e638b39 Mon Sep 17 00:00:00 2001
From: hydrargyrum <dev@indigo.re>
Date: Sun, 6 Jan 2019 16:08:55 +0100
Subject: [PATCH] python: fix get_property error when property doesn't exist
Indent the directive properly to attach it to Threads autoclass
documentation.
Fixes:
WARNING: don't know which module to import for autodocumenting
'__str__' (try placing a "module" or "currentmodule" directive in the
document, or giving an explicit module name)
The simplistic mocking in conf.py falls short on python 3.7. Just use
unittest.mock instead.
Fixes:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/config.py", line 368, in eval_config_file
execfile_(filename, namespace)
File "/usr/lib/python3/dist-packages/sphinx/util/pycompat.py", line 150, in execfile_
exec_(code, _globals)
File "/path/to/notmuch/bindings/python/docs/source/conf.py", line 39, in <module>
from notmuch import __VERSION__,__AUTHOR__
File "/path/to/notmuch/bindings/python/notmuch/__init__.py", line 54, in <module>
from .database import Database
File "/path/to/notmuch/bindings/python/notmuch/database.py", line 25, in <module>
from .globals import (
File "/path/to/notmuch/bindings/python/notmuch/globals.py", line 48, in <module>
class NotmuchDatabaseS(Structure):
TypeError: __mro_entries__ must return a tuple
When invoking gpg as a backgrounded tool, it's important to let gpg
know that it is backgrounded, to avoid spurious prompts or other
breakage.
In particular, https://bugs.debian.org/913614 was a regression in
GnuPG which causes problems when importing keys without a terminal,
but gpg expects one.
Ensuring that notmuch-emacs always invokes gpg as a background process
should avoid some of these unnecessary failure.
Thanks to Justus Winter for finding this problem.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
