Re: Notmuch, Emacs and pinentry -- oh my
On Mon 2019-11-11 20:10:26 +0100, Ralph Seichter wrote: > I tried that by setting GPG_TTY to a fixed terminal, but while this > seemed to work on the first call, the second time I was prompted for a > password it was echoed, in cleartext, to the terminal. Is there a better > method to achieve what you proposed? I don't fully understand the parameters of what you just posted here, but my understanding is that Werner Koch (GnuPG upstream) expects pinentry-tty or pinentry-curses to work in this dedicated terminal mode. If you can post a full and clear description of what you did and how it did not work as expected to https://dev.gnupg.org/ as a bug report, and point me to it, i am happy to try to make sure that report gets some kind of reasonable resolution from upstream (even though i probably don't have time to solve it myself). Let me know if you can't get an account working to report a bug on that system, i can probably grease the skids there too. >> To be clear about your threat model here: [...] > > Barring break-ins, nobody but me is logging in on that particular > server, so intercepting gpg-agent would be difficult. Access to the > Notmuch index would not be any easier, unless somebody physically > removed the hard drives. > > The lock/unlock operations to seems interesting, and, if it was based on > strong encryption, I would feel more comfortable. Are you thinking of > protecting just the index or the whole Maildir store? The latter would > not work for me, because Dovecot needs to access the data, and if only > the index is protected, I'd still need to decrypt messages within Emacs. This hypothetical subcommand would just protect the index. If the index is unlocked, and you're using: notmuch config set index.decrypt true Then you will be able to read your mail without access to your long-term secret key material because notmuch will stash a copy of the session key for each message in the index, and decryption can happen with that session key on its own. please read the index.decrypt section of notmuch-config(1) for more details. Regards, --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Segfault when tagging results of to: query
Hi, On Mon, Nov 11, 2019 at 8:54 PM Hugh Williams wrote: > > When trying to tag all messages to a particular address using the query > `notmuch tag +College to:exam...@example.com` I get a segfault. The > backtrace from gdb is shown below. > > ``` > #0 0x778deee4 in () at /usr/lib/libxapian.so.30 > #1 0x778e26fe in () at /usr/lib/libxapian.so.30 > #2 0x778e90a2 in () at /usr/lib/libxapian.so.30 > #3 0x778081f8 in Xapian::Enquire::Internal::get_mset(unsigned int, > unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) > const () at /usr/lib/libxapian.so.30 > #4 0x77808466 in Xapian::Enquire::get_mset(unsigned int, unsigned > int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () > at /usr/lib/libxapian.so.30 > #5 0x77fb69ca in () at /usr/lib/libnotmuch.so.5 > #6 0x5556bca2 in () > #7 0x5556c21a in () > #8 0xc12c in () > #9 0x779c9153 in __libc_start_main () at /usr/lib/libc.so.6 > #10 0xc2ee in () > ``` I see the same issue as well! I'm on Fedora 30, using the package available in the repos. 5.1.20-300.fc30.x86_64 notmuch-0.29.1-1.fc30.x86_64 Here's an example stack trace: Stack trace of thread 26982: #0 0x7f6a3f4c42b8 _ZNK14AndNotPostList10get_weightEv (libxapian.so.30) #1 0x7f6a3f4c7d06 _ZNK14SelectPostList10get_weightEv (libxapian.so.30) #2 0x7f6a3f4cf62a _ZN10MultiMatch8get_msetEjjjRN6Xapian4MSetERNS0_6Weight8InternalEPKNS0_12MatchDeciderEPKNS0_8KeyMakerE (libxapian.so.30) #3 0x7f6a3f3e50e6 _ZNK6Xapian7Enquire8Internal8get_msetEjjjPKNS_4RSetEPKNS_12MatchDeciderE (libxapian.so.30) #4 0x7f6a3f3e5359 _ZNK6Xapian7Enquire8get_msetEjjjPKNS_4RSetEPKNS_12MatchDeciderE (libxapian.so.30) #5 0x7f6a3f9a6da0 n/a (libnotmuch.so.5) #6 0x00419468 tag_query (notmuch) #7 0x004199d2 notmuch_tag_command (notmuch) #8 0x00409efb main (notmuch) #9 0x7f6a3f5b2f43 __libc_start_main (libc.so.6) #10 0x0040a0ae _start (notmuch) Query that triggered the segfault is: notmuch tag +fedora -- path:Gmail/** and to:lists.fedoraproject.org and is:new -- Suvayu Open source is the future. It sets us free. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Segfault when tagging results of to: query
When trying to tag all messages to a particular address using the query `notmuch tag +College to:exam...@example.com` I get a segfault. The backtrace from gdb is shown below. ``` #0 0x778deee4 in () at /usr/lib/libxapian.so.30 #1 0x778e26fe in () at /usr/lib/libxapian.so.30 #2 0x778e90a2 in () at /usr/lib/libxapian.so.30 #3 0x778081f8 in Xapian::Enquire::Internal::get_mset(unsigned int, unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () at /usr/lib/libxapian.so.30 #4 0x77808466 in Xapian::Enquire::get_mset(unsigned int, unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () at /usr/lib/libxapian.so.30 #5 0x77fb69ca in () at /usr/lib/libnotmuch.so.5 #6 0x5556bca2 in () #7 0x5556c21a in () #8 0xc12c in () #9 0x779c9153 in __libc_start_main () at /usr/lib/libc.so.6 #10 0xc2ee in () ``` Thanks, Hugh ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Notmuch, Emacs and pinentry -- oh my
* Daniel Kahn Gillmor: > Have you considered running gpg-agent in a dedicated terminal window, > and handling the gpg-agent prompts from that window? I tried that by setting GPG_TTY to a fixed terminal, but while this seemed to work on the first call, the second time I was prompted for a password it was echoed, in cleartext, to the terminal. Is there a better method to achieve what you proposed? > To be clear about your threat model here: [...] Barring break-ins, nobody but me is logging in on that particular server, so intercepting gpg-agent would be difficult. Access to the Notmuch index would not be any easier, unless somebody physically removed the hard drives. The lock/unlock operations to seems interesting, and, if it was based on strong encryption, I would feel more comfortable. Are you thinking of protecting just the index or the whole Maildir store? The latter would not work for me, because Dovecot needs to access the data, and if only the index is protected, I'd still need to decrypt messages within Emacs. Currently, decryption happens in whatever MUA I am using at that time, i.e. mostly Notmuch/Emacs and alternatively Thunderbird/Enigmail. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: can a notmuch query filter the output based on the size of a thread?
On Mon, Nov 11 2019, Daniel Kahn Gillmor wrote: > On Mon 2019-11-11 09:48:47 -0800, Jameson Graef Rollins wrote: >> I'm not sure I understand what the question is. They want to count >> messages, i.e. "notmuch count"? > > nope, i think they want: > >- show me all threads where: > - at least one message has the tag 'list/questions', and I have never personally had the need to search based on numbers of messages, but I have definitely thought that it would be good if searches worked over entire threads instead of just messages. I would much prefer if a search for "foo AND bar" would turn up a thread where "foo" was mentioned in one message in the thread and "bar" was mentioned in another. I think that would be very useful. > - at least two distinct messages are present > > does that make more sense? > > --dkg > ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: can a notmuch query filter the output based on the size of a thread?
On Mon 2019-11-11 09:48:47 -0800, Jameson Graef Rollins wrote: > On Mon, Nov 11 2019, Daniel Kahn Gillmor wrote: >> Over on https://github.com/pazz/alot/issues/1449, a user asks: >> >>> I would like to query for `mailcount`, for example >>> to search for mails on a mailing list which got answered >>> `:search tag:list/questions and mailcount>1` >>> or >>> `:search tag:list/questions and not mailcount:1` > > I'm not sure I understand what the question is. They want to count > messages, i.e. "notmuch count"? nope, i think they want: - show me all threads where: - at least one message has the tag 'list/questions', and - at least two distinct messages are present does that make more sense? --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: can a notmuch query filter the output based on the size of a thread?
On Mon, Nov 11 2019, Daniel Kahn Gillmor wrote: > Over on https://github.com/pazz/alot/issues/1449, a user asks: > >> I would like to query for `mailcount`, for example >> to search for mails on a mailing list which got answered >> `:search tag:list/questions and mailcount>1` >> or >> `:search tag:list/questions and not mailcount:1` > > This seems like a question for notmuch (and maybe for xapian). I don't > know how to do it off the top of my head. Any takers? I'm not sure I understand what the question is. They want to count messages, i.e. "notmuch count"? ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Notmuch, Emacs and pinentry -- oh my
On Fri 2019-11-08 16:40:05 +0100, Ralph Seichter wrote: > I only access the server with a terminal, and that's where Emacs is > running in. Curses is as graphical as it gets. ;-) Neither pinentry-tty nor pinentry-curses is designed to work (or capable of working well) with another process actively sharing the tty to which it's connected. That means that having either such interaction in the same terminal while you're running emacs is probably not going to end well :/ Have you considered running gpg-agent in a dedicated terminal window, and handling the gpg-agent prompts from that window? That would provide a clean separation between password entry (and other forms of interaction with the gpg-agent) and interaction with your message store. My understanding is that this is the recommended way of using gpg-agent when (a) you have a passphrase-locked secret key, and (b) no graphical environment is available. > As for the nuclear option of decoding on indexing: That worries me more > than using Emacs with some form of pinentry and gpg-agent. To be clear about your threat model here: an active attacker with access to your account on the server can relatively easily get a copy of your secret key in unprotected form. What they do is intercept your gpg-agent process, and then next time you enter your password, they use it to decrypt and exfiltrate your secret key. So the difference between that situation and a situation where you have indexed the cleartext is that the same attacker can just raid the cleartext index directly (e.g. from backups, or from the physical disk if it's seized), without having to wait to actively intercept your password. That's a significant difference, but not a huge one. If your index was protected (e.g. via an encrypted filesystem), perhaps you'd feel differently about that tradeoff? In my queue of things to work on, i've got "notmuch lock" and "notmuch unlock", which should apply filesystem encryption protection to your notmuch index. Is that something you'd be interested in? note that if you adopt it, then you get a few additional nice features: * the ability to search the cleartext of your encrypted messages * the ability to destroy old/expired decryption-capable subkey secret material without losing access to the cleartext of encrypted messages that you want to retain. happy to talk more about those tradeoffs if you like. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
Johan Parin [2019-11-11T00:16:17+01] wrote:
> My real frustration lies in the thread view. Typically threads will be
> partially read and I want to read only unread messages.
> I'm trying instead to use the tree view, this seems to me the more
> natural way to view threads. So I immediately do `Z' whenever I enter
> a thread. I would like to have the option to enter tree view
> automatically for a thread from the search buffer. Is it possible?
It seems to me that using search term tag:unread will help you. Try this
in the *hello* buffer:
z tag:unread
You'll go directly to tree view and unread messages will show with
normal colours and read messages with grey colour. Commands "n" and "p"
will skip over read messages ("N" and "P" won't). You can configure
saved searches to start with tree view.
--
/// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
// https://keys.openpgp.org/search?q=tliko...@iki.fi
/ https://keybase.io/tlikonen https://github.com/tlikonen
signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
Hi Johan-- On Sun 2019-11-10 13:49:29 +0100, Johan Parin wrote: > Add a new flag --message-headers to notmuch show, in order to let the > user specify displayed headers using `notmuch-message-headers' in the > emacs mua. This is interesting work, thanks for proposing it. I haven't reviewed the C changes in detail, but i wanted to ask a couple of bigger-picture questions about where you see this going and how it fits into the broader ecosystem around notmuch: - What is the specific use case for this? For example, can you identify situations where different headers need to be emitted by different users? Even one motivating example would help others on this list understand why they might want to care :) - Do we need full configurability here? I'd generally prefer for notmuch to be simple, instead of offering lots of ways for things to be subtly different across installations. If there's an additional header that notmuch-show should be exporting in machine-readable mode, why not just export it unilaterally, and let the consumer of the headers filter out what they want to filter out? - If we do go ahead with the configurability approach, is there a rationale for requiring that the option should be a full list, rather than a differential approach? for example "--include-header=Foo" and "--suppress-header=Bar" would let the user stick as close to the defaults as possible. That way an upgrade to notmuch that does something nice to the default headers wouldn't necessarily get overridden by anyone in the habit of making these adjustments. - Again, if we're going with the configurability approach, should it just be a command line argument, or is this something that someone might want to set/retrieve with "notmuch config"? These are meant as constructive questions, not as a critique -- i'm hoping that we can make notmuch solve the problems you're trying to solve! All the best, --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
On Mon 2019-11-11 10:26:18 -0500, Daniel Kahn Gillmor wrote: > - What is the specific use case for this? For example, can you identify >situations where different headers need to be emitted by different >users? Even one motivating example would help others on this list >understand why they might want to care :) ah, sorry, i've just read id:20191109221358.4349-1-johan.pa...@gmail.com and its associated messages, so i can see that some of the questions i'm asking are already under discussion. I see that you just want user-agent and x-mailer for your own purposes. Maybe it would be worthwhile to propose that narrow, limited change as a simple patch, without configurability and see what it looks like? I would personally be more likely to advocate for merging a patch that meets the specific needs of a notmuch user, and increase the configurability surface of notmuch. If processing a couple of extra headers on a long thread is too expensive for some consumer, i'd suggest that is an optimization for the consumer to tackle. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
can a notmuch query filter the output based on the size of a thread?
Over on https://github.com/pazz/alot/issues/1449, a user asks: > I would like to query for `mailcount`, for example > to search for mails on a mailing list which got answered > `:search tag:list/questions and mailcount>1` > or > `:search tag:list/questions and not mailcount:1` This seems like a question for notmuch (and maybe for xapian). I don't know how to do it off the top of my head. Any takers? --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unread handling
On Monday, 2019-11-11 at 00:16:17 +01, Johan Parin wrote:
I'm probably doing something wrong but I find myself frustrated
with the handling of unread in the emacs-mua.
In notmuch-search I found the default bold face for unread of
notmuch-search-unread-face not enough to make them stand out so
I tried something like
(setq notmuch-search-line-faces
'(("unread" . '(:foreground "SkyeBlue"))
(setq notmuch-search-line-faces
'(("unread" :foreground "SkyeBlue")))
(And I don't have a “SkyeBlue”, just “SkyBlue”.)
which ought to work according to the doc, but did not
work. Fortunately however it works to define a new face with
defface and use that.
(setq notmuch-search-line-faces
'(("unread" . my/notmuch-unread-face)))
So that problem solved.
My real frustration lies in the thread view. Typically threads
will be partially read and I want to read only unread messages.
I find the show view confusing because I don't clearly see the
message boundaries. Also I always need to start with C-u M-RET
to get an overview of the thread. In this view the unread stand
out a bit due to the colorization of the unread tag, which is
typically visible. I still would like to be able to colorize the
entire line or the author here, for unread. Is it possible?
The single-line summary of the message is drawn using
notmuch-message-summary-face, which you can customise. This would
be the same for all messages in the thread, though (no distinction
for “unread”).
You could perhaps abuse notmuch-tag-formats to force unread
message header lines to stand out more.
I'm trying instead to use the tree view, this seems to me the
more natural way to view threads. So I immediately do `Z'
whenever I enter a thread. I would like to have the option to
enter tree view automatically for a thread from the search
buffer. Is it possible?
“Z” in search mode should take you directly to tree mode.
In tree view however, again I would like to colorize the unread
messages. Haven't found a way to do this and reading
notmuch-tree.el it seems it's not possible. Is there a way?
Since I like to keep my window to 80 chars the tag display is
outside the visible area and I find myself doing C-e to find the
unread tags. This is very inconvenient.
Also I would like to navigate to the next unread message, and
would prefer the `n' binding to do that instead of go to next
message. Haven't found a binding for that.
Finally when entering the tree view I would like the first
unread message to automatically be shown.
I'm not a tree mode user, so I'm not familiar with it.
I guess the above can be summarized as, I would like to have the
option to have a gnus-ish way of viewing threads.
Tree mode is the closest, I think.
Again, I'm probably doing something wrong and / or am missing
some possibilities here, it would be very interesting to hear
others work flow for thread reading.
notmuch doesn't generally obsess about the “unread” tag quite as
much as the “inbox” tag. Maybe you are used to orienting yourself
around “unread” (which is important in Gnus, I'd agree) and
thinking about how to look at “inbox” instead would help?
dme.
--
I was better off when I was on your side, and I was holding on.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
