Re: [PATCH 12/20] cli/show: add information about which headers were protected

[David Bremner]

Daniel Kahn Gillmor  writes:

> --- a/devel/schemata
> +++ b/devel/schemata
> @@ -89,9 +89,15 @@ crypto = {
>status:  sigstatus,
># was the set of signatures described under encrypted 
> cover?
>encrypted:   bool,
> +  # which of the headers is covered by sigstatus?
> +  headers: [header_name*]
>  },
>  decrypted?: {
>status: msgdecstatus,
> +  # map encrypted headers that differed from the outside 
> headers.
> +  # the value of each item in the map is what that field 
> showed externally
> +  # (maybe null if it was not present in the external 
> headers).
> +  masked-headers:  { header_name: string|null,*}
>  }
>  }

I'm not completely happy with either the update here to the schema file
without a version number bump or with the alternative of the output not
quite matching the schema. On the whole I think I'd prefer that the
schema update be done atomically, either before all the related changes
or after them.

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

Re: [PATCH 11/20] cli/show: emit payload subject instead of outside subject

[David Bremner]

Daniel Kahn Gillmor  writes:

>  
>  sp->map_key (sp, "Subject");
> -sp->string (sp, g_mime_message_get_subject (message));
> +if (msg_crypto && msg_crypto->payload_subject) {
> + sp->string (sp, msg_crypto->payload_subject);
> +} else
> + sp->string (sp, g_mime_message_get_subject (message));

This is not really an issue with your patch per se, but do we actually
use this code for anything other than top level messages? I'm wondering
because of my experiments with storing message-document level headers
[1]. It seems difficult to look at the database when things are done at
the GMime level like this.

[1]  id:20180623014247.17834-1-da...@tethera.net

>  test_json_nodes <<<"$output" \
>  'crypto:[0][0][0]["crypto"]={"decrypted": {"status": 
> "full"}}' \
>  'subject:[0][0][0]["headers"]["Subject"]="This is a 
> protected header"'
>  
> -

naughty white space change. Time to update your pre-commit hook?

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

Re: [PATCH 04/20] util/crypto: _notmuch_message_crypto: tracks message-wide crypto state

[Daniel Kahn Gillmor]

On Fri 2018-06-15 07:16:05 -0300, David Bremner wrote:
> Daniel Kahn Gillmor  writes:
>
>> +notmuch_status_t
>> +_notmuch_message_crypto_set_sig_list (_notmuch_message_crypto_t 
>> *msg_crypto, GMimeSignatureList *sigs)
>> +{
>
> It's a bit confusing that nothing in this API/patch seems to use the
> sig_list stored by this function

i've updated the commit message to explain that we will use it later :)

>> +void
>> +_notmuch_message_crypto_cleanup (_notmuch_message_crypto_t *msg_crypto)
>> +{
>> +if (!msg_crypto)
>> +return;
>> +if (msg_crypto->sig_list)
>> +g_object_unref (msg_crypto->sig_list);
>> +}
>
> It _looks_ like you're planning on manually calling
> _notmuch_message_crypto_cleanup.  In order to allow for hierarchical
> de-allocation (i.e. non-explicit de-allocation, we need to call
> talloc_set_destructor. There's a few examples in the the existing code.

ah, good call.  in the revised version, that should be taken care of.
hopefully i even did it right :) thanks for the heads-up!

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

Re: 'notmuch search thread:<>' lists multiple threads

[Naveen N. Rao]

Hi David,

David Bremner wrote:

"Naveen N. Rao"  writes:

In my case, I seem to be having the In-Reply-To headers. I end up with 
two files per message: one from my inbox and one from the gmane archive 
that I pull in. All the messages from the gmane archive seem to have a 
re-written 'In-Reply-To' header, but 'Message-Id' and 'References' are 
the same.


That sounds like essentially the same issue, due to the fact that
notmuch prefers In-Reply-To when choosing a parent for a message.

Currently the database is correct (or at least one not-crazy definition
of correct): all of the reference and in-reply-to terms are attached to
the message document in the database. On the other hand, the in memory
data structures currently assume that In-reply-to is a unique value
(with ties broken at indexing time).

It might be that the solution is to read a list of in-reply-to values
and use all of them in threading. At a quick glance, that looks doable;
I'm just not sure about unintended consequences.


Were you able to look into this again?
Using a list of in-reply-to values sounds like a good option, though I 
clearly have no idea about other consequences from that. If you have a 
patch, I can help test that.


Thanks,
Naveen


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