Daniel Kahn Gillmor writes:
>>
>> -sphinx-texinfo: .texi.stamp
>> +sphinx-texinfo: $(DOCBUILDDIR)/.texi.stamp
>
> I think this final change (to the sphinx-texinfo target) belongs in the
> previous patchset.
>
> Otherwise, this series looks good to me, using your followup two-part
> replacement
Örjan Ekeberg writes:
> Added the type 'regexp and group 'notmuch-send as properties to the
> customizable variable notmuch-mua-attachment-regexp.
pushed,
d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notm
Doan Tran Cong Danh writes:
> From notmuch 0.28, notmuch support relative database path in
> notmuch-config(1), but python binding haven't taught this yet.
>
> afew denied to work with a perfectly fine notmuch-config due to this.
pushed to master
d
_
Daniel Kahn Gillmor writes:
> If a test has added a GnuPG homedir, it may well want to know the
> fingerprint. This saves us from having to redefine this magic string
> in multiple places when more tests evenutally use the GnuPG homedir.
pushed, with typo in commit message fixed
___
On Sat 2019-04-20 13:02:57 -0400, Daniel Kahn Gillmor wrote:
> Unsigned encrypted mail shows up with a weird empty signature list.
> If we successfully decrypted and there was no signature in it, we
> should just not show a sigstatus at all.
Just a ping on this -- i don't think it should be partic
This allows MUAs that don't want to think about per-mime-part
cryptographic status to have a simple high-level overview of the
message's cryptographic state.
Sensibly structured encrypted and/or signed messages will work fine
with this. The only requirement for the simplest encryption + signing
i
The mime node context (a per-message context) gains a cryptographic
status object, and the mime_node_t object itself can return a view on
that status to an interested party.
The status is not yet populated, and for now we can keep that view
read-only, so that it can only be populated/modified duri
Deliberately populate the message's cryptographic status while walking
the MIME tree from the CLI.
Note that the additional numchild argument added to _mime_node_create
is a passthrough needed to be able to adequately populate the crypto
state object.
---
mime-node.c | 24 +---
E-mail encryption and signatures reported by notmuch are at the MIME
part level. This makes sense in the dirty details, but for users we
need to have a per-message conception of the cryptographic state of
the e-mail. (see
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html for more
discus
E-mail structures are potentially arbitrarily complicated.
Cryptographic protection standards like S/MIME and OpenPGP or PGP/MIME
are often applicable to some elements of some messages.
Last year's "E-Fail" attacks made it clear that trying to provide
normal users with cryptographic protections on
The typical use case for gpg is that if you control a secret key, you
mark it with "ultimate" ownertrust.
This bizarrely opaque --import-ownertrust mechanism is GnuPG's
standard mechanism to set up ultimate ownertrust (the ":6" means
"ultimate", for whatever reason).
---
test/test-lib.sh | 1 +
1
On Wed 2019-04-24 18:06:44 -0400, Daniel Kahn Gillmor wrote:
> The typical use case for gpg is that if you control a secret key, you
> mark it with "ultimate" ownertrust.
>
> This bizarrely opaque --import-ownertrust mechanism is GnuPG's
> standard mechanism to set up ultimate ownertrust (the ":6"
The typical use case for gpg is that if you control a secret key, you
mark it with "ultimate" ownertrust.
This bizarrely opaque --import-ownertrust mechanism is GnuPG's
standard mechanism to set up ultimate ownertrust (the ":6" means
"ultimate", for whatever reason).
---
test/test-lib.sh | 1 +
1
The typical use case for gpg is that if you control a secret key, you
mark it with "ultimate" ownertrust.
This bizarrely opaque --import-ownertrust mechanism is GnuPG's
standard mechanism to set up ultimate ownertrust (the ":6" means
"ultimate", for whatever reason).
---
test/test-lib.sh | 1 +
1
14 matches
Mail list logo