Re: [PATCH 3/3] emacs: Drop content-free "Unknown signature status" button
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
Re: [PATCH 3/4] doc: use stamp file for html docs
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: subsequent rebuilds of notmuch always re-build sphinx and ruby
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 > doc/_bu
Re: subsequent rebuilds of notmuch always re-build sphinx and ruby
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
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: [PATCH] emacs: Add missing type and group to defcustom variable
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: [PATCH] emacs: hint that notmuch-mua-attachment-regexp is a regular expression
On Mon 2019-04-22 11:33:34 +0200, Örjan Ekeberg wrote: > This addresses the same issue, and therefore overlaps with the patch > I submitted a week ago. > (id:20190415133519.4532-1-ekeb...@kth.se) sorry, i'd missed your earlier patch! i agree that your patch is obviously better than mine, thanks for pointing it out again. I've marked my patch with notmuch::obsolete, and marked yours with notmuch::trivial and notmuch::patch, as i don't think it needs any more review, and should be merged. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
