On Mon 2020-04-27 22:21:36 +0300, Ciprian Dorin Craciun wrote:
> On Mon, Apr 27, 2020 at 9:21 PM Tomi Ollila wrote:
>>> [dkg wrote:]
>>> release, remove the suggestion to use a whitespace separator from the
>>> documentation, and eventually phase it out entirely in some future
>>> release.
>>
>> A
Daniel Kahn Gillmor writes:
> This CA is useful for test suites and the like, but is not an
> actually-secure CA, because its secret key material is also published.
>
> I plan to use it for its intended purpose in the notmuch test suite.
>
> It was copied from this Internet Draft:
>
> https://www
The documentation for message mode clearly states that EasyPG (which
uses GnuPG) is the default and recommended way to use S/MIME with
mml-secure:
[0]
https://www.gnu.org/software/emacs/manual/html_node/message/Using-S_002fMIME.html
To ensure that this mode works, we just need to import the secr
This CA is useful for test suites and the like, but is not an
actually-secure CA, because its secret key material is also published.
I plan to use it for its intended purpose in the notmuch test suite.
It was copied from this Internet Draft:
https://www.ietf.org/id/draft-dkg-lamps-samples-01.htm
Signed-off-by: Daniel Kahn Gillmor
---
test/test-lib.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 1ffedb25..31f37ed7 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -132,13 +132,13 @@ add_gnupg_home ()
add_gpgsm_home
Recognize the protected subject for S/MIME example protected header
messages.
Signed-off-by: Daniel Kahn Gillmor
---
test/T356-protected-headers.sh | 38 +++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/test/T356-protected-headers.sh b/test/T356-p
GPGME has a strange failure mode when it is in offline mode, and/or
when certificates don't have any CRLs: in particular, it refuses to
accept the validity of any certificate other than a "root" cert.
This can be worked around by setting the `disable-crl-checks`
configuration variable for gpgsm.
These tests describe some simple behavior we would expect to work if
we were to correctly index the cleartext of encrypted S/MIME messages
(PKCS#7 envelopedData).
Of course, they don't currently pass, so we mark them known-broken.
Signed-off-by: Daniel Kahn Gillmor
---
test/T355-smime.sh | 22 +
Without this fix, we couldn't run both add_gnupg_home and
add_gpgsm_home in the same test script.
Signed-off-by: Daniel Kahn Gillmor
---
test/test-lib.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index ac1b9315..d9997b27 10064
This test does exactly what it says on the tin. It expects JSON data
to be parseable by Python, at least.
Signed-off-by: Daniel Kahn Gillmor
---
test/test-lib.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index dd7fdfaa..6f47994e 100644
--- a/t
Add a simple S/MIME SignedData message, taken from an upcoming draft
of
https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/
RFC 8551 describes a SignedData, a one-part clearsigned object that is
more resistant to common patterns of MTA message munging than
multipart/signed (b
No functional change.
We no longer need to identify the key and cert to mml-mode when
sending an S/MIME message, so making a copy of key+cert.pem to
test_suite.pem is superfluous. Get rid of the extra file.
Signed-off-by: Daniel Kahn Gillmor
---
test/T355-smime.sh | 6 ++
1 file changed, 2
These sample messages are taken directly from the Protected Headers
draft:
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
Note that this commit doesn't strictly pass the common git pre-commit
hook due to introducing some trailing whitespace. That's just the
nature of the
GnuPG's gpgsm, like gpg, should always be used with --batch when it is
invoked in a non-interactive environment.
Signed-off-by: Daniel Kahn Gillmor
---
test/test-lib.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 6a62b5c1..d4f
This is taken from the same Internet Draft that test/smime/ca.crt
comes from. See that draft for more details.
https://www.ietf.org/id/draft-dkg-lamps-samples-02.html#name-pkcs12-object-for-bob
We don't use it yet, but it will be used to decrypt other messages in
the test suite.
Note that we inc
S/MIME messages that use PKCS#7 are not currently well-handled by
notmuch.
This series introduces a set of tests that cover such messages, most
of which are initially broken. A future (shorter) series will resolve
these tests.
Some S/MIME messages *are* handled correctly by notmuch already: in
p
This allows us to test S/MIME messages in other tests.
Signed-off-by: Daniel Kahn Gillmor
---
test/T355-smime.sh | 13 -
test/test-lib.sh | 13 +
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/test/T355-smime.sh b/test/T355-smime.sh
index 11a4d6cd..84b
When consuming a signed+encrypted S/MIME message generated by emacs,
we expect to see the same cryptographic properties for the message as
a whole. This is not done correctly yet, so the test is marked as
known broken.
Signed-off-by: Daniel Kahn Gillmor
---
test/T355-smime.sh | 9 +
1 f
David Bremner writes:
> It turns out the behaviour of inline functions in C header files is
> not a good idea, and can cause linking problems if the compiler
> decides not to inline them. In principle this is solvable by using a
> "static inline" declaration, but this potentially makes a copy in
19 matches
Mail list logo
