Re: Handle PKCS#7 S/MIME messages
On Thu, Apr 30 2020, Daniel Kahn Gillmor wrote:
> This series applies after the "Add tests for S/MIME PKCS#7 messages"
> series, which was introduced in
> id:20200428185723.660184-1-...@fifthhorseman.net
>
> With this series applied, notmuch handles standard PKCS#7 S/MIME
> messages (using GnuPG's gpgsm as a backend, as mediated by GMime's use
> of GPGME) as well as it handles PGP/MIME messages.
>
> In addition to showing and replying to these messages, the series
> covers indexing the cleartext of encrypted messages, and understanding
> protected headers.
I did not see anything suspicious in code, but
I got these test failures:
in ubuntu 19.10 native environment, and
in debian 10 (podman) container running in fedora 31 system
T355-smime: Testing S/MIME signature verification and decryption
FAIL Verify signature on PKCS#7 SignedData message
crypto: value not equal: data[0][0][0]["crypto"]["signed"]["status"][0] =
{'status': 'good',
'fingerprint': '702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB',
'created': 1574813489,
'expires': 2611032858} !=
{'created': 1574813489,
'expires': 2611032858,
'fingerprint': '702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB',
'userid': 'CN=Alice Lovelace',
'status': 'good'}
T356-protected-headers: Testing Message decryption with protected headers
FAIL verify signed PKCS#7 subject (multipart-signed)
sig_uid: object not found:
data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
FAIL verify signed PKCS#7 subject (onepart-signed)
sig_uid: object not found:
data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
FAIL confirm signed and encrypted PKCS#7 subject (sign+enc)
sig_uid: object not found:
data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
FAIL confirm signed and encrypted PKCS#7 subject (sign+enc+legacy-disp)
sig_uid: object not found:
data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>
> --dkg
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
notmuch and mailing lists
Hello, I was wondering whether anyone who previously read mailing lists via NNTP has stopped doing this after starting to use notmuch. I've not yet used NNTP to read mailing lists myself, but I think there are limitations to the way I currently read lists, and was wondering whether it is worth exploring the NNTP approach, or trying to come up with notmuch-based workflow improvements. Kindly CC me on replies. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Add support for `--limit=N` to `notmuch show`
In a previous email (about `thread:...` field in JSON output of
`notmuch show`), I described one of my use-cases for notmuch.
Now extending upon that, if one would to implement an email client
that provides the user with search, there are two approaches:
* use `notmuch search -- {query}` and based on that output display a
thread list like GMail does;
* use `notmuch show -- {query}` and based on that display a page with
all emails that matched, grouping them by thread; (I prefer this
variant, as it gives me a quicker glance if I search for something
specific;)
Now the problem with `notmuch show` is that if I give it a too "broad"
query like `*` it will chew a lot of CPU and RAM (and in my case
eventually crash).
`notmuch search` does have a `--limit=N` argument that limits the
search output only to the first `N` items. My feature request is to
add such a flag also to `notmuch show` that should:
* limit the number of threads in all cases except `--format=raw`;
* not be allowed in case of `--format=raw` or `--part=P`;
As a work-around I could use `notmuch search --output=threads
--limit={limit} -- {query}`, then take those thread ID's and issue an
`notmuch show -- thread:... thread:...`. But this has the following
problems:
* it requires two `notmuch` CLI calls;
* and most importantly it renders the `--entire-thread=false` feature
useless; (as not the entire threads are matched by `notmuch show` as
opposed only to those matched by `notmuch search`;)
Thanks,
Ciprian.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Add support for `thread` field in `notmuch show`
On Fri, May 1, 2020 at 3:09 PM David Bremner wrote:
> Ciprian Dorin Craciun writes:
> > I know that one can use `thread:{id:MESSAGE_ID}` to achieve the same
> > result, however:
> > * it is somewhat cumbersome for the integrator;
>
> Out of curiousity, what is harder about it? In both cases you have to
> extra one value from the JSON.
It is cumbersome because:
* for once, now you need for each email to run a new `notmuch search`
instance to get that email's thread id; this is very sub-optimal when
you have more than a handful emails;
* secondly, it adds more code to the client;
To understand my use-case: I currently intend to use `notmuch show
--format=json` to search my emails, and based on that to generate a
nice HTML page, displaying all found emails. Now I want to include in
each email's section a link to only display the thread.
In order to do that, I either have to generate (by usin the technique
described above) the `thread:...` for each of those emails, which in
turn generates one CLI call per email. (And 99% of the time perhaps I
don't even click the thread.) (Another option would be to use the
`thread:{id:...}` for that link, but I find this quite a hack.)
> > * having the thread identifier explicitly, could be used as a key in a
> > cache, or other internal lookups;
> >
> > In fact the only way one can extract the thread identifier via the
> > `notmuch` CLI is to use `notmuch search --output=threads --
> > id:MESSAGE_ID`
>
> Offhand I have no strong objection to someone (who is not me) adding
> this. I think it's important to be aware that thread id's are ephemeral,
> and subject to change e.g. if the database is re-built from
> scratch.
I understand that `thread:...` is tied to a particular database, but
that shouldn't be an issue, as people don't regenerate often their
databases, and the caches are usually short-lived.
This weekend I'll try to take a stab at adding this to `notmuch`.
Ciprian.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Add support for `thread` field in `notmuch show`
David Bremner writes: > Offhand I have no strong objection to someone (who is not me) adding > this. I think it's important to be aware that thread id's are ephemeral, > and subject to change e.g. if the database is re-built from > scratch. I guess a more common/interesting case is that two threads can merge if new is indexed. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Add support for `thread` field in `notmuch show`
Ciprian Dorin Craciun writes:
> I know that one can use `thread:{id:MESSAGE_ID}` to achieve the same
> result, however:
> * it is somewhat cumbersome for the integrator;
Out of curiousity, what is harder about it? In both cases you have to
extra one value from the JSON.
> * having the thread identifier explicitly, could be used as a key in a
> cache, or other internal lookups;
>
> In fact the only way one can extract the thread identifier via the
> `notmuch` CLI is to use `notmuch search --output=threads --
> id:MESSAGE_ID`
Offhand I have no strong objection to someone (who is not me) adding
this. I think it's important to be aware that thread id's are ephemeral,
and subject to change e.g. if the database is re-built from
scratch.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Any updates on the `List-Id` indexing feature?
Ciprian Dorin Craciun writes: > On Wed, Apr 29, 2020 at 8:08 PM David Bremner wrote: >> > I've also read the FAQ: >> > * https://notmuchmail.org/faq/#index8h2 >> >> Oops, that needs to be updated. >> >> It is implemented. See notmuch-config(1), under "index.header" > > > That's perfect. However the `search-terms` man pages doesn't say how > it should be used. Yes, it's a bit cryptic. There is a reference to user defined prefixes, but that's it. > > Should I gather (from the `config` manpage) that these "prefixes" > should always start with a upper-case letter, as in: `notmuch search > -- 'List:some-id'`? Yes, that sounds about right. In practice other things work as well, but that depends on the Xapian tokenizer, which we don't really control, so users should probably stick to capital letters to avoid suprises. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
