Re: [PATCH] emacs: Add missing type and group to defcustom variable

2019-04-23 Thread Daniel Kahn Gillmor
On Mon 2019-04-15 15:35:19 +0200, Örjan Ekeberg wrote:
> Added the type 'regexp and group 'notmuch-send as properties to the
> customizable variable notmuch-mua-attachment-regexp.

This is clearly a good patch, and better than
id:20190420195359.23399-1-...@fifthhorseman.net which i'd sent to try to
address the same issue (Örjan adds both group and type, and i only added
type).

Tomi also reviewed my patch and said it was ok, i'm assuming that the
result would be the same on this one.  I think it should be merged.

Thanks, Örjan!

   --dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: subsequent rebuilds of notmuch always re-build sphinx and ruby

2019-04-23 Thread Daniel Kahn Gillmor
On Tue 2019-04-23 22:09:23 -0300, David Bremner wrote:
> [dkg wrote:]
>> I do note that (independent of this series), if i run the following
>> loop:
>>
>>
>>  while make -j4 --trace; do
>> python3 -c 'print("="*100)'
>> touch doc/man1/notmuch-reply.rst
>>  done
>>
>> then only every second run of make contains this info:
>
> I think I see this also, but no idea yet what is going on.

I've tagged the previous mail with notmuch::bug so that we can keep
track of it, but i don't think it's a high priority.

thanks for having looked into it!

   --dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: subsequent rebuilds of notmuch always re-build sphinx and ruby

2019-04-23 Thread David Bremner
Daniel Kahn Gillmor  writes:

> On Mon 2019-04-22 21:03:05 -0300, David Bremner wrote:
>> There was a problem with the first patch, which I replaced with two more.
>
> thanks.  i've reviewed and published my review on that series.  I think
> it should probably be merged.
>
>> I'm open to ideas, but keep in mind we want to support parallel make,
>> which means we have to be careful not to trigger multiple invocations of
>> sphinx-build in parallel.

> hm, i'm not entirely sure why sphinx-build can't be run in parallel, if
> it could target the creation of specific files (but maybe it can't).

It can target specific files according to the documentation, but the
main issue is that it caches a bunch of state under
doc/_build/doctrees. It doesn't do any kind of locking, so multiple
writers leads to build failures.

>
> I do note that (independent of this series), if i run the following
> loop:
>
>
>  while make -j4 --trace; do
> python3 -c 'print("="*100)'
> touch doc/man1/notmuch-reply.rst
>  done
>
> then only every second run of make contains this info:
>

I think I see this also, but no idea yet what is going on.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: subsequent rebuilds of notmuch always re-build sphinx and ruby

2019-04-23 Thread Daniel Kahn Gillmor
On Mon 2019-04-22 21:03:05 -0300, David Bremner wrote:
> There was a problem with the first patch, which I replaced with two more.

thanks.  i've reviewed and published my review on that series.  I think
it should probably be merged.

> I'm open to ideas, but keep in mind we want to support parallel make,
> which means we have to be careful not to trigger multiple invocations of
> sphinx-build in parallel.

hm, i'm not entirely sure why sphinx-build can't be run in parallel, if
it could target the creation of specific files (but maybe it can't).

I do note that (independent of this series), if i run the following
loop:


 while make -j4 --trace; do
python3 -c 'print("="*100)'
touch doc/man1/notmuch-reply.rst
 done

then only every second run of make contains this info:


doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-reply.1.gz' 
due to: doc/_build/man/man1/notmuch-reply.1
rm -f doc/_build/man/man1/notmuch-reply.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-reply.1 > doc/_build/man/man1/notmuch-reply.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-reindex.1.gz' 
due to: doc/_build/man/man1/notmuch-reindex.1
rm -f doc/_build/man/man1/notmuch-reindex.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-reindex.1 > doc/_build/man/man1/notmuch-reindex.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-restore.1.gz' 
due to: doc/_build/man/man1/notmuch-restore.1
rm -f doc/_build/man/man1/notmuch-restore.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-restore.1 > doc/_build/man/man1/notmuch-restore.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-new.1.gz' due 
to: doc/_build/man/man1/notmuch-new.1
rm -f doc/_build/man/man1/notmuch-new.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-new.1 > doc/_build/man/man1/notmuch-new.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-dump.1.gz' 
due to: doc/_build/man/man1/notmuch-dump.1
rm -f doc/_build/man/man1/notmuch-dump.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-dump.1 > doc/_build/man/man1/notmuch-dump.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-address.1.gz' 
due to: doc/_build/man/man1/notmuch-address.1
rm -f doc/_build/man/man1/notmuch-address.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-address.1 > doc/_build/man/man1/notmuch-address.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-tag.1.gz' due 
to: doc/_build/man/man1/notmuch-tag.1
rm -f doc/_build/man/man1/notmuch-tag.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-tag.1 > doc/_build/man/man1/notmuch-tag.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-count.1.gz' 
due to: doc/_build/man/man1/notmuch-count.1
rm -f doc/_build/man/man1/notmuch-count.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-count.1 > doc/_build/man/man1/notmuch-count.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-search.1.gz' 
due to: doc/_build/man/man1/notmuch-search.1
rm -f doc/_build/man/man1/notmuch-search.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-search.1 > doc/_build/man/man1/notmuch-search.1.gz
doc/Makefile.local:38: update target 
'doc/_build/man/man1/notmuch-emacs-mua.1.gz' due to: 
doc/_build/man/man1/notmuch-emacs-mua.1
rm -f doc/_build/man/man1/notmuch-emacs-mua.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-emacs-mua.1 > 
doc/_build/man/man1/notmuch-emacs-mua.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-show.1.gz' 
due to: doc/_build/man/man1/notmuch-show.1
rm -f doc/_build/man/man1/notmuch-show.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-show.1 > doc/_build/man/man1/notmuch-show.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-insert.1.gz' 
due to: doc/_build/man/man1/notmuch-insert.1
rm -f doc/_build/man/man1/notmuch-insert.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-insert.1 > doc/_build/man/man1/notmuch-insert.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch.1.gz' due to: 
doc/_build/man/man1/notmuch.1
rm -f doc/_build/man/man1/notmuch.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch.1 > doc/_build/man/man1/notmuch.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-compact.1.gz' 
due to: doc/_build/man/man1/notmuch-compact.1
rm -f doc/_build/man/man1/notmuch-compact.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-compact.1 > doc/_build/man/man1/notmuch-compact.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man1/notmuch-config.1.gz' 
due to: doc/_build/man/man1/notmuch-config.1
rm -f doc/_build/man/man1/notmuch-config.1.gz && gzip --stdout 
doc/_build/man/man1/notmuch-config.1 > doc/_build/man/man1/notmuch-config.1.gz
doc/Makefile.local:38: update target 'doc/_build/man/man5/notmuch-hooks.5.gz' 
due to: doc/_build/man/man5/notmuch-hooks.5
rm -f doc/_build/man/man5/notmuch-hooks.5.gz && gzip --stdout 
doc/_build/man/man5/notmuch-hooks.5 > 

Re: [PATCH 3/4] doc: use stamp file for html docs

2019-04-23 Thread Daniel Kahn Gillmor
On Sun 2019-04-21 14:12:44 -0300, David Bremner wrote:
> These are less time consuming than the texi docs to rebuild (because
> the texi rebuild triggers info rebuild), but still take noticable time.
> ---
>  doc/Makefile.local | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/doc/Makefile.local b/doc/Makefile.local
> index 2a701646..a8fee537 100644
> --- a/doc/Makefile.local
> +++ b/doc/Makefile.local
> @@ -50,10 +50,13 @@ sphinx-html: | $(DOCBUILDDIR)/.roff.stamp
>  sphinx-texinfo: | sphinx-html
>  sphinx-info: | sphinx-texinfo
>  
> -sphinx-html:
> +sphinx-html: $(DOCBUILDDIR)/.html.stamp
> +
> +$(DOCBUILDDIR)/.html.stamp: $(ALL_RST_FILES)
>   $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(DOCBUILDDIR)/html
> + touch $@
>  
> -sphinx-texinfo: .texi.stamp
> +sphinx-texinfo: $(DOCBUILDDIR)/.texi.stamp

I think this final change (to the sphinx-texinfo target) belongs in the
previous patchset.

Otherwise, this series looks good to me, using your followup two-part
replacement for the obsolete 1/4 patch.

I've tested it, and it reduces the amount of time for the subsequent run
of "make" quite a bit.

After a "./configure && make clean && make", subsequent repeated "make
--trace" runs look like this:

0 dkg@alice:~/src/notmuch/notmuch$ make --trace
emacs/Makefile.local:76: update target 'emacs/.eldeps.x' due to: emacs/.eldeps
cmp -s emacs/.eldeps emacs/.eldeps.x || cp emacs/.eldeps emacs/.eldeps.x
doc/Makefile.local:66: update target 'sphinx-info' due to: sphinx-texinfo
make -C doc/_build/texinfo info
make[1]: Entering directory '/home/dkg/src/notmuch/notmuch/doc/_build/texinfo'
make[1]: Nothing to be done for 'info'.
make[1]: Leaving directory '/home/dkg/src/notmuch/notmuch/doc/_build/texinfo'
bindings/Makefile.local:8: update target 'ruby-bindings' due to: 
lib/libnotmuch.so
cd bindings/ruby && \
EXTRA_LDFLAGS="-Wl,--no-undefined" \
LIBNOTMUCH="../../lib/libnotmuch.so" \
NOTMUCH_SRCDIR='/home/dkg/src/notmuch/notmuch' \
ruby extconf.rb --vendor
creating Makefile
make -C bindings/ruby
make[1]: Entering directory '/home/dkg/src/notmuch/notmuch/bindings/ruby'
Makefile:258: update target 'notmuch.so' due to: Makefile
echo linking shared-object notmuch.so
linking shared-object notmuch.so
rm -f notmuch.so
gcc -shared -o notmuch.so database.o directory.o filenames.o init.o message.o 
messages.o query.o status.o tags.o thread.o threads.o -L. 
-L/usr/lib/x86_64-linux-gnu -L. -Wl,-z,relro -Wl,-z,now -fstack-protector 
-rdynamic -Wl,-export-dynamic -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now 
-Wl,--compress-debug-sections=zlib   ../../lib/libnotmuch.so -lruby-2.5  
-lpthread -lgmp -ldl -lcrypt -lm   -lc
make[1]: Leaving directory '/home/dkg/src/notmuch/notmuch/bindings/ruby'
0 dkg@alice:~/src/notmuch/notmuch$ 

so there's still a bit of strange .eldeps and sphinx-*info business, but
they take basically no time.  And of course the ruby bindings haven't
been dealt with yet.

This seems like a clear improvement on the status quo, so i think we
should merge it and whittle down the remaining issues where we can.

 --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 3/3] emacs: Drop content-free "Unknown signature status" button

2019-04-23 Thread Daniel Kahn Gillmor
On Mon 2019-04-22 13:26:05 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2019-04-22 13:18:14 -0400, Daniel Kahn Gillmor wrote:
>> When we have not been able to evaluate the signature status of a given
>> MIME part, showing a content-free (and interaction-free) "[ Unknown
>> signature status ]" button doesn't really help the user at all, and
>> takes up valuable screen real-estate.
>>
>> A visual reminder that a given message is *not* signed isn't helpful
>> unless it is always present, in which case we'd want to see "[ Unknown
>> signature status ]" buttons on all messages, even ones that don't have
>> a signing structure, but i don't think we want that.
>
> This is a small step down the path of making notmuch-emacs friendlier
> with regards to encrypted messages, but it's one that will have an
> effect on future patch series that work with encrypted messages.  I'd be
> happy to hear any concerns people have about this change, but i find
> notmuch-emacs is more pleasant to use this way.

I've heard from some people that they don't like this final patch
because the "[ Unknown signature status ]" button is at least an
indication that the message appears to be signed (even if we decided not
to -- or were unable to -- evaluate the signature).

I considered argument this when writing the patch initially, and i don't
think it's a good argument for two reasons:

 a) without actual signature verification, the user experience is
trivially scammable by an adversary who knows how to craft a MIME
message, and it's basically encouraging a user pattern that is
something along the lines of:

  https://xkcd.com/1181/

(though maybe a bit more subtle, based on MIME structure instead of
the inline-signing that xkcd is mocking)

This is a particularly bad security indicator and user experience.
The thing isn't reliable, and it's not actionable in most cases.

 b) In the current state of the codebase, the presence of the button
does *not* indicate that a signature-like thing is even present.  If
you look at
test/emacs-show.expected-output/notmuch-show-decrypted-message, that
shows the cleartext view of a decrypted message which *does not*
have an OpenPGP signature on it at all
(test/corpora/crypto/basic-encrypted.eml is encrypted but unsigned).


I could imagine changing notmuch to fix concern (b) -- that is, hiding
the button just in the case where no signature-looking thing is present
at all.  But i haven't seen anyone even identify that problem publicly
yet, let alone offer a fix for it.

But i think that (a) is at least as big of a concern as (b); the fix i'm
proposing in this series is actually simpler than such a targeted fix
would be; and the fix in this series actually solves both problems.

If someone wants to offer a fix just for (b) on top of the first two
patches in this series, i'd happily advocate for it as better than the
status quo, which would let us put off (a) to a more interesting and
targeted discussion.

--dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch