Re: show a single message in a huge thread

2021-06-01 Thread Jameson Graef Rollins
On Tue, Jun 01 2021, David Bremner  wrote:
> Alan Schmitt  writes:
>
>> Hello,
>>
>> On 2021-05-28 16:16, Alan Schmitt  writes:
>>
>>> Thank you for the suggestion. Here is what I did:
>>> - run the search
>>> - execute notmuch-tree-from-search-current-query
>>> - hit RET on a message deep in the thread
>>> - I get this error
>>>
>>> Debugger entered--Lisp error: (error "Lisp nesting exceeds 
>>> ‘max-lisp-eval-depth’")
>>
>> Is this a bug of notmuch-emacs? Is there a way to display a single
>> message independently of its context?
>>
>
> I'm not sure what the best UI is, but here is a start:
>
> (defun notmuch-show-single-message (query)
>   (interactive "sQuery: ")
>   (message query)
>   (let ((notmuch-show-indent-messages-width 0)
> (notmuch-show-only-matching-messages t))
> (notmuch-show query)))

It used to be that if a search returned only a single message that
message would just be displayed directly, by passing the thread view.
I'm not sure when/why that changed.

jamie.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: show a single message in a huge thread

2021-05-28 Thread Jameson Graef Rollins
On Fri, May 28 2021, alan.schm...@polytechnique.org wrote:
> Hello,
>
> I want to see a message in a huge thread (too big for notmuch to
> display). To find it, I switch to unthreaded mode, I select the message
> (I hit RET), but then notmuch tries to show all the other messages as
> well (which makes it hang as the thread is too big, and one of the
> message results in an error "symbolp: Lisp nesting exceeds
> ‘max-lisp-eval-depth’", which prevents later messages from being
> displayed).
>
> I tried doing C-u RET, but I immediately get a similar error:
> "notmuch-show-insert-thread: Lisp nesting exceeds
> ‘max-lisp-eval-depth’".

I will concur that notmuch-emacs has very poor performance with really
long threads.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: emacs: How to tab-complete destination email addresses?

2020-09-24 Thread Jameson Graef Rollins
On Thu, Sep 24 2020, David Bremner  wrote:
> George Kadianakis  writes:
>
>> So I guess this ordering should happen internally in notmuch-address,
>> right? Perhaps as a new type of "--sort" option like "--most-frequent"
>> or "--best-fit".
>>
>> If this is the right way to do it, perhaps I'll take a stab at it over
>> the next days. If it's not the right way to do it, please let me know so
>> that I don't do useless things! :)
>
> there was some discussion about upstreaming some of the features of
> notmuch-addrlookup-c into notmuch-address [1]. I'm not sure what
> happened there, but maybe this helps.

I wasn't aware of notmuch-addrlookup-c as a separate tool, but I just
tried it and it looks like it could be promising.  If it has better
address sorting that definitely seems like something that would be good
to pull in upstream.

>> Hmm, I've never used this interface but if you are talking about the
>> "--output" switch I see that they can be combined. So like you can do:
>>
>>$ notmuch address --output sender --output recipients jameson 
>>
>> to combine both To: and From:.
>
> Maybe the elisp 'internal' front-end needs to be updated to (optionally) do 
> what
> Jamie asks.

So I don't think these are the right options to consider, but I'm not
sure.  If I'm searching for addresses associated with the user
"jameson", I think I *don't* want --output=recipients, since I imagine
that includes all the addresses that "jameson" has sent messages *to*,
which is definitely not what I would want included.  But maybe I'm not
understanding.  It seems like emacs must be creating a more nuanced set
of arguments somehow...

jamie.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: emacs: How to tab-complete destination email addresses?

2020-09-23 Thread Jameson Graef Rollins
On Wed, Sep 23 2020, George Kadianakis  wrote:
> One way forward is to switch from using notmuch-address to using
> something like bbdb and manually curate my database (since bbdb offers
> this capability).
>
> But I think the right way would be to somehow introduce a bunch of
> heuristics in notmuch/emacs so that the right email address is chosen
> for each person. For example, if I tab-complete "Alice", I would like
> notmuch to give me the email address that Alice has used herself most
> frequently the past few times she contacted me.
>
> Perhaps there is something that does what I want already?
> If that's the case, I'd love to be pointed to a good solution!

I find the convenience of not having to maintain an address book to be a
huge win with the use of notmuch-address, so I'm generally fine to
filter through the offered addresses to find the one that I generally
recognize to be the most viable.  That said, an obvious improvement (as
you suggest) would be to order addresses based on most recent+frequent
use, so that the most recently used one shows up first.

The problem I have, though, is that for some reason that I don't
understand the interface can use To: address, or From: addresses, but
not both.  This is by far the most annoying thing to me, since in both
scenarios there will end up being missing addresses that I need that I
then have to go search for manually.  If the interface could be
configured to return most From: and To: address that would be a big
improvement imho.

jamie.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

2020-04-29 Thread Jameson Graef Rollins
On Wed, Apr 29 2020, Ciprian Dorin Craciun  wrote:
> I think there are two complete different use-cases for the `notmuch` binary:
> * a simple CLI to query the database, in which case the current flags seem OK;
> * a "poor-mans" API to query the database, more bellow;
>
> (I know there already exists an `libnotmuch` API accessible in many
> programming languages.  However for prototyping, and even for safety
> and robustness, when performance isn't an issue, I find the tool-based
> approach much more resilient.)
>
> Now about the "API" use-case,  I assume that at the moment many users
> have already integrated `notmuch` as it is with the current flags and
> behaviour.  Thus I agree that changing any flags in backward
> incompatible way would make a lot of people unhappy, and will generate
> perhaps quite a bit of "customer support".  :)

This is a good point.  The CLI might be "poor", but important apps like
notmuch-emacs are using them, so we should be careful about changing the
interface.

> Regarding the `--boolean` vs `--no-boolean` it does solve the
> strictness problem, however it makes the life of script developers
> quite hard, as now he has a `case` or `if/then/else`.  Therefore I
> would say that `--flag=value` is the best option as it can be simply
> written as `--flag={FLAG:-true}` or in Python for example `"--flag=%s"
> % _flag`.

Also a good point.  I guess the --flag=value interface is a safer/easier
one to converge on.

> Thinking even further uppon this, perhaps an even simpler idea would
> be to provide a new command, like for example `notmuch api` that takes
> on `stdin` a JSON with a specific format and does its job.

This actually sounds like a pretty good idea...

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


Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

2020-04-29 Thread Jameson Graef Rollins
On Wed, Apr 29 2020, David Bremner  wrote:
> I guess I'm a bit leery of removing UI features that presumably at least
> some people rely on. It's pretty upsetting to have sofware break one's
> muscle memory.

I dare say there are few people that have muscle memory for the notmuch
command line (especially for notmuch show), and fewer that aren't
themselves developers...
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

2020-04-29 Thread Jameson Graef Rollins
On Tue, Apr 28 2020, Daniel Kahn Gillmor  wrote:
> One final way we could normalize everything and make it less
> idiosyncratic, with shorter, simpler man pages: deprecate and then drop
> the --booloption/--no-booloption mechanisms, requiring --booloption=true
> or --booloption=false instead.  Once they're dropped, allow whitespace
> between "--booloption true" and "--booloption false" just like every
> other type of option.

Or we could just use only --booloption/--no-booloption...

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


Re: proposing "notmuch purge"

2020-01-14 Thread Jameson Graef Rollins
On Tue, Jan 14 2020, Ryan Tate  wrote:
> Is there any other notmuch command that results in a change to the state
> of actual mail files, as opposed to the database?

If maildir.synchronize_flags is set true then maildir flags in message
file names will be synchronized with tags (see notmuch-config(1)).

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


Re: proposing "notmuch purge"

2020-01-14 Thread Jameson Graef Rollins
On Tue, Jan 14 2020, Daniel Kahn Gillmor  wrote:
>> I think that the "SEARCH-TERMS" part should be configurable, not
>> hard-coded. A user could have setting like
>> "search.purge_tags=deleted;spam" and that would lead to search terms
>> "tag:deleted OR tag:spam" in the purge operation.
>
> I want the user to be able to run "notmuch purge", with no arguments, to
> "Do What I Mean"™
>
> I also want the "purge" subcommand to have its own configuration
> space -- it's *not* a specialized form of "search".

Honestly I don't see the point of any user configuration here.  Seems
likely to only add confusion and possibly improperly deleted messages,
which would be very bad.

Just use the "deleted" tag only.  It's already being used in multiple
place to mean that the message should be deleted.

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


Re: [PATCH] debian: Override lintian suggestion to move elpa-notmuch to Section: lisp

2019-12-24 Thread Jameson Graef Rollins
On Mon, Dec 23 2019, Daniel Kahn Gillmor  wrote:
> Signed-off-by: Daniel Kahn Gillmor 

lgtm.

jamie.


>  debian/elpa-notmuch.lintian-overrides | 4 
>  1 file changed, 4 insertions(+)
>  create mode 100644 debian/elpa-notmuch.lintian-overrides
>
> diff --git a/debian/elpa-notmuch.lintian-overrides 
> b/debian/elpa-notmuch.lintian-overrides
> new file mode 100644
> index ..aa275eda
> --- /dev/null
> +++ b/debian/elpa-notmuch.lintian-overrides
> @@ -0,0 +1,4 @@
> +# elpa-notmuch is an elisp plugin for dealing with e-mail.  We can
> +# already tell from the package name that it is an elisp package, so
> +# it belongs in Section: mail, and lintian is being too strict here.
> +elpa-notmuch: wrong-section-according-to-package-name elpa-notmuch => lisp
> -- 
> 2.24.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Attach public key and encrypt by default

2019-12-17 Thread Jameson Graef Rollins
On Mon, Dec 16 2019, "Carolyn \"Lynn\" Knight-Serrano"  
wrote:
> I have two feature requests/questions for notmuch-emacs? One would it
> be possible to add or configure in support for automatically adding
> your gpg public key to messages? Second, could there be a feature that
> checks if there's a gpg key for the recipient of a message and if
> there is, turn on encryption by default? Thanks!

Hi, Carolyn.  Both of these features is basically exactly what autocrypt
aims to provide:

https://autocrypt.org/

I know that Daniel Gillmor (dkg) and others have been actively working
on building autocrypt support into notmuch and notmuch-emacs.  I too
really want autocrypt support in notmuch, and am wishing I had more time
to help integrate it.  Maybe we can convince dkg to report on where he
sees things right now and we can outline a development work plan to help
push development forward.

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


Re: moving the config into the database [was: Re: [PATCH] Display extra headers for emacs-mua - db config option]

2019-12-10 Thread Jameson Graef Rollins
On Sun, Dec 08 2019, Jorge P. de Morais Neto  wrote:
> Em [2019-12-08 dom 09:12:55-0800], Jameson Graef Rollins escreveu:
>
>> You can already use 'notmuch config list' to dump every configuration
>> item to stdout.  Would that be sufficient for personal synchronization
>> purposes.
>
> But then I would have to remember invoking
> ~notmuch config list > ~/notmuch-config~
> every time I changed Notmuch configuration.

Rather than remember, why not just have your synchronization script
retrieve the config at sync time using notmuch config/dump.  That way
you don't have to remember to do anything, and you can be agnostic about
how the configuration info is stored on disk.

Fwiw I support dkg's idea to store the config in the database itself.  I
think that's a clean simplification that makes a lot of sense.

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


Re: Handle PKCS#7 signedData (S/MIME single-part clearsigned)

2019-12-09 Thread Jameson Graef Rollins
On Mon, Dec 09 2019, William Casarin  wrote:
> Daniel Kahn Gillmor  writes:
>> Several of the patches should be simple to read and uncontroversial (I
>> hope!), and I welcome/encourage merging of those patches to reduce the
>> length of the remaining series.
>
> I did a quick skim and it looks ok, although I'm not super familiar with
> S/MIME. Any steps toward S/MIME support gets a Concept ACK from me!

+1 on this.  Anything that pushes better crypto support is always good.
I gave the series a casual once over and it looks good to me, but I
haven't done an in-depth code review.

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


Re: moving the config into the database [was: Re: [PATCH] Display extra headers for emacs-mua - db config option]

2019-12-08 Thread Jameson Graef Rollins
On Sun, Dec 08 2019, Jorge P. de Morais Neto  wrote:
> Em [2019-11-22 sex 10:43:40+0800], Daniel Kahn Gillmor escreveu:
>
>> Better than documenting, i'd be happy if we would add a "notmuch config
>> edit" subcommand, which handles the above sequence for you, invoking
>> $EDITOR at the appropriate time.
>>
>> The only caveat i see there is if the end user wants to inject comments
>> in the config file, which would then be stripped out in between these
>> invocations.  perhaps someone who finds these comments in config files
>> super important could propose a way to stash them in the db and recover
>> them during "notmuch config edit" as well :)
>
> I sync my two Notmuch configuration files -- personal notebook and
> workplace desktop -- over Unison via a USB flash drive.  This way, when
> I want to reconfigure Notmuch in one machine, I have the other machine's
> configuration as reference.  However, I do not sync the entire Notmuch
> databases because, since they are big and change frequently, I suppose
> they would wear the USB flash drive and also increase the
> synchronization time.
>
> Thus for my use case it would be useful if "notmuch config edit" could
> automatically keep a perennial text file reflecting the configuration in
> the database.  That text file would then be synchronized by Unison.

You can already use 'notmuch config list' to dump every configuration
item to stdout.  Would that be sufficient for personal synchronization
purposes.

jamie.
___
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?

2019-11-11 Thread Jameson Graef Rollins
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?

2019-11-11 Thread Jameson Graef Rollins
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: v4 of repairing Mixed-up mangled MIME messages

2019-09-14 Thread Jameson Graef Rollins
On Sat, Sep 14 2019, Daniel Kahn Gillmor  wrote:
> On Sat 2019-09-14 00:29:40 -0700, Jameson Graef Rollins wrote:
>> Can we have notmuch auto-apply a tag, like the "encrypted" and "signed"
>> tags, that indicates mail has been mangled in this way?
>
> i don't believe tags are appropriate for this use -- the growing
> convention is to use properties for automated notes like this, and you
> can see from the series that this is the case:
>
> + notmuch_message_add_property (message, "index.repaired", "mixedup");
>
>> I'm feeling somewhat morally opposed to just silently fixing mail
>> that's been broken by bad/irresponsible actors on the net.  We need to
>> keep pushing on MS to fix this issue globally, so I for one would like
>> to be reminded if I'm still being affected by this.
>
> you should be able to do that with:
>
>  notmuch search property:index.repaired=mixedup
>
> does that satisfy your concerns?

Oh, so sorry, I should have read the patches more closely.  Yes, that
property definitely satisfies.  Thank you for your completeness in the
series, dkg.

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


Re: v4 of repairing Mixed-up mangled MIME messages

2019-09-14 Thread Jameson Graef Rollins
On Sat, Sep 14 2019, David Bremner  wrote:
> Jameson Graef Rollins  writes:
>
>> Can we have notmuch auto-apply a tag, like the "encrypted" and "signed"
>> tags, that indicates mail has been mangled in this way?  I'm feeling
>> somewhat morally opposed to just silently fixing mail that's been broken
>> by bad/irresponsible actors on the net.  We need to keep pushing on MS
>> to fix this issue globally, so I for one would like to be reminded if
>> I'm still being affected by this.
>
> It's side point, but it should rather be a property than a tag if we do
> something like that. In hindsight I think "auto tags" were probably a
> design mistake, since they are (easily) mutable by users.

Right, sorry, yes it should be a property.  I agree.

Any reason not to move "encrypted" and "signed" to be properties as
well?

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


Re: v4 of repairing Mixed-up mangled MIME messages

2019-09-14 Thread Jameson Graef Rollins
On Sun, Sep 08 2019, Daniel Kahn Gillmor  wrote:
> This is the fourth revision of the "Mixed up Mangling" series.
> Previous versions:
>
>  * v1 starts at id:20190528225452.17550-1-...@fifthhorseman.net
>  * v2 starts at id:20190530172707.10378-1-...@fifthhorseman.net
>  * v3 starts at id:20190531074842.16789-1-...@fifthhorseman.net
>
> This is a simple rebase of v3 on top of the current notmuch master
> branch.
>
> Comments welcome, as always!

Can we have notmuch auto-apply a tag, like the "encrypted" and "signed"
tags, that indicates mail has been mangled in this way?  I'm feeling
somewhat morally opposed to just silently fixing mail that's been broken
by bad/irresponsible actors on the net.  We need to keep pushing on MS
to fix this issue globally, so I for one would like to be reminded if
I'm still being affected by this.

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


Re: explain the json hierarchy format

2019-07-03 Thread Jameson Graef Rollins
On Wed, Jul 03 2019, meOme  wrote:
> Can anyone explain the resulting json format to me?
> I have a typical respone from
> notmuch show --format=json thread:x
> and i don't really understand the meaning of the hierarchy.

If you have a copy of the source [0] there's a file "devel/schemata"
that explains the structured output.

jamie.

[0] git://notmuchmail.org/git/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: new crypto customization variable to control stashing of encryption session keys

2018-06-19 Thread Jameson Graef Rollins
On Tue, Jun 19 2018, Daniel Kahn Gillmor  wrote:
> This is looking good to me, thanks!
>
> two more bits of nit-pickery below:
>
> On Tue 2018-06-19 08:20:12 -0700, Jameson Graef Rollins wrote:
>> +(defcustom notmuch-show-stash-session-keys nil
>> +  "Should session keys be stashed when decrypting messages for display?
>> +
>> +If this variable is non-nil session keys recovered while
>> +decrypting messages for display will be stored in the database.
>> +See description of --decrypt option in notmuch-show(1) for more
>> +information.
>
> do we want to include a warning here about the security of the index?
> setting this value to true not only stashes the session keys, but it
> also indexes the cleartext.  at the moment we're not directing people to
> the same kind of warnings ("Be aware that the index… DO NOT USE …
> without considering the security of your index.") that are present
> already in notmuch-reindex(1) and notmuch-new(1) and notmuch-insert(1).
> Perhaps notmuch-show(1) needs the same boilerplate warning, and we could
> replicate some short version of it here too?

I was wondering if it would make sense to have a separate man page for
describing all the intricacies of notmuch's crypto functionality,
i.e. notmuch-crypto(7).  There's going to be a lot of
redundancy/boilerplate in all the different man pages, and it seems like
it would be useful to put it all in one place and just reference it from
all the others.

This could also be a good place to describe how protected headers are
handled, and autocrypt once we finally get around to implementing it.

>> +NOTE: Stashing encryption session keys requires opening the
>> +notmuch database in read/write mode, which is not normally done
>
> i'd say "not otherwise done" instead of "not normally done", since we
> don't want to claim that people who use this feature aren't "normal" :)

But the claim wouldn't not be true!

I'll push another (five copies of a new) version.

jamie.


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


Re: [PATCH] emacs: new crypto customization variable to control stashing of encryption session keys

2018-06-19 Thread Jameson Graef Rollins
On Tue, Jun 19 2018, Jameson Graef Rollins  wrote:
> Introduce notmuch-show-store-session-keys customization variable to
> control stashing of session keys.  If non-nil any session keys
> recovered during decryption will be stored in the database.
>
> This is just a switch to have --decrypt= use "stash" instead of
> "true".
> ---
> Gah forgot to update the commit message.  Sorry.

Sorry, this is the one to use, since I messed up the commit message on
the first.  So sorry for all the screw ups.

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


[PATCH] emacs: new crypto customization variable to control stashing of encryption session keys

2018-06-19 Thread Jameson Graef Rollins
Introduce notmuch-show-store-session-keys customization variable to
control stashing of session keys.  If non-nil any session keys
recovered during decryption will be stored in the database.

This is just a switch to have --decrypt= use "stash" instead of
"true".
---
Gah forgot to update the commit message.  Sorry.

 emacs/notmuch-crypto.el | 15 +++
 emacs/notmuch-query.el  |  4 +++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
index fc2b5301..26ce19b4 100644
--- a/emacs/notmuch-crypto.el
+++ b/emacs/notmuch-crypto.el
@@ -43,6 +43,21 @@ mode."
   :package-version '(notmuch . "0.25")
   :group 'notmuch-crypto)
 
+(defcustom notmuch-show-stash-session-keys nil
+  "Should session keys be stashed when decrypting messages for display?
+
+If this variable is non-nil session keys recovered while
+decrypting messages for display will be stored in the database.
+See description of --decrypt option in notmuch-show(1) for more
+information.
+
+NOTE: Stashing encryption session keys requires opening the
+notmuch database in read/write mode, which is not normally done
+when retrieving messages for display."
+  :type 'boolean
+  :package-version '(notmuch . "0.28")
+  :group 'notmuch-crypto)
+
 (defface notmuch-crypto-part-header
   'class color)
   (background dark))
diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
index 563e4acf..e53c9489 100644
--- a/emacs/notmuch-query.el
+++ b/emacs/notmuch-query.el
@@ -32,7 +32,9 @@ is a possibly empty forest of replies.
 "
   (let ((args '("show" "--format=sexp" "--format-version=4")))
 (if notmuch-show-process-crypto
-   (setq args (append args '("--decrypt=true"
+(if notmuch-show-stash-session-keys
+(setq args (append args '("--decrypt=stash")))
+  (setq args (append args '("--decrypt=true")
 (setq args (append args search-terms))
 (apply #'notmuch-call-notmuch-sexp args)))
 
-- 
2.17.1

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


[PATCH] emacs: new crypto customization variable to control stashing of encryption session keys

2018-06-19 Thread Jameson Graef Rollins
Introduce notmuch-crypto-store-session-keys customization variable to
control stashing of session keys.  If non-nil any session keys
recovered during decryption will be stored in the database.

This is just a switch to have --decrypt= use "stash" instead of
"true".
---
 emacs/notmuch-crypto.el | 15 +++
 emacs/notmuch-query.el  |  4 +++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
index fc2b5301..26ce19b4 100644
--- a/emacs/notmuch-crypto.el
+++ b/emacs/notmuch-crypto.el
@@ -43,6 +43,21 @@ mode."
   :package-version '(notmuch . "0.25")
   :group 'notmuch-crypto)
 
+(defcustom notmuch-show-stash-session-keys nil
+  "Should session keys be stashed when decrypting messages for display?
+
+If this variable is non-nil session keys recovered while
+decrypting messages for display will be stored in the database.
+See description of --decrypt option in notmuch-show(1) for more
+information.
+
+NOTE: Stashing encryption session keys requires opening the
+notmuch database in read/write mode, which is not normally done
+when retrieving messages for display."
+  :type 'boolean
+  :package-version '(notmuch . "0.28")
+  :group 'notmuch-crypto)
+
 (defface notmuch-crypto-part-header
   'class color)
   (background dark))
diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
index 563e4acf..e53c9489 100644
--- a/emacs/notmuch-query.el
+++ b/emacs/notmuch-query.el
@@ -32,7 +32,9 @@ is a possibly empty forest of replies.
 "
   (let ((args '("show" "--format=sexp" "--format-version=4")))
 (if notmuch-show-process-crypto
-   (setq args (append args '("--decrypt=true"
+(if notmuch-show-stash-session-keys
+(setq args (append args '("--decrypt=stash")))
+  (setq args (append args '("--decrypt=true")
 (setq args (append args search-terms))
 (apply #'notmuch-call-notmuch-sexp args)))
 
-- 
2.17.1

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


Re: [PATCH] emacs: new crypto customization variable to control stashing of encryption session keys

2018-06-19 Thread Jameson Graef Rollins
On Tue, Jun 19 2018, David Bremner  wrote:
> I'm fine with whatever you and dkg decide for a name, but note that the
> customization group is independent from the name; you just choose
> whatever group you want in the defcustom.

Oh, I didn't realize that.  I thought they were linked.  In that case
I'll go with:

notmuch-show-store-session-keys


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


Re: [PATCH] emacs: new crypto customization variable to control stashing of encryption session keys

2018-06-18 Thread Jameson Graef Rollins
On Mon, Jun 18 2018, Daniel Kahn Gillmor  wrote:
> how about:
>
> notmuch-crypto-store-session-keys-on-show

Works for me.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: new crypto customization variable to control stashing of encryption session keys

2018-06-18 Thread Jameson Graef Rollins
On Mon, Jun 18 2018, Daniel Kahn Gillmor  wrote:
> This looks like it would work, but calling it
> notmuch-crypto-store-session-keys is a bit confusing, because based on
> the name it looks like it would apply to many places (e.g. during
> message sending, should a session key be stored when the outbound
> message is fcc'ed?), but based on the implementation it only matters
> during "show".
>
> Should its name be notmuch-show-store-session-keys instead?

I feel like it should be under the notmuch-crypto customization group,
not notmuch-show.  notmuch-crypto-show-store-session-keys ?

> also, i think the description of the variable setting should be clearer
> about its scope, and about the implications of setting it to non-nil
> (e.g. needing read/write access to the notmuch db to view all messages)

I will clarify the docs once we decide on variable name.

jamie.


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


[PATCH] emacs: new crypto customization variable to control stashing of encryption session keys

2018-06-17 Thread Jameson Graef Rollins
Introduce notmuch-crypto-store-session-keys customization variable to
control stashing of session keys.  If non-nil any session keys
recovered during decryption will be stored in the database.

This is just a switch to have --decrypt= use "stash" instead of
"true".
---
This seems like the simplest approach, to just add a new variable to
control session key stashing.  Much simpler that reworking the meaning
of notmuch-crypto-process-mime.

 emacs/notmuch-crypto.el | 10 ++
 emacs/notmuch-query.el  |  4 +++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
index fc2b5301..e1943f53 100644
--- a/emacs/notmuch-crypto.el
+++ b/emacs/notmuch-crypto.el
@@ -43,6 +43,16 @@ mode."
   :package-version '(notmuch . "0.25")
   :group 'notmuch-crypto)
 
+(defcustom notmuch-crypto-store-session-keys nil
+  "Should session keys from decrypted messages be stored in database?
+
+If this variable is non-nil session keys recovered from decrypted
+messages will be stored in the database.  See notmuch-show(1) for
+more information."
+  :type 'boolean
+  :package-version '(notmuch . "0.28")
+  :group 'notmuch-crypto)
+
 (defface notmuch-crypto-part-header
   'class color)
   (background dark))
diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
index 563e4acf..3e6bc8b1 100644
--- a/emacs/notmuch-query.el
+++ b/emacs/notmuch-query.el
@@ -32,7 +32,9 @@ is a possibly empty forest of replies.
 "
   (let ((args '("show" "--format=sexp" "--format-version=4")))
 (if notmuch-show-process-crypto
-   (setq args (append args '("--decrypt=true"
+(if notmuch-crypto-store-session-keys
+(setq args (append args '("--decrypt=stash")))
+  (setq args (append args '("--decrypt=true")
 (setq args (append args search-terms))
 (apply #'notmuch-call-notmuch-sexp args)))
 
-- 
2.17.1

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


Re: [PATCH] emacs: use new show --decrypt=stash feature in emacs UI

2018-06-13 Thread Jameson Graef Rollins
On Wed, Jun 13 2018, Daniel Kahn Gillmor  wrote:
> On Wed 2018-06-13 13:25:54 -0300, David Bremner wrote:
>> What about using symbols and some kind of case? less efficient but
>> better error checking
>
> symbols would also make for a more brittle interaction between future
> versions of the notmuch cli and notmuch-emacs, but i agree that the
> error checking would probably be worth it (it's not hard to update the
> list of symbols if a new option gets added to "show --decrypt".
>
> also, it looks like notmuch-mua-reply reasons about
> notmuch-show-process-crypto to create the --decrypt= arg for "notmuch
> reply".  "notmuch reply" doesn't have --decrypt=stash (and i don't think
> there's any sensible workflow that would warrant puting it there) so
> some reasoning needs to be done there.  symbols would make that a more
> sensible approach.

I'm not sure exactly what you mean by "symbols", but I'm working on
something that will turn notmuch-crypto-process-mime into a choice
custom with constant values.  A separate derived value will be used to
provide the correct bool to notmuch-show-process-crypto.

I'll provide another iteration that we can discuss.

jamie.


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


Re: [PATCH] emacs: use new show --decrypt=stash feature in emacs UI

2018-06-13 Thread Jameson Graef Rollins
On Tue, Jun 12 2018, Daniel Kahn Gillmor  wrote:
> On Tue 2018-06-12 10:00:18 -0400, Daniel Kahn Gillmor wrote:
>> (it'd be nice to be able to use notmuch-emacs to browse a notmuch
>> archive without locking the notmuch db or even needing read/write access
>> to the database)
>
> to be clear, it's not just about wanting to be able to avoid write
> access during "notmuch show" -- there are other use cases i'd like us to
> be able to support, including the ability to keep some messages'
> cleartext indexed, while leaving some of them un-indexed (keeping their
> contents secret from anyone who doesn't have the user's secret keys).
>
> This proposed change removes that possibility, so i think it needs more
> nuance.

This patch works for all the use cases I personally care about, so I
would like a configuration that is this simple.

The use case you're arguing for, which I believe is the ability to
choose on a per-message basis whether you want to stash or not, would
have to not use the show stash functionality at all.

What if notmuch-crypto-process-mime just accepted the same values that
show --decrypt does, with the same meanings, e.g.:

┌─┬───┬──┬──┬───┐
│ │ false │ auto │ true │ stash │
├─┼───┼──┼──┼───┤
│Show  cleartext  if  session  key is │   │ X│ X│ X │
│already known│   │  │  │   │
├─┼───┼──┼──┼───┤
│Use secret keys to show cleartext│   │  │ X│ X │
├─┼───┼──┼──┼───┤
│Stash any  newly  recovered  session │   │  │  │ X │
│keys, reindexing message if found│   │  │  │   │
└─┴───┴──┴──┴───┘

notmuch-crypto-process-mime is really only relevant for show anyway, so
I think this makes sense.

Users who want to chose to stash on a per-message basis would then need
to set notmuch-crypto-process-mime=true, and then do reindex
--decrypt=true if they want to stash.

jamie.


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


[PATCH] minor cleanup to printmimestructure

2018-06-11 Thread Jameson Graef Rollins
make the source slightly easier to read.  no functional change.
---
 devel/printmimestructure | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/devel/printmimestructure b/devel/printmimestructure
index afa0590e..ab2a6673 100755
--- a/devel/printmimestructure
+++ b/devel/printmimestructure
@@ -24,7 +24,7 @@ from __future__ import print_function
 import email
 import sys
 
-def test(z, prefix=''):
+def print_part(z, prefix):
 fname = '' if z.get_filename() is None else ' [' + z.get_filename() + ']'
 cset = '' if z.get_charset() is None else ' (' + z.get_charset() + ')'
 disp = z.get_params(None, header='Content-Disposition')
@@ -35,8 +35,23 @@ def test(z, prefix=''):
 for d in disp:
 if d[0] in [ 'attachment', 'inline' ]:
 disposition = ' ' + d[0]
+if z.is_multipart():
+nbytes = len(z.as_string())
+else:
+nbytes = len(z.get_payload())
+
+print('{}{}{}{}{} {:d} bytes'.format(
+prefix,
+z.get_content_type(),
+cset,
+disposition,
+fname,
+nbytes,
+))
+
+def test(z, prefix=''):
 if (z.is_multipart()):
-print(prefix + '┬╴' + z.get_content_type() + cset + disposition + 
fname, z.as_string().__len__().__str__() + ' bytes')
+print_part(z, prefix+'┬╴')
 if prefix.endswith('└'):
 prefix = prefix.rpartition('└')[0] + ' '
 if prefix.endswith('├'):
@@ -49,6 +64,6 @@ def test(z, prefix=''):
 test(parts[i], prefix + '└')
 # FIXME: show epilogue?
 else:
-print(prefix + '─╴'+ z.get_content_type() + cset + disposition + 
fname, z.get_payload().__len__().__str__(), 'bytes')
+print_part(z, prefix+'─╴')
 
 test(email.message_from_file(sys.stdin), '└')
-- 
2.17.1

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


Re: [PATCH] emacs: use new show --decrypt=stash feature in emacs UI

2018-06-11 Thread Jameson Graef Rollins
Jeez I don't know how I manged to send three copies of this to the list.
Apologies for the spam.  At least only one of them needs to be reviewed!

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


[PATCH] emacs: use new show --decrypt=stash feature in emacs UI

2018-06-11 Thread Jameson Graef Rollins
This just changes the show --decrypt flag to "stash" in the emacs UI,
so that session keys will be stashed in the database when viewing
encrypted messages that have not previously been decrypted.  As
always, this will only happen if the notmuch-crypto-process-mime
customization variable is set to "true".
---
 emacs/notmuch-lib.el   | 2 +-
 emacs/notmuch-query.el | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index a7e02710..94ddef52 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -593,7 +593,7 @@ the given type."
   (set-buffer-multibyte nil))
 (let ((args `("show" "--format=raw"
   ,(format "--part=%s" (plist-get part :id))
-  ,@(when process-crypto '("--decrypt=true"))
+  ,@(when process-crypto '("--decrypt=stash"))
   ,(notmuch-id-to-query (plist-get msg :id
   (coding-system-for-read
(if binaryp 'no-conversion
diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
index 563e4acf..8c38eb02 100644
--- a/emacs/notmuch-query.el
+++ b/emacs/notmuch-query.el
@@ -32,7 +32,7 @@ is a possibly empty forest of replies.
 "
   (let ((args '("show" "--format=sexp" "--format-version=4")))
 (if notmuch-show-process-crypto
-   (setq args (append args '("--decrypt=true"
+(setq args (append args '("--decrypt=stash"
 (setq args (append args search-terms))
 (apply #'notmuch-call-notmuch-sexp args)))
 
-- 
2.17.1

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


[PATCH] emacs: use new show --decrypt=stash feature in emacs UI

2018-06-11 Thread Jameson Graef Rollins
This just changes the show --decrypt flag to "stash" in the emacs UI,
so that session keys will be stashed in the database when viewing
encrypted messages that have not previously been decrypted.  As
always, this will only happen if the notmuch-crypto-process-mime
customization variable is set to "true".
---
 emacs/notmuch-lib.el   | 2 +-
 emacs/notmuch-query.el | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index a7e02710..94ddef52 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -593,7 +593,7 @@ the given type."
   (set-buffer-multibyte nil))
 (let ((args `("show" "--format=raw"
   ,(format "--part=%s" (plist-get part :id))
-  ,@(when process-crypto '("--decrypt=true"))
+  ,@(when process-crypto '("--decrypt=stash"))
   ,(notmuch-id-to-query (plist-get msg :id
   (coding-system-for-read
(if binaryp 'no-conversion
diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
index 563e4acf..8c38eb02 100644
--- a/emacs/notmuch-query.el
+++ b/emacs/notmuch-query.el
@@ -32,7 +32,7 @@ is a possibly empty forest of replies.
 "
   (let ((args '("show" "--format=sexp" "--format-version=4")))
 (if notmuch-show-process-crypto
-   (setq args (append args '("--decrypt=true"
+(setq args (append args '("--decrypt=stash"
 (setq args (append args search-terms))
 (apply #'notmuch-call-notmuch-sexp args)))
 
-- 
2.17.1

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


Re: Protected headers in notmuch

2018-06-03 Thread Jameson Graef Rollins
On Sat, Jun 02 2018, Jameson Graef Rollins  wrote:
> I've pushed a branch of this series rebased against notmuch/release (for
> some reason master is currently a couple commits behind) and fixed to
> reflect the exposure of notmuch_message_get_database:
>
> https://gitlab.com/jrollins/notmuch/commits/protected-headers-fix
>
> All tests pass.  Note it requires gmime 3.0 (which tripped me up for a
> bit since notmuch still implicitly supports older gmime versions).
>
> I haven't done a commit-by-commit review yet, but I am now using this
> series and it works as advertised: messages with encrypted subjects are
> searchable by the encrypted subject, and the encrypted subjects show up
> correctly in all the clients I'm using (both CLI and emacs).
>
> I strongly support the inclusion of this feature, particularly since
> it's an important component of autocrypt, which I want even more.

I've now done a commit-by-commit review and I think this is a very clean
patch series, with very good test suite coverage.  To the extent that I
have much to say on any of the code structure (not much) it all looks
good to me.

In particular I really like the introduction of the new "cryptographic
envelope" concept, and the new whole-message crypto status object that
goes with it.  I think this is a very solid idea that will be very
useful for clients going forward.  The implementation details seem solid
and well thought out to me, seeming to include all the useful info that
a client would need.

As for the protected headers, I like that they're just swapped in
seamlessly.  It also seems useful that the crypto envelope status
includes information about which headers were signed, and which headers
were masked by those that were encrypted.  It seems that there's just
enough information emitted about the overall crypto status and the
protected headers for any clients to be able to construct a useful UX
for users, but without any cruft that could potentially be confusing.

jamie.


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


Re: Protected headers in notmuch

2018-06-02 Thread Jameson Graef Rollins
I've pushed a branch of this series rebased against notmuch/release (for
some reason master is currently a couple commits behind) and fixed to
reflect the exposure of notmuch_message_get_database:

https://gitlab.com/jrollins/notmuch/commits/protected-headers-fix

All tests pass.  Note it requires gmime 3.0 (which tripped me up for a
bit since notmuch still implicitly supports older gmime versions).

I haven't done a commit-by-commit review yet, but I am now using this
series and it works as advertised: messages with encrypted subjects are
searchable by the encrypted subject, and the encrypted subjects show up
correctly in all the clients I'm using (both CLI and emacs).

I strongly support the inclusion of this feature, particularly since
it's an important component of autocrypt, which I want even more.

jamie.


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


Re: [PATCH 18/20] indexing: record protected subject when indexing cleartext

2018-06-02 Thread Jameson Graef Rollins
On Fri, May 11 2018, Daniel Kahn Gillmor  wrote:
> When indexing the cleartext of an encrypted message, record any
> protected subject in the database, which should make it findable and
> visible in search.
> ---
>  lib/index.cc   | 42 ++
...
> diff --git a/lib/index.cc b/lib/index.cc
> index 0ad683fa..db16b6f8 100644
> --- a/lib/index.cc
> +++ b/lib/index.cc
...
> @@ -430,8 +435,13 @@ _index_mime_part (notmuch_message_t *message,
>   }
>   continue;
>   }
> - _index_mime_part (message, indexopts,
> -   g_mime_multipart_get_part (multipart, i));
> + child = g_mime_multipart_get_part (multipart, i);
> + status = _notmuch_message_crypto_potential_payload (msg_crypto, 
> child, part, i);
> + if (status)
> + _notmuch_database_log (_notmuch_message_database (message),
> +"Warning: failed to mark the potential 
> cryptographic payload (%s).\n",
> +notmuch_status_to_string (status));
> + _index_mime_part (message, indexopts, child, msg_crypto);
>   }
>   return;
>  }

In 9088db76d89264b733f6b45e776d8952da237921 _notmuch_message_database
was exposed as notmuch_message_get_database, so this patch needs to be
updated:

diff --git a/lib/index.cc b/lib/index.cc
index 74e1ba43..18e712b1 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -438,7 +438,7 @@ _index_mime_part (notmuch_message_t *message,
child = g_mime_multipart_get_part (multipart, i);
status = _notmuch_message_crypto_potential_payload (msg_crypto, 
child, part, i);
if (status)
-   _notmuch_database_log (_notmuch_message_database (message),
+   _notmuch_database_log (notmuch_message_get_database (message),
   "Warning: failed to mark the potential 
cryptographic payload (%s).\n",
   notmuch_status_to_string (status));
_index_mime_part (message, indexopts, child, msg_crypto);

This fix doesn't affect any of the subsequent patches in this series.

jamie.


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


Re: [PATCH] cli: add support for only printing the addresses in notmuch address

2017-12-20 Thread Jameson Graef Rollins
On Wed, Dec 20 2017, Jani Nikula  wrote:
> Matter of taste. I like the self-documenting aspect of *what* these
> options control. --output=body is obvious, --body is less
> so. --include-html includes html somewhere, I think --output=html would
> be better.
>
> In the spirit of worse is better, I'll note that using --output= stores
> all the possible values in a single bit mask, and it's easy to define
> the defaults for *all* possible outputs in one variable, and it's easy
> to check *all* possible combinations with bit masks. Not so with
> independent parameters. Again, matter of taste how much you appreciate
> implementation simplicity. With notmuch show, I think that guideline
> would have made the interface better too. YMMV.
>
> As to notmuch address --output=address, it fulfills all the feature
> needs that popped up in this thread. If there's a strong desired to
> change the interface, we'll need patches as this one's already merged.

I'm less interested in specific argument formatting than I am in
consistency across the interface.  I just don't like how --output= now
has quite different semantics between the different sub commands.  That
seems like the wrong direction to me.

jamie.


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


Re: [PATCH] cli: add support for only printing the addresses in notmuch address

2017-12-19 Thread Jameson Graef Rollins
On Wed, Dec 20 2017, Jani Nikula  wrote:
> ~$ notmuch address --output=sender --output=recipients --output=address 
> --output=count id:878tdy8a2q@ligo.caltech.edu
> 1 notmuch@notmuchmail.org
> 1 jroll...@finestructure.net
> 1 d...@fifthhorseman.net
> 1 j...@nikula.org
>
> I prefer this to separate options.

Really?  If each is just a switch then why not:

~$ notmuch address --sender --recipients --address --count 
id:878tdy8a2q@ligo.caltech.edu

?  It's just shorter, right?

Also, this behavior is quite different than for search, in which only
the last --output applies.

> notmuch search uses separate --entire-thread, --body, and --include-html
> options, and I think those are getting messy.

The seem less messy than a "--output=" prefixed version of the same.

jamie.


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


Re: [PATCH] cli: add support for only printing the addresses in notmuch address

2017-12-19 Thread Jameson Graef Rollins
On Tue, Dec 19 2017, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> On Tue 2017-12-19 13:23:55 -0800, Jameson Graef Rollins wrote:
>> On Thu, Nov 02 2017, Jani Nikula <j...@nikula.org> wrote:
>>> The notmuch address output is much more useful for scripts with just
>>> the addresses printed. Support this using the --output=address option.
>>
>> Isn't "address" kind of orthogonal to "sender" and "recipient"?  Isn't
>> this more like the --output/--format distinction in search?
>
> i think i agree with Jamie here -- it'd be nice to be able to ask for
> the addresses of the senders, or the addresses of the recipients.  how
> would that be done here?

Sorry, I see now that address already has the --format option with the
expected values.  So I think either address-only or sender/recipient
should be a separate option.

jamie.


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


Re: [PATCH] cli: add support for only printing the addresses in notmuch address

2017-12-19 Thread Jameson Graef Rollins
On Thu, Nov 02 2017, Jani Nikula  wrote:
> The notmuch address output is much more useful for scripts with just
> the addresses printed. Support this using the --output=address option.

Isn't "address" kind of orthogonal to "sender" and "recipient"?  Isn't
this more like the --output/--format distinction in search?

jamie.


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


Re: [PATCH v2 06/21] crypto: Test restore of cleartext index from stashed session keys

2017-12-07 Thread Jameson Graef Rollins
On Mon, Dec 04 2017, David Bremner  wrote:
> Pushed patches 1 to 6. I seem to recall 7 and 8 basically adressed
> concerns/suggestions Jamie had, so I'm hoping he can have a quick look
> at those.

Yes, this new series is great and definitely addresses all my concerns.
I'm stoked to see that the first part of it has been pushed, and looking
forward to the full series!

This is really great progress, Daniel.  Thanks for pushing on this.

jamie.


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


Re: [PATCH 07/18] crypto: new decryption policy "auto"

2017-11-12 Thread Jameson Graef Rollins
On Sun, Nov 12 2017, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> On Sat 2017-11-11 15:14:03 -0800, Jameson Graef Rollins wrote:
>> On Wed, Oct 25 2017, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
>>> diff --git a/util/crypto.h b/util/crypto.h
>>> index b23ca747..dc95b4ca 100644
>>> --- a/util/crypto.h
>>> +++ b/util/crypto.h
>>> @@ -16,7 +16,8 @@ typedef struct _notmuch_crypto {
>>>  } _notmuch_crypto_t;
>>>  
>>>  GMimeObject *
>>> -_notmuch_crypto_decrypt (notmuch_message_t *message,
>>> +_notmuch_crypto_decrypt (notmuch_decryption_policy_t decrypt,
>>> +notmuch_message_t *message,
>>>  GMimeCryptoContext* crypto_ctx,
>>>  GMimeMultipartEncrypted *part,
>>>  GMimeDecryptResult **decrypt_result,
>>
>> Why does _notmuch_crypt_decrypt need to have
>> "notmuch_decryption_policy_t decrypt" as an input argument?  Isn't
>> notmuch_decryption_policy_t already an attribute of the crypto_ctx?  Is
>> there some situation where the policy would differ from what's specified
>> in the crypto_ctx?
>
> crypto_ctx here is just a GMimeCryptoContext, which doesn't know
> anything about notmuch_decryption_policy_t.  Maybe i'm misunderstanding
> your question?
>
> I'd be happy to streamline the interface to this internal function, but
> given that it's not an exported API, i'm not as concerned about things
> like future cleanliness -- the notmuch source contains all invocations
> of the function anywhere, so if we find a nicer way to streamline it in
> the future, we can do that cleanup across the codebase in a single
> commit.

I guess I'm confusing how things were before, when the crypto_ctx was a
notmuch-defined thing that included the GMimeCryptoContext.

It seems like _notmuch_crypto_t could just hold the GMimeCryptoContext,
as it does for earlier versions of GMime, which would make things easier
to pass around.  But this discussion is tangent to this patch series.

jamie.


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


Re: Stashed session keys

2017-11-12 Thread Jameson Graef Rollins
On Sun, Nov 12 2017, Daniel Kahn Gillmor  wrote:
>> Finally, I think it would be worthwhile to resolve the disparity between
>> the usage of "decrypt" and "try-decrypt" in the CLI and config options.
>> I'm not sure why we're using different terms in different contexts, even
>> though the meanings are essentially the same.  A follow-up patch series
>> changing "try-decrypt" -> "decrypt" would probably be in order.
>
> If this series lands, i'd be happy to supply such an term-normalizing
> series for subsequent consideration.
>
> If people feel that this term normalization is the main blocker to
> landing this series, i could try to rebase it with a different UI terms,
> but rebasing the series for this change feels like busy-work to me (and
> would be more effort than a simple normalization patch on top).  i'd
> rather spend my limited notmuch hacking+reviewing time providing useful
> features.

I don't think it's a blocker at all, but I do think the term
normalization should happen before the next release, since I think we
should change "try-decrypt" -> "decrypt", which would affect things
already in master.  But I very much hope this series will land before
the next release, in which case I think it's fine to wait to do the
normalization after this series lands.

jamie.


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


Re: [PATCH 07/18] crypto: new decryption policy "auto"

2017-11-11 Thread Jameson Graef Rollins
On Wed, Oct 25 2017, Daniel Kahn Gillmor  wrote:
> diff --git a/util/crypto.h b/util/crypto.h
> index b23ca747..dc95b4ca 100644
> --- a/util/crypto.h
> +++ b/util/crypto.h
> @@ -16,7 +16,8 @@ typedef struct _notmuch_crypto {
>  } _notmuch_crypto_t;
>  
>  GMimeObject *
> -_notmuch_crypto_decrypt (notmuch_message_t *message,
> +_notmuch_crypto_decrypt (notmuch_decryption_policy_t decrypt,
> +  notmuch_message_t *message,
>GMimeCryptoContext* crypto_ctx,
>GMimeMultipartEncrypted *part,
>GMimeDecryptResult **decrypt_result,

Why does _notmuch_crypt_decrypt need to have
"notmuch_decryption_policy_t decrypt" as an input argument?  Isn't
notmuch_decryption_policy_t already an attribute of the crypto_ctx?  Is
there some situation where the policy would differ from what's specified
in the crypto_ctx?

jamie.


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


Re: cleartext indexing version 5

2017-10-16 Thread Jameson Graef Rollins
On Sun, Oct 15 2017, Daniel Kahn Gillmor  wrote:
> I welcome review and feedback.

I have reviewed this patch series and everything looks in order.  Coding
style is consistent with notmuch standards.  The patch is
feature-complete, with appropriate documentation.  All tests pass.  I am
now using this series by default, with config set to automatically index
encrypted mail ("index.try_decrypt=true"), and have experienced no
issues.

I am strongly in support of this patch series.  Daniel is doing crucial
work pushing for widespread use of email encryption.  This series is
necessary in the context of that larger goal.  He's been pushing this
series for a year and a half now, so I think it's appropriate that it
final be integrated.

jamie.


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


Re: cleartext indexing, round 3

2017-10-10 Thread Jameson Graef Rollins
On Tue, Oct 10 2017, Daniel Kahn Gillmor  wrote:
> I've also pushed this series to the "cleartext-indexing" branch at
> https://gitlab.com/dkg/notmuch for those who prefer a direct git pull.
> it is currently git commit 6f7f6847141db2f031b29c68d966fa13c3be2da5.

Hey, Daniel, I think you mean the branch named "cleartext-index".
That's the branch in your repo that corresponds to that hash.

jamie.


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


Re: whitelisting

2017-03-06 Thread Jameson Graef Rollins
On Mon, Mar 06 2017, Steven Allen  wrote:
> Instead of iterating over all messages in spam, why not just iterate
> over *new* messages (`tag:new`) in your pre hook? That is (pseudo code):
>
> for message in `notmuch search tag:new and tag:spam`:
> for author in message.headers["From"]: 
> author = clean(author) # Extract the *actual* email address 
> (name@domain).
> # There are probably faster ways to check this...
> if `notmuch count tag:sent and to:author` > 0:
> notmuch tag -spam -- message
>
> That should be reasonably fast.

Thanks for the suggestion, Steven.  Yes, my intention was to restrict
over just "new", and yes, it is considerably faster.  Thanks for the
tip.

jamie.


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


Re: whitelisting

2017-03-06 Thread Jameson Graef Rollins
On Mon, Mar 06 2017, Jameson Graef Rollins <jroll...@finestructure.net> wrote:
> I could try to write a python script to iterate over all tag:spam,
> extract addresses from those messages, and match against the
> whitelist, but I doubt that will be any faster.

So a custom python script that iterates over all tag:new messages and
matches addresses against the white list is actually quite fast, so
hopefully this will be sufficient for my needs:

  query = 'tag:new AND tag:spam'
  me = get_me_addrs()
  whitelist = list(whitelist_iter())
  with notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE) as db:
  query = db.create_query(query)
  for doc in query.search_messages():
  a = match_addr(doc.get_header('From'))
  if a in whitelist:
  db.begin_atomic()
  doc.remove_tag('spam')
  db.end_atomic()

Guess I should have checked that first, so sorry about the noise.  Still
curious if anyone has come up with any other creative solutions to this
issue though...

jamie.


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


whitelisting

2017-03-06 Thread Jameson Graef Rollins
Hi, folks.  In my on-going war with spam [0], the new battle ground is
false positives: I'm losing too much ham to mis-classification.

For my first line of attack, I would like automatically whitelist every
address to which I have ever sent mail.  I realize this is flawed
(spammers frequently pose as me) but it's my best hope at the moment for
recovering false positives (which is more important than a couple of
additional false negatives).

It's fairly easy to find all such addresses, e.g.:

notmuch address --output=recipients from:jrollins...

But I'm having a hard time coming up with an efficient way to tag mail
coming from any of these address (which total ~4k).  The only command
line way to do it that I've come up with is:



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


Re: [PATCH 9/9] add has: query prefix to search for specific properties

2016-08-13 Thread Jameson Graef Rollins
On Sat, Aug 06 2016, David Bremner  wrote:
> @@ -217,7 +224,7 @@ exact matches like "tag:inbox"  or **probabilistic**, 
> supporting a more flexible
>  
>  
>  Boolean
> -   **tag:**, **id:**, **thread:**, **folder:**, **path:**
> +   **tag:**, **id:**, **thread:**, **folder:**, **path:**, **has**
>  Probabilistic
> **from:**, **to:**, **subject:**, **attachment:**, **mimetype:**

Super minor annoying comment, but I wonder if there's a missing colon in
the above addition:

> +   **tag:**, **id:**, **thread:**, **folder:**, **path:**, **has:**


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


Re: [WIP PATCH] emacs: query: completion for from: in searches

2016-08-12 Thread Jameson Graef Rollins
On Fri, Aug 12 2016, Mark Walters  wrote:
> This is a first attempt at tab completion for from: searches
> ---
>
> This sort of works (well it works but maybe in unexpected ways!)
>
> At the moment it completes to any word (as delimited by whitespace) in
> any address stored in the address hashmap. It does not trigger the
> address harvesting itself -- you either need to call
> notmuch-address-harvest-trigger manually, or use address completion
> when sending a mail first, and the harvest needs to finish before this
> will work.
>
> Since the hashmap does some address deduplication this will not give
> perfect completion (there may be names in your database it won't
> complete to). Also completion is case-sensitive.
>
> Getting a perfect solution may be more effort than its worth -- this
> will probably demonstrate whether something like this suffices.

Mark, this patch is awesome.  Really, it works great and is incredibly
useful.  With it I am able to trivially find emails that have
traditionally been very difficult for me to retrieve because the sender
addresses are obscure, e.g. I've only been able to remember a couple
starting characters.

This is on par with the tag: completion for usefulness.  It would be
great to extend this to to: completion as well.

+2

Thanks so much, Mark.

jamie.


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


Bug#826280: notmuch: shortcut to list tags

2016-06-03 Thread Jameson Graef Rollins
Package: notmuch
Version: 0.22-1
Severity: wishlist

I occaissionally want to grep through all tags used in my store:

notmuch search --output=tags '*' | grep 

It would be nice if there was a shortcut to output all tags to stdout:

notmuch tag | grep ...

Just utilizing the notmuch tag command when called with no arguments
would be the most intiuitive (just like git) and simplest.

Thanks.

jamie.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (600, 'testing'), (200, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages notmuch depends on:
ii  libc6   2.22-7
ii  libglib2.0-02.48.1-1
ii  libgmime-2.6-0  2.6.20-1+b1
ii  libnotmuch4 0.22-1
ii  libtalloc2  2.1.6-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages notmuch recommends:
ii  alot   0.3.6-1
ii  gnupg-agent2.1.11-7
ii  gpgsm  2.1.11-7
ii  notmuch-emacs  0.22-1
ii  notmuch-mutt   0.22-1
ii  notmuch-vim0.22-1

notmuch suggests no packages.

-- no debconf information

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


Re: [PATCH v3 15/16] added notmuch_message_reindex

2016-02-09 Thread Jameson Graef Rollins
On Sun, Jan 31 2016, Daniel Kahn Gillmor  wrote:
> This new function asks the database to reindex a given message, using
> the supplied indexopts.
>
> This can be used, for example, to index the cleartext of an encrypted
> message.

I just wanted to mention that I think there's a problem with the reindex
functionality introduced in this patch (or in 16/16).  It looks like
this function irrevocably busts apart threads.  dkg and I are
investigating.

jamie.


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


[PATCH 3/3] cli: crypto: S/MIME verification/decryption support

2015-03-02 Thread Jameson Graef Rollins
On Sun, Jan 18 2015, David Bremner  wrote:
> Jani Nikula  writes:
>
>> The notmuch-show flags --decrypt and --verify will now also process
>> S/MIME multiparts if encountered. Requires gmime-2.6 and gpgsm.
>>
>> Based on work by Jameson Graef Rollins .
>>
>
> I tend to agree this version is a bit easier to read, if a bit longer.
> Jamie, do you have any objections?
>
> I haven't tried this version with the tests in this thread.

So sorry to take so long to respond.  If Jani has a cleaner version of
the patch then by all means, please let it supersede what I have done.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20150302/51c91a52/attachment.pgp>


Re: [PATCH 3/3] cli: crypto: S/MIME verification/decryption support

2015-03-02 Thread Jameson Graef Rollins
On Sun, Jan 18 2015, David Bremner da...@tethera.net wrote:
 Jani Nikula j...@nikula.org writes:

 The notmuch-show flags --decrypt and --verify will now also process
 S/MIME multiparts if encountered. Requires gmime-2.6 and gpgsm.

 Based on work by Jameson Graef Rollins jroll...@finestructure.net.


 I tend to agree this version is a bit easier to read, if a bit longer.
 Jamie, do you have any objections?

 I haven't tried this version with the tests in this thread.

So sorry to take so long to respond.  If Jani has a cleaner version of
the patch then by all means, please let it supersede what I have done.

jamie.


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


[PATCH] test: initial tests for smime

2015-01-17 Thread Jameson Graef Rollins
On Sat, Jan 17 2015, David Bremner  wrote:
>> But do we really need to test the message output of openssl?  It seems
>> like it's broken, and if it ever gets fixed we'll need to change this
>> test.
>
> I think it's not so much broken as "canonical". There is some discussion
> in the openssl-smime man page that pointed me to RFC5751
> para 3.1.1
>
>MIME entities of major type "text" MUST have both their line endings
>and character set canonicalized.  The line ending MUST be the pair of
>characters 

Interesting, and oh well.  Not going to fall down that rabbit hole!

>> But all we really care about is that openssl is properly verifying the
>> message, yes?  Why not just test that and forget about the rest of
>> openssl's output?
>
> Maybe it doesn't add too much as long as the message is using the "clear
> signed" multipart/signed format. On the other hand there is an opaque
> signed format (application/pkcs7-mime with Signeddata) too, where it
> would be interesting to check for mangling of the text. Similarly, when
> we add a similar test for encryption, I think we do want to check the
> content, so we'll have to figure this out at some point.

But at any point are we using the output of the message piped through
openssl?  Does gmime (possibly via gpgsm) actually pipe the message
through openssl before further parsing it?  If so, then I guess we do
care about what openssl does to the original message.  If not, then I'm
still not sure we care.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



[PATCH] test: initial tests for smime

2015-01-17 Thread Jameson Graef Rollins
On Sat, Jan 17 2015, David Bremner  wrote:
> It was kindof my fault: my original script add embedded ^M's in it, but
> this "cleverness" was messed up somewhere in the patch process.
>
> Does this version work for you?

For some reason PATCH 3/4 no longer applies after substituting in this
patch as PATCH 1/4.

But do we really need to test the message output of openssl?  It seems
like it's broken, and if it ever gets fixed we'll need to change this
test.  But all we really care about is that openssl is properly
verifying the message, yes?  Why not just test that and forget about the
rest of openssl's output?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



SMIME patches v3, with some tests

2015-01-17 Thread Jameson Graef Rollins
On Sat, Jan 17 2015, David Bremner  wrote:
> Generating the certs was very much trial and error.  The net of
> a thousand lies may have led me astray a bit in that it may be
> possible to do this all with gpgsm and avoid the dependency on
> openssl. On the other hand, some tests is better than no tests.

Hey, David.  Thanks so much for covering our butts and finally putting
together these tests.

They look good to me.  Unfortunately, one of the tests is failing for
me, but I'm completely perplexed as to why:

T355-smime: Testing S/MIME signature verification and decryption
 PASS   Generate CA Cert
 PASS   Generate User Cert
 PASS   emacs delivery of S/MIME signed message
 FAIL   Signature verification (openssl)
--- T355-smime.4.OUTPUT 2015-01-17 19:06:46.806054727 +
+++ T355-smime.4.EXPECTED   2015-01-17 19:06:46.806054727 +
@@ -1,4 +1,4 @@
 Verification successful
-Content-Type: text/plain
-
-This is a test signed message.
+Content-Type: text/plain
+
+This is a test signed message.
 PASS   signature verification (notmuch CLI)

??  There's visually no difference between the supposedly diff'd text.
A hd of the output files being compared shows that openssl is using a
carriage return '0d' followed by line feed '0a' for every newline,
in place of a simple line feed '0a' in the original message file:

servo:~/src/notmuch/git [master*] 0$ hd 
test/tmp.T355-smime/T355-smime.4.EXPECTED 
  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 74 65  |Content-Type: te|
0010  78 74 2f 70 6c 61 69 6e  0a 0a 54 68 69 73 20 69  |xt/plain..This i|
0020  73 20 61 20 74 65 73 74  20 73 69 67 6e 65 64 20  |s a test signed |
0030  6d 65 73 73 61 67 65 2e  0a 56 65 72 69 66 69 63  |message..Verific|
0040  61 74 69 6f 6e 20 73 75  63 63 65 73 73 66 75 6c  |ation successful|
0050  0a|.|
0051
servo:~/src/notmuch/git [master*] 0$ hd test/tmp.T355-smime/T355-smime.4.OUTPUT 
  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 74 65  |Content-Type: te|
0010  78 74 2f 70 6c 61 69 6e  0d 0a 0d 0a 54 68 69 73  |xt/plainThis|
0020  20 69 73 20 61 20 74 65  73 74 20 73 69 67 6e 65  | is a test signe|
0030  64 20 6d 65 73 73 61 67  65 2e 0d 0a 56 65 72 69  |d message...Veri|
0040  66 69 63 61 74 69 6f 6e  20 73 75 63 63 65 73 73  |fication success|
0050  66 75 6c 0a   |ful.|
0054
servo:~/src/notmuch/git [master*] 0$ 

Bad openssl.  (Daniel off stage screaming: "why aren't you using
certtool!")

I also noticed that the "Verification successful" string is not reliably
being printed to stderr before the message output.

Two possible patches to fix the problems are attached below.  The second
is maybe slightly preferred, since it eliminates any reliance on broken
openssl message output whatsoever.

Thanks again for working on this, David.

jamie.


diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 0e5fd4a..5e3ec72 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -43,7 +43,9 @@ test_expect_success 'emacs delivery of S/MIME signed mes

 test_begin_subtest "Signature verification (openssl)"
 notmuch show --format=raw subject:"test signed message 001" |\
-openssl smime -verify -CAfile ca.crt >& OUTPUT
+openssl smime -verify -CAfile ca.crt 2> OUTPUT
+notmuch show --format=raw subject:"test signed message 001" |\
+openssl smime -verify -CAfile ca.crt | tr -d '\015' >> OUTPUT
 cat < EXPECTED
 Verification successful
 Content-Type: text/plain


diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 0e5fd4a..cba23e0 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -43,12 +43,9 @@ test_expect_success 'emacs delivery of S/MIME signed me

 test_begin_subtest "Signature verification (openssl)"
 notmuch show --format=raw subject:"test signed message 001" |\
-openssl smime -verify -CAfile ca.crt >& OUTPUT
+openssl smime -verify -CAfile ca.crt 2> OUTPUT
 cat < EXPECTED
 Verification successful
-Content-Type: text/plain
-
-This is a test signed message.
 EOF
 test_expect_equal_file OUTPUT EXPECTED

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: SMIME patches v3, with some tests

2015-01-17 Thread Jameson Graef Rollins
On Sat, Jan 17 2015, David Bremner da...@tethera.net wrote:
 Generating the certs was very much trial and error.  The net of
 a thousand lies may have led me astray a bit in that it may be
 possible to do this all with gpgsm and avoid the dependency on
 openssl. On the other hand, some tests is better than no tests.

Hey, David.  Thanks so much for covering our butts and finally putting
together these tests.

They look good to me.  Unfortunately, one of the tests is failing for
me, but I'm completely perplexed as to why:

T355-smime: Testing S/MIME signature verification and decryption
 PASS   Generate CA Cert
 PASS   Generate User Cert
 PASS   emacs delivery of S/MIME signed message
 FAIL   Signature verification (openssl)
--- T355-smime.4.OUTPUT 2015-01-17 19:06:46.806054727 +
+++ T355-smime.4.EXPECTED   2015-01-17 19:06:46.806054727 +
@@ -1,4 +1,4 @@
 Verification successful
-Content-Type: text/plain
-
-This is a test signed message.
+Content-Type: text/plain
+
+This is a test signed message.
 PASS   signature verification (notmuch CLI)

??  There's visually no difference between the supposedly diff'd text.
A hd of the output files being compared shows that openssl is using a
carriage return '0d' followed by line feed '0a' for every newline,
in place of a simple line feed '0a' in the original message file:

servo:~/src/notmuch/git [master*] 0$ hd 
test/tmp.T355-smime/T355-smime.4.EXPECTED 
  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 74 65  |Content-Type: te|
0010  78 74 2f 70 6c 61 69 6e  0a 0a 54 68 69 73 20 69  |xt/plain..This i|
0020  73 20 61 20 74 65 73 74  20 73 69 67 6e 65 64 20  |s a test signed |
0030  6d 65 73 73 61 67 65 2e  0a 56 65 72 69 66 69 63  |message..Verific|
0040  61 74 69 6f 6e 20 73 75  63 63 65 73 73 66 75 6c  |ation successful|
0050  0a|.|
0051
servo:~/src/notmuch/git [master*] 0$ hd test/tmp.T355-smime/T355-smime.4.OUTPUT 
  43 6f 6e 74 65 6e 74 2d  54 79 70 65 3a 20 74 65  |Content-Type: te|
0010  78 74 2f 70 6c 61 69 6e  0d 0a 0d 0a 54 68 69 73  |xt/plainThis|
0020  20 69 73 20 61 20 74 65  73 74 20 73 69 67 6e 65  | is a test signe|
0030  64 20 6d 65 73 73 61 67  65 2e 0d 0a 56 65 72 69  |d message...Veri|
0040  66 69 63 61 74 69 6f 6e  20 73 75 63 63 65 73 73  |fication success|
0050  66 75 6c 0a   |ful.|
0054
servo:~/src/notmuch/git [master*] 0$ 

Bad openssl.  (Daniel off stage screaming: why aren't you using
certtool!)

I also noticed that the Verification successful string is not reliably
being printed to stderr before the message output.

Two possible patches to fix the problems are attached below.  The second
is maybe slightly preferred, since it eliminates any reliance on broken
openssl message output whatsoever.

Thanks again for working on this, David.

jamie.


diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 0e5fd4a..5e3ec72 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -43,7 +43,9 @@ test_expect_success 'emacs delivery of S/MIME signed mes
 
 test_begin_subtest Signature verification (openssl)
 notmuch show --format=raw subject:test signed message 001 |\
-openssl smime -verify -CAfile ca.crt  OUTPUT
+openssl smime -verify -CAfile ca.crt 2 OUTPUT
+notmuch show --format=raw subject:test signed message 001 |\
+openssl smime -verify -CAfile ca.crt | tr -d '\015'  OUTPUT
 cat EOF  EXPECTED
 Verification successful
 Content-Type: text/plain


diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 0e5fd4a..cba23e0 100755
--- a/test/T355-smime.sh
+++ b/test/T355-smime.sh
@@ -43,12 +43,9 @@ test_expect_success 'emacs delivery of S/MIME signed me
 
 test_begin_subtest Signature verification (openssl)
 notmuch show --format=raw subject:test signed message 001 |\
-openssl smime -verify -CAfile ca.crt  OUTPUT
+openssl smime -verify -CAfile ca.crt 2 OUTPUT
 cat EOF  EXPECTED
 Verification successful
-Content-Type: text/plain
-
-This is a test signed message.
 EOF
 test_expect_equal_file OUTPUT EXPECTED
 


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


Re: [PATCH] test: initial tests for smime

2015-01-17 Thread Jameson Graef Rollins
On Sat, Jan 17 2015, David Bremner da...@tethera.net wrote:
 It was kindof my fault: my original script add embedded ^M's in it, but
 this cleverness was messed up somewhere in the patch process.

 Does this version work for you?

For some reason PATCH 3/4 no longer applies after substituting in this
patch as PATCH 1/4.

But do we really need to test the message output of openssl?  It seems
like it's broken, and if it ever gets fixed we'll need to change this
test.  But all we really care about is that openssl is properly
verifying the message, yes?  Why not just test that and forget about the
rest of openssl's output?

jamie.


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


Re: [PATCH] test: initial tests for smime

2015-01-17 Thread Jameson Graef Rollins
On Sat, Jan 17 2015, David Bremner da...@tethera.net wrote:
 But do we really need to test the message output of openssl?  It seems
 like it's broken, and if it ever gets fixed we'll need to change this
 test.

 I think it's not so much broken as canonical. There is some discussion
 in the openssl-smime man page that pointed me to RFC5751
 para 3.1.1

MIME entities of major type text MUST have both their line endings
and character set canonicalized.  The line ending MUST be the pair of
characters CRLF

Interesting, and oh well.  Not going to fall down that rabbit hole!

 But all we really care about is that openssl is properly verifying the
 message, yes?  Why not just test that and forget about the rest of
 openssl's output?

 Maybe it doesn't add too much as long as the message is using the clear
 signed multipart/signed format. On the other hand there is an opaque
 signed format (application/pkcs7-mime with Signeddata) too, where it
 would be interesting to check for mangling of the text. Similarly, when
 we add a similar test for encryption, I think we do want to check the
 content, so we'll have to figure this out at some point.

But at any point are we using the output of the message piped through
openssl?  Does gmime (possibly via gpgsm) actually pipe the message
through openssl before further parsing it?  If so, then I guess we do
care about what openssl does to the original message.  If not, then I'm
still not sure we care.

jamie.


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


questions about post-new/insert hooks

2014-12-23 Thread Jameson Graef Rollins
Hi, folks.  I was wondering about possible race conditions in the
post-new hook.  Given that the database does not remain locked during
execution of the post-new hook, isn't there a possibility that more new
messages will be added to the database before the post-new hook has
finished processing?  If so, I can imagine multiple ways that might
break typical logic in post-new hooks.  I wonder if this race condition
could be avoided by e.g. sending the post-new hook the message ids of
all newly-added messages on stdin.  The hook could then use the message
ids to process just the new messages, without worrying that other
messages could have been added in the middle of processing.  Has anyone
thought about this?

I was also wondering about per-message insertion hooks.  The new(ish)
insert command has a post-insert hook which is run on a per-message
insertion basis.  What about adding a hook that would run on each
message being added with new?  This would also be a way to get rid of
the above mentioned race condition, and might allow for simpler message
content filtering for those of us using notmuch-new instead of
notmuch-insert.  Maybe in this the per-message hook could get the full
text of the message on stdin, and the message id as argument.

I haven't fully thought the implications of this stuff through, so I
would love to hear what others think.

The reason I bring all this up is that I'm trying to figure out the best
way to integrate spam classification into my notmuch setup, which for
some reason is currently proving exceedingly difficult.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



questions about post-new/insert hooks

2014-12-23 Thread Jameson Graef Rollins
Hi, folks.  I was wondering about possible race conditions in the
post-new hook.  Given that the database does not remain locked during
execution of the post-new hook, isn't there a possibility that more new
messages will be added to the database before the post-new hook has
finished processing?  If so, I can imagine multiple ways that might
break typical logic in post-new hooks.  I wonder if this race condition
could be avoided by e.g. sending the post-new hook the message ids of
all newly-added messages on stdin.  The hook could then use the message
ids to process just the new messages, without worrying that other
messages could have been added in the middle of processing.  Has anyone
thought about this?

I was also wondering about per-message insertion hooks.  The new(ish)
insert command has a post-insert hook which is run on a per-message
insertion basis.  What about adding a hook that would run on each
message being added with new?  This would also be a way to get rid of
the above mentioned race condition, and might allow for simpler message
content filtering for those of us using notmuch-new instead of
notmuch-insert.  Maybe in this the per-message hook could get the full
text of the message on stdin, and the message id as argument.

I haven't fully thought the implications of this stuff through, so I
would love to hear what others think.

The reason I bring all this up is that I'm trying to figure out the best
way to integrate spam classification into my notmuch setup, which for
some reason is currently proving exceedingly difficult.

jamie.


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


auto-choosing reply addresses in notmuch-emacs

2014-11-14 Thread Jameson Graef Rollins
Hi, folks.  I wonder if anyone knows of a way to tell the emacs client
to use different email addresses to respond to mail from different
sources.  So for instance, I would like to respond to mail to one
mailing list from one address, and to another mailing list from a
different address.  Ideally I would be able to set up some sort of
filter rules such that if the mail is from ".*@example.com" I would
respond with my me at example.com address, and if the mail is from
".*@example.org" I would respond with my jrollins at finestructure.net
address.

Does anyone already do anything like this?  I would how hard it would be
to setup built-in support for something like that.  Given that notmuch
generates replies, maybe we could add it to the notmuch cli somehow,
with some new config fields?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



auto-choosing reply addresses in notmuch-emacs

2014-11-14 Thread Jameson Graef Rollins
Hi, folks.  I wonder if anyone knows of a way to tell the emacs client
to use different email addresses to respond to mail from different
sources.  So for instance, I would like to respond to mail to one
mailing list from one address, and to another mailing list from a
different address.  Ideally I would be able to set up some sort of
filter rules such that if the mail is from .*@example.com I would
respond with my m...@example.com address, and if the mail is from
.*@example.org I would respond with my jroll...@finestructure.net
address.

Does anyone already do anything like this?  I would how hard it would be
to setup built-in support for something like that.  Given that notmuch
generates replies, maybe we could add it to the notmuch cli somehow,
with some new config fields?

jamie.


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


[DRAFT PATCH] modified notmuch-emacs-mua

2014-11-03 Thread Jameson Graef Rollins
On Thu, Jul 10 2014, Tomi Ollila  wrote:
> Highlights:
>
> * notmuch-emacs-mua without arguments runs (notmuch-hello)
>
> * runs emacs(1) in case emacsclient(1) fails to connect to running emacs
>
> * takes -nw option
>
> * handles mailto:
>
> * --from option when sending non-mailto: way
>
> * -i includes file --body[= ]string inserts string

Hi, Tomi.  I think including an emacs CLI like this is probably a good
idea.  I might not use it myself, since I've already concocted one for
my personal use, but I still think it's a good idea.

The particular thing I'm interested in, though, is mailto: URL handling:

> + mailto:*)
> + oIFS=$IFS; IFS=; OPTARG="$*" IFS=$oIFS
> + escape_optarg
> + exec_mua "(progn (require 'notmuch) (browse-url-mail \"$OPTARG\"))"
> + exit
> +esac

I have submitted multiple revisions of a patch that handles mailto: URLs
in notmuch-mua.el:

id:1334438868-17168-1-git-send-email-jrollins at finestructure.net

It hasn't been accepted yet, though.  I've tried browse-url-mail before,
and it would be convenient to use it.  However, used on it's own it has
the problem that it doesn't open new message buffer in the "notmuch"
way.  For instance, I prefer my new notmuch buffers to appear in new
frames.  browse-url-mail doesn't respect this.  Maybe it could be
wrapped in a notmuch-mua-mailto function, or you could instead be using
the function I submitted?

I've been a bit out of touch for a while, so forgive me if anything has
change that I'm not aware of.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: [DRAFT PATCH] modified notmuch-emacs-mua

2014-11-03 Thread Jameson Graef Rollins
On Thu, Jul 10 2014, Tomi Ollila tomi.oll...@iki.fi wrote:
 Highlights:

 * notmuch-emacs-mua without arguments runs (notmuch-hello)

 * runs emacs(1) in case emacsclient(1) fails to connect to running emacs

 * takes -nw option

 * handles mailto:

 * --from option when sending non-mailto: way

 * -i includes file --body[= ]string inserts string

Hi, Tomi.  I think including an emacs CLI like this is probably a good
idea.  I might not use it myself, since I've already concocted one for
my personal use, but I still think it's a good idea.

The particular thing I'm interested in, though, is mailto: URL handling:

 + mailto:*)
 + oIFS=$IFS; IFS=; OPTARG=$* IFS=$oIFS
 + escape_optarg
 + exec_mua (progn (require 'notmuch) (browse-url-mail \$OPTARG\))
 + exit
 +esac

I have submitted multiple revisions of a patch that handles mailto: URLs
in notmuch-mua.el:

id:1334438868-17168-1-git-send-email-jroll...@finestructure.net

It hasn't been accepted yet, though.  I've tried browse-url-mail before,
and it would be convenient to use it.  However, used on it's own it has
the problem that it doesn't open new message buffer in the notmuch
way.  For instance, I prefer my new notmuch buffers to appear in new
frames.  browse-url-mail doesn't respect this.  Maybe it could be
wrapped in a notmuch-mua-mailto function, or you could instead be using
the function I submitted?

I've been a bit out of touch for a while, so forgive me if anything has
change that I'm not aware of.

jamie.


pgp9NjsOJTGDl.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Tabulation in multiline headers

2014-10-17 Thread Jameson Graef Rollins
On Fri, Oct 17 2014, Sergei Shilovsky  wrote:
> Lets consider this message:
>
> id:87r5aucoeg.fsf at servo.finestructure.net
>
> Its subject spreads over 2 lines and the 2nd line is indented with
>  in the file:
>
> Subject: running the crypto branch [was: Re: Hiding HTML mime-parts and/or
> scrubbing (gmail's) HTML-based citation]
>
> The issue is that notmuch_message_get_header() returns this whole line
> with the Tab
> character (though I guess it should not):
>
> running the crypto branch [was: Re: Hiding HTML mime-parts
> and/orscrubbing (gmail's) HTML-based citation]
>
> This file could be imported from gmane though with mb2md. My test long
> subject message (sent via gmail) didn't got any tabulation.

Hi, Sergei.  I'm not clear on where exactly you are seeing a problem
with this tab in the subject line.  Is it showing up somewhere you think
it shouldn't?

Headers that are broken across multiple lines must be indented, so I
think it is fairly standard for MUAs to insert either a space or a tab
at that point.

>  No idea where this tabulation could came from, but would that be
> correct to replace  with space in libnotmuch itself?

User-Agent: Notmuch/0.5-102-ge86ac1d (http://notmuchmail.org) Emacs/23.2.1
(i486-pc-linux-gnu)

I'm not sure libnotmuch should be doing any scrubbing of the message
contents.  The emacs UI does seem to replace the tab with a space,
though.  Maybe other MUAs should be doing the same?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: Tabulation in multiline headers

2014-10-17 Thread Jameson Graef Rollins
On Fri, Oct 17 2014, Sergei Shilovsky sshilov...@gmail.com wrote:
 Lets consider this message:

 id:87r5aucoeg@servo.finestructure.net

 Its subject spreads over 2 lines and the 2nd line is indented with
 Tab in the file:

 Subject: running the crypto branch [was: Re: Hiding HTML mime-parts and/or
 Tab---scrubbing (gmail's) HTML-based citation]

 The issue is that notmuch_message_get_header() returns this whole line
 with the Tab
 character (though I guess it should not):

 running the crypto branch [was: Re: Hiding HTML mime-parts
 and/orTabscrubbing (gmail's) HTML-based citation]

 This file could be imported from gmane though with mb2md. My test long
 subject message (sent via gmail) didn't got any tabulation.

Hi, Sergei.  I'm not clear on where exactly you are seeing a problem
with this tab in the subject line.  Is it showing up somewhere you think
it shouldn't?

Headers that are broken across multiple lines must be indented, so I
think it is fairly standard for MUAs to insert either a space or a tab
at that point.

  No idea where this tabulation could came from, but would that be
 correct to replace tab with space in libnotmuch itself?

User-Agent: Notmuch/0.5-102-ge86ac1d (http://notmuchmail.org) Emacs/23.2.1
(i486-pc-linux-gnu)

I'm not sure libnotmuch should be doing any scrubbing of the message
contents.  The emacs UI does seem to replace the tab with a space,
though.  Maybe other MUAs should be doing the same?

jamie.


pgpcujDOT4Yvx.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Bug#755544: notmuch-emacs: doesn't check gpg/pgp signatures by default

2014-07-21 Thread Jameson Graef Rollins
On Mon, Jul 21 2014, David Bremner  wrote:
> notmuch folks: it seems that in vagrant's message, and several others I
> checked, it notmuch-crypto-process-mime==nil, then no signature button
> is created at all.

Yes, this is true.  The signature button is pretty meaningless if we're
not processing the signature.

Maybe instead by default we could have a signature button that opens up
a notmuch-crypto-process-mime customization buffer?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: Bug#755544: notmuch-emacs: doesn't check gpg/pgp signatures by default

2014-07-21 Thread Jameson Graef Rollins
On Mon, Jul 21 2014, David Bremner da...@tethera.net wrote:
 notmuch folks: it seems that in vagrant's message, and several others I
 checked, it notmuch-crypto-process-mime==nil, then no signature button
 is created at all.

Yes, this is true.  The signature button is pretty meaningless if we're
not processing the signature.

Maybe instead by default we could have a signature button that opens up
a notmuch-crypto-process-mime customization buffer?

jamie.


pgpp50bMyggRM.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 1/2] cli: S/MIME verification/decryption support

2014-07-06 Thread Jameson Graef Rollins
On Tue, Jul 01 2014, David Bremner  wrote:
> Jameson Graef Rollins  writes:
>
>> The notmuch-show flags --decrypt and --verify will now also process
>> S/MIME multiparts if encountered.  Requires gmime-2.6 and gpgsm.
>
> I was trying to figure out how to test this. I tried a few couple signed
> messages, but I got "bad" signature status in both cases.
>
> An example message is attached.
>
>http://mid.gmane.org/4F1423A1.90909 at cms.hu-berlin.de
>
> Are we missing the signature between bad and untrusted signatures, or
> does that distinction not exist for S/MIME?

Hey, David.  How did you generate the signatures?  I would love to see a
script that generates a signature on a test message.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140706/ea5d8223/attachment.pgp>


Re: [PATCH 1/2] cli: S/MIME verification/decryption support

2014-07-06 Thread Jameson Graef Rollins
On Tue, Jul 01 2014, David Bremner da...@tethera.net wrote:
 Jameson Graef Rollins jroll...@finestructure.net writes:

 The notmuch-show flags --decrypt and --verify will now also process
 S/MIME multiparts if encountered.  Requires gmime-2.6 and gpgsm.

 I was trying to figure out how to test this. I tried a few couple signed
 messages, but I got bad signature status in both cases.

 An example message is attached.

http://mid.gmane.org/4f1423a1.90...@cms.hu-berlin.de

 Are we missing the signature between bad and untrusted signatures, or
 does that distinction not exist for S/MIME?

Hey, David.  How did you generate the signatures?  I would love to see a
script that generates a signature on a test message.

jamie.


pgpirxW36U8lj.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


github

2014-05-16 Thread Jameson Graef Rollins
On Mon, May 12 2014, Felipe Contreras  wrote:
> How would our development cycle be controlled by GitHub?
>
> The whole point of a distributed VCS is that there isn't a single
> central repository you rely on.

If this is true then why are we even talking about github?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: github

2014-05-16 Thread Jameson Graef Rollins
On Mon, May 12 2014, Felipe Contreras felipe.contre...@gmail.com wrote:
 How would our development cycle be controlled by GitHub?

 The whole point of a distributed VCS is that there isn't a single
 central repository you rely on.

If this is true then why are we even talking about github?

jamie.


pgpH219XD6zhJ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


github

2014-05-12 Thread Jameson Graef Rollins
On Sun, Apr 27 2014, Jani Nikula  wrote:
> To be honest, I am slightly concerned by the popularity of
> github. Despite being a hosting site primarily for open source, it *is*
> a proprietary platform. Source code hosting is plain git, but AFAIK all
> the rest (review process, issue tracking, and so on) is pretty much at
> the whim and mercy of the company running it. They make a change, you
> adapt. If you don't want to adapt, it's not easy to switch over to
> another service provider either if you've built your process around
> github.
>
> So even if the features of github amazed me (they don't), I would have
> pretty strong reservations about relying on them.

There seems to have been a lot of discussion on the list recently about
github.  I just want to express my very strong agreement with Jani's
sentiment above.  A lot of us in the notmuch community moved to notmuch
because we didn't want our email controlled by a single service provider
(e.g. gmail).  I don't want our development cycle controlled by github
(or any other proprietary SCM) for many of the same reasons.

The current notmuch development process, that's been built up over the
last five years, is the most efficient and effective I've ever worked
with.  It's really a well-oiled machine.  Newcomers (always welcome!)
should give it a try before suggesting we abandon it.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: github

2014-05-12 Thread Jameson Graef Rollins
On Sun, Apr 27 2014, Jani Nikula j...@nikula.org wrote:
 To be honest, I am slightly concerned by the popularity of
 github. Despite being a hosting site primarily for open source, it *is*
 a proprietary platform. Source code hosting is plain git, but AFAIK all
 the rest (review process, issue tracking, and so on) is pretty much at
 the whim and mercy of the company running it. They make a change, you
 adapt. If you don't want to adapt, it's not easy to switch over to
 another service provider either if you've built your process around
 github.

 So even if the features of github amazed me (they don't), I would have
 pretty strong reservations about relying on them.

There seems to have been a lot of discussion on the list recently about
github.  I just want to express my very strong agreement with Jani's
sentiment above.  A lot of us in the notmuch community moved to notmuch
because we didn't want our email controlled by a single service provider
(e.g. gmail).  I don't want our development cycle controlled by github
(or any other proprietary SCM) for many of the same reasons.

The current notmuch development process, that's been built up over the
last five years, is the most efficient and effective I've ever worked
with.  It's really a well-oiled machine.  Newcomers (always welcome!)
should give it a try before suggesting we abandon it.

jamie.


pgpcj9A5WINCH.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


folder and path completely broken in HEAD?

2014-05-09 Thread Jameson Graef Rollins
On Sat, May 03 2014, dm-list-email-notmuch at scs.stanford.edu wrote:
> First, are there people out there who do not use a collection of maildir
> directories, with all mail in cur and new?

o/ I completely abandoned the usage of separate mail "folders" since I
started using notmuch.  All my mail now just goes into a single maildir.
I consider this one of notmuch's awesome features.  It's honestly been a
bit perplexing to me that folks have put so much work into
parsing/indexing paths and folders given that it seems to me that
notmuch has utterly obviated the need to worry about such things (thank
god!).

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: folder and path completely broken in HEAD?

2014-05-09 Thread Jameson Graef Rollins
On Sat, May 03 2014, dm-list-email-notm...@scs.stanford.edu wrote:
 First, are there people out there who do not use a collection of maildir
 directories, with all mail in cur and new?

o/ I completely abandoned the usage of separate mail folders since I
started using notmuch.  All my mail now just goes into a single maildir.
I consider this one of notmuch's awesome features.  It's honestly been a
bit perplexing to me that folks have put so much work into
parsing/indexing paths and folders given that it seems to me that
notmuch has utterly obviated the need to worry about such things (thank
god!).

jamie.


pgpRJXuRxDyWc.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


emacs reply fills X clipboard with reply message body

2014-05-08 Thread Jameson Graef Rollins
On Thu, May 08 2014, David Edmondson  wrote:
> [ I'm cycling around back through some old mail. ]
>
> On Tue, Sep 17 2013, Jameson Graef Rollins wrote:
>> I've just started noticing that when I reply to messages from the emacs
>> UI, my X clipboard is filled with the body of the reply message,
>> displacing whatever was in there previously.
>
> This doesn't happen to me today. Is it still a problem for other people?

This was fixed a while back, although I don't remember which series it
was that fixed it.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140508/cf9e3a5f/attachment.pgp>


Re: emacs reply fills X clipboard with reply message body

2014-05-08 Thread Jameson Graef Rollins
On Thu, May 08 2014, David Edmondson d...@dme.org wrote:
 [ I'm cycling around back through some old mail. ]

 On Tue, Sep 17 2013, Jameson Graef Rollins wrote:
 I've just started noticing that when I reply to messages from the emacs
 UI, my X clipboard is filled with the body of the reply message,
 displacing whatever was in there previously.

 This doesn't happen to me today. Is it still a problem for other people?

This was fixed a while back, although I don't remember which series it
was that fixed it.

jamie.


pgpvRnUZkWCol.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re:

2014-05-06 Thread Jameson Graef Rollins
On Tue, May 06 2014, David Bremner da...@tethera.net wrote:
 The first of these fixes a build failure on Debian Linux/armhf (and
 OS/X). If the patch seems ok, I'd like to roll it into a bug fix
 release.  The second is more of a suggestion to make that atomicity
 test easier to debug, since it seems to find the dark corners of gdb.

Hey, David.  It looks like Charles's series fixes some of these same
issues and more:

id:1399395748-44920-1-git-send-email-ccel...@cs.stanford.edu

jamie.


pgpLxkBoffw_g.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: remove auto-signing of replies to signed messages

2014-04-15 Thread Jameson Graef Rollins
On Tue, Apr 15 2014, David Bremner  wrote:
> Jameson Graef Rollins  writes:
>
>> It was decided that auto-signing is potentially too troublesome for the
>> apparently common case of users who enable crypto processing for the
>> purpose of checking signature validity but who are not in a position to
>> sign out-going messages.  Users can still manually invoke signing as needed.
>
> pushed

Awesome.  Thank you Jani and David for fixing this issue.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140415/3cdb7d96/attachment.pgp>


Re: [PATCH] emacs: remove auto-signing of replies to signed messages

2014-04-15 Thread Jameson Graef Rollins
On Tue, Apr 15 2014, David Bremner da...@tethera.net wrote:
 Jameson Graef Rollins jroll...@finestructure.net writes:

 It was decided that auto-signing is potentially too troublesome for the
 apparently common case of users who enable crypto processing for the
 purpose of checking signature validity but who are not in a position to
 sign out-going messages.  Users can still manually invoke signing as needed.

 pushed

Awesome.  Thank you Jani and David for fixing this issue.

jamie.


pgpT2pkPrVjBE.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: remove auto-signing of replies to signed messages

2014-04-14 Thread Jameson Graef Rollins
It was decided that auto-signing is potentially too troublesome for the
apparently common case of users who enable crypto processing for the
purpose of checking signature validity but who are not in a position to
sign out-going messages.  Users can still manually invoke signing as needed.

Encrypting replies to encrypted messages is more of a security issue
so we leave it in place.
---
 emacs/notmuch-mua.el | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index bf6253f..95e4a4d 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -116,10 +116,9 @@ list."
notmuch-mua-hidden-headers))

 (defun notmuch-mua-reply-crypto (parts)
+  "Add mml sign-encrypt flag if any part of original message is encrypted."
   (loop for part in parts
-   if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/signed")
- do (mml-secure-message-sign)
-   else if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/encrypted")
+   if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/encrypted")
  do (mml-secure-message-sign-encrypt)
else if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/*")
  do (notmuch-mua-reply-crypto (plist-get part :content
@@ -236,7 +235,7 @@ list."
;; Quote the original message according to the user's configured style.
(message-cite-original)))

-;; Sign and/or encrypt replies to signed and/or encrypted messages.
+;; Crypto processing based crypto content of the original message
 (when process-crypto
   (notmuch-mua-reply-crypto (plist-get original :body

-- 
1.9.1



Re: [PATCH] emacs: sign/encrypt replies to signed/encrypted messages

2014-04-14 Thread Jameson Graef Rollins
On Mon, Apr 14 2014, Jani Nikula j...@nikula.org wrote:
 On Apr 14, 2014 10:17 AM, David Bremner da...@tethera.net wrote:

 Jani Nikula j...@nikula.org writes:
  +(defun notmuch-mua-reply-crypto (parts)
  +  (loop for part in parts
  + if (notmuch-match-content-type (plist-get part :content-type)
 multipart/signed)
  +   do (mml-secure-message-sign)

 How do people feel about disabling/removing the previous two lines?


 I'd be fine with that (see the commit message).

I'd be fine with that as well.  I auto-sign all outgoing mail regardless
of the signature status of what I'm replying to, so that's fine.
Auto-encrypting replies to encrypted mail is actually a security issue,
whereas auto-signing is not, so as long as we have the auto-encrypting
always enabled that should ok.

David, did you want to handle the patch?  If not let me know and I'll do
it.

jamie.


pgpSILVLb6R85.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: remove auto-signing of replies to signed messages

2014-04-14 Thread Jameson Graef Rollins
It was decided that auto-signing is potentially too troublesome for the
apparently common case of users who enable crypto processing for the
purpose of checking signature validity but who are not in a position to
sign out-going messages.  Users can still manually invoke signing as needed.

Encrypting replies to encrypted messages is more of a security issue
so we leave it in place.
---
 emacs/notmuch-mua.el | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index bf6253f..95e4a4d 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -116,10 +116,9 @@ list.
notmuch-mua-hidden-headers))
 
 (defun notmuch-mua-reply-crypto (parts)
+  Add mml sign-encrypt flag if any part of original message is encrypted.
   (loop for part in parts
-   if (notmuch-match-content-type (plist-get part :content-type) 
multipart/signed)
- do (mml-secure-message-sign)
-   else if (notmuch-match-content-type (plist-get part :content-type) 
multipart/encrypted)
+   if (notmuch-match-content-type (plist-get part :content-type) 
multipart/encrypted)
  do (mml-secure-message-sign-encrypt)
else if (notmuch-match-content-type (plist-get part :content-type) 
multipart/*)
  do (notmuch-mua-reply-crypto (plist-get part :content
@@ -236,7 +235,7 @@ list.
;; Quote the original message according to the user's configured style.
(message-cite-original)))
 
-;; Sign and/or encrypt replies to signed and/or encrypted messages.
+;; Crypto processing based crypto content of the original message
 (when process-crypto
   (notmuch-mua-reply-crypto (plist-get original :body
 
-- 
1.9.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: process crypto for reply only when specified

2014-04-13 Thread Jameson Graef Rollins
On Sun, Apr 13 2014, Tomi Ollila  wrote:
>> Perhaps people with no ability to sign are less likely to have
>> "notmuch-crypto-process-mime" set?  Or we can add another configuration
>> variable initialized from notmuch-crypto-process-mime, but allowing
>> people to shut this off.
>
> Well, I set notmuch-crypto-process-mime to nil -- it still wants to
> sign the message and runs gpg...

Was my followup patch applied?  My patch controls the insertion of the
mml tag depending on whether or not notmuch-crypto-process-mime is t or
not.  If notmuch-crypto-process-mime is nil the tag won't be added.
Presumably you either did not have that patch applied, or had manually
set it to t?

In any event, if the mml tag is present, it's no longer in notmuch's
hands; emacs's mail processing is handling things and calling gpg-agent
to sign/encrypt the message.

Can you clarify what exactly your situation was?

Presumably people who have not set up any crypto processing should not
have notmuch-crypto-process-mime set t.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: [PATCH] emacs: process crypto for reply only when specified

2014-04-13 Thread Jameson Graef Rollins
On Sun, Apr 13 2014, Tomi Ollila tomi.oll...@iki.fi wrote:
 Perhaps people with no ability to sign are less likely to have
 notmuch-crypto-process-mime set?  Or we can add another configuration
 variable initialized from notmuch-crypto-process-mime, but allowing
 people to shut this off.

 Well, I set notmuch-crypto-process-mime to nil -- it still wants to
 sign the message and runs gpg...

Was my followup patch applied?  My patch controls the insertion of the
mml tag depending on whether or not notmuch-crypto-process-mime is t or
not.  If notmuch-crypto-process-mime is nil the tag won't be added.
Presumably you either did not have that patch applied, or had manually
set it to t?

In any event, if the mml tag is present, it's no longer in notmuch's
hands; emacs's mail processing is handling things and calling gpg-agent
to sign/encrypt the message.

Can you clarify what exactly your situation was?

Presumably people who have not set up any crypto processing should not
have notmuch-crypto-process-mime set t.

jamie.


pgp3U5wDLQOHU.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Feature suggestion. Indexing encrypted mail?

2014-04-07 Thread Jameson Graef Rollins
On Mon, Apr 07 2014, Jeremy Nickurak  wrote:
> Nonetheess, if you can tell from the index that a given message contains
> the words "hotel" "wine" "wife" "secret" and "rendezvous", you can infer a
> *lot* about the contents of encrypted contents of the message.

Of course.  Given that the content of the message will be stored
unencrypted in the db, indexing encrypted messages is potentially a foot
gun.  If we were to enable a feature like this, it would definitely be a
user-beware situation.  I don't see any way around that.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Feature suggestion. Indexing encrypted mail?

2014-04-07 Thread Jameson Graef Rollins
On Mon, Apr 07 2014, john.wyzer at gmx.de wrote:
>> confess i haven't been following closely), it wouldn't be much extra
>> effort for someone to implement a filter that strips encryption from the
>> message.  (this might still have the problem mentioned above about also
>> stripping PGP/MIME signatures, but the signatures and the decrypted
>> message itself would remain intact so they could be shown directly by
>> notmuch show without trouble).
>
> I don't understand that. :-(
> This sounds as if the view of the message is not generated from the
> mail storage. Isn't the purpose of the index to find the appropriate
> message file and everything else is generated from that file?

I think that's exactly what Daniel is saying: what's viewed comes from
the message directly, and not from the db.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



[PATCH] emacs: process crypto for reply only when specified

2014-04-07 Thread Jameson Graef Rollins
This is a tweak to patch "emacs: sign/encrypt replies to
signed/encrypted messages" to only add mml crypto flags for replys
when crypto processing has been activated.

---

Thanks to mjw1009 for implementation suggestions.

Jani, you might consider squashing this with your original for a v2.
Pushing them separately seems fine to me as well.

jamie.

---
 emacs/notmuch-mua.el | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 9fb84b5..bf6253f 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -160,9 +160,10 @@ list."

 (defun notmuch-mua-reply (query-string  sender reply-all)
   (let ((args '("reply" "--format=sexp" "--format-version=1"))
+   (process-crypto notmuch-show-process-crypto)
reply
original)
-(when notmuch-show-process-crypto
+(when process-crypto
   (setq args (append args '("--decrypt"

 (if reply-all
@@ -236,7 +237,8 @@ list."
(message-cite-original)))

 ;; Sign and/or encrypt replies to signed and/or encrypted messages.
-(notmuch-mua-reply-crypto (plist-get original :body)))
+(when process-crypto
+  (notmuch-mua-reply-crypto (plist-get original :body

   ;; Push mark right before signature, if any.
   (message-goto-signature)
-- 
1.9.1



[PATCH] emacs: sign/encrypt replies to signed/encrypted messages

2014-04-07 Thread Jameson Graef Rollins
On Sat, Apr 05 2014, Jani Nikula  wrote:
> This is a simple approach to improving security when replying to
> signed or encrypted messages. If the message being replied to was
> signed, add mml tag to sign the reply. If the message being replied to
> was encrypted, add mml tag to sign and encrypt the reply.

Jani, thank you so much for this patch!  This is really great, and I
very much appreciate your work on it.

I've tested it and so far it does exactly as advertised: replys to
encrypted messages automatically get the correct mml tags to encrypt the
reply.  I sign all messages by default, and it doesn't seem to interact
adversely with that configuration afaict.

> This may need configuration; I for one might want to encrypt replies
> to encrypted messages, but not always sign replies to signed messages.
>
> This still includes a slight bug: if any mml tags are added, they are
> included in the region containing the quoted parts. Killing the region
> will kill the mml tags too.

Both of these issues seem pretty minor to me.  It certainly gets my vote
to push without these additional features (especially considering the
security benefits).

I just have one comment below:

> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index ba3ef275ec5e..9fb84b57b030 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -224,7 +233,10 @@ list."
>   (set-mark (point))
>   (goto-char start)
>   ;; Quote the original message according to the user's configured style.
> - (message-cite-original
> + (message-cite-original)))
> +
> +;; Sign and/or encrypt replies to signed and/or encrypted messages.
> +(notmuch-mua-reply-crypto (plist-get original :body)))

Maybe we should check to see if crypto processing is activated before
adding this additional crypto handling.  I would have guessed we might
want something like this instead:

(when notmuch-show-process-crypto
  (notmuch-mua-reply-crypto (plist-get original :body

However, for some reason I can't get this to work.  It looks like
notmuch-show-process-crypto keeps evaluating to false in this context,
regardless of whether crypto processing has been engaged.  I'm unclear
why.  Anyone know see how notmuch-show-process-crypto would evaluate to
false here, even when it evaluates to true earlier in the same
notmuch-mua-reply call?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Re: [PATCH] emacs: sign/encrypt replies to signed/encrypted messages

2014-04-07 Thread Jameson Graef Rollins
On Sat, Apr 05 2014, Jani Nikula j...@nikula.org wrote:
 This is a simple approach to improving security when replying to
 signed or encrypted messages. If the message being replied to was
 signed, add mml tag to sign the reply. If the message being replied to
 was encrypted, add mml tag to sign and encrypt the reply.

Jani, thank you so much for this patch!  This is really great, and I
very much appreciate your work on it.

I've tested it and so far it does exactly as advertised: replys to
encrypted messages automatically get the correct mml tags to encrypt the
reply.  I sign all messages by default, and it doesn't seem to interact
adversely with that configuration afaict.

 This may need configuration; I for one might want to encrypt replies
 to encrypted messages, but not always sign replies to signed messages.

 This still includes a slight bug: if any mml tags are added, they are
 included in the region containing the quoted parts. Killing the region
 will kill the mml tags too.

Both of these issues seem pretty minor to me.  It certainly gets my vote
to push without these additional features (especially considering the
security benefits).

I just have one comment below:

 diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
 index ba3ef275ec5e..9fb84b57b030 100644
 --- a/emacs/notmuch-mua.el
 +++ b/emacs/notmuch-mua.el
 @@ -224,7 +233,10 @@ list.
   (set-mark (point))
   (goto-char start)
   ;; Quote the original message according to the user's configured style.
 - (message-cite-original
 + (message-cite-original)))
 +
 +;; Sign and/or encrypt replies to signed and/or encrypted messages.
 +(notmuch-mua-reply-crypto (plist-get original :body)))

Maybe we should check to see if crypto processing is activated before
adding this additional crypto handling.  I would have guessed we might
want something like this instead:

(when notmuch-show-process-crypto
  (notmuch-mua-reply-crypto (plist-get original :body

However, for some reason I can't get this to work.  It looks like
notmuch-show-process-crypto keeps evaluating to false in this context,
regardless of whether crypto processing has been engaged.  I'm unclear
why.  Anyone know see how notmuch-show-process-crypto would evaluate to
false here, even when it evaluates to true earlier in the same
notmuch-mua-reply call?

jamie.


pgpYlHtwP2h2E.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: process crypto for reply only when specified

2014-04-07 Thread Jameson Graef Rollins
This is a tweak to patch emacs: sign/encrypt replies to
signed/encrypted messages to only add mml crypto flags for replys
when crypto processing has been activated.

---

Thanks to mjw1009 for implementation suggestions.

Jani, you might consider squashing this with your original for a v2.
Pushing them separately seems fine to me as well.

jamie.

---
 emacs/notmuch-mua.el | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 9fb84b5..bf6253f 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -160,9 +160,10 @@ list.
 
 (defun notmuch-mua-reply (query-string optional sender reply-all)
   (let ((args '(reply --format=sexp --format-version=1))
+   (process-crypto notmuch-show-process-crypto)
reply
original)
-(when notmuch-show-process-crypto
+(when process-crypto
   (setq args (append args '(--decrypt
 
 (if reply-all
@@ -236,7 +237,8 @@ list.
(message-cite-original)))
 
 ;; Sign and/or encrypt replies to signed and/or encrypted messages.
-(notmuch-mua-reply-crypto (plist-get original :body)))
+(when process-crypto
+  (notmuch-mua-reply-crypto (plist-get original :body
 
   ;; Push mark right before signature, if any.
   (message-goto-signature)
-- 
1.9.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Feature suggestion. Indexing encrypted mail?

2014-04-07 Thread Jameson Graef Rollins
On Mon, Apr 07 2014, john.wy...@gmx.de wrote:
 confess i haven't been following closely), it wouldn't be much extra
 effort for someone to implement a filter that strips encryption from the
 message.  (this might still have the problem mentioned above about also
 stripping PGP/MIME signatures, but the signatures and the decrypted
 message itself would remain intact so they could be shown directly by
 notmuch show without trouble).

 I don't understand that. :-(
 This sounds as if the view of the message is not generated from the
 mail storage. Isn't the purpose of the index to find the appropriate
 message file and everything else is generated from that file?

I think that's exactly what Daniel is saying: what's viewed comes from
the message directly, and not from the db.

jamie.


pgpk6FOrvud5H.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Feature suggestion. Indexing encrypted mail?

2014-04-07 Thread Jameson Graef Rollins
On Mon, Apr 07 2014, Jeremy Nickurak not-m...@trk.nickurak.ca wrote:
 Nonetheess, if you can tell from the index that a given message contains
 the words hotel wine wife secret and rendezvous, you can infer a
 *lot* about the contents of encrypted contents of the message.

Of course.  Given that the content of the message will be stored
unencrypted in the db, indexing encrypted messages is potentially a foot
gun.  If we were to enable a feature like this, it would definitely be a
user-beware situation.  I don't see any way around that.

jamie.


pgpNh3TSxkTus.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH v2] cli: add a tool for starting new message in the emacs ui

2014-04-06 Thread Jameson Graef Rollins
On Sun, Apr 06 2014, Jani Nikula  wrote:
> Add a tool to start composing an email in the Notmuch Emacs UI with
> the specified subject, recipients, and message body.

Hey, Jani.  You might be interested in checking out a patch I submitted
a while back to support "mailto:; urls in notmuch-mua.el:

id:1327865624-7673-1-git-send-email-jrollins at finestructure.net

That, combined with your new ui interface would make handling mailto:
urls in say browsers very convenient, e.g.:

  ELISP="(notmuch-mua-mailto \"$URL\")"

for:

  notmuch-emacs-mua mailto:foo at example.com

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 



Feature suggestion. Indexing encrypted mail?

2014-04-05 Thread Jameson Graef Rollins
On Sat, Apr 05 2014, David Bremner  wrote:
> john.wyzer at gmx.de writes:
>
>> Would it be possible to add the configurable option to also decrypt
>> encrypted messages on the fly while indexing to make them searchable,
>> too?
>>
>> That would be really great for people that consider gnupg  mainly an
>> encryption for transport or have their complete hard drive encrypted...
>
> As far I understand an attacker could reconstruct the message from the
> index, so one question is whether the extra complexity in notmuch is
> worth the minimal extra security over decrypting on delivery and storing
> plaintext on the (presumably encrypted) disk. Of course decrypting on
> delivery may be inconvenient (or impossible). I have CCed the two people
> who have implemented most of the crypto related stuff in notmuch so they
> can comment.

Indexing encrypted email is a bit of a foot-gun, since, as David
mentions, it is apparently possible to reconstruct encrypted messages


  1   2   3   4   5   6   7   8   9   10   >