[PATCH] emacs: fix notmuch-show-update-tags to support duplicate files
With duplicate files, the headerlines of messages in notmuch-show
buffer contains (initially) 1/n at the end of line.
Update the regexp used to search and replace tag changes to
match the current line -- drop unnecessary capturing of the
(tags), but capture the duplicates indicator.
Update the headerline pretty much like notmuch-show-insert-headerline
does, like the changes introduced mostly in commit 5ea5a5557d9a.
---
Is this getting too complex (well, we may have other stuff with
similar complexity there ;/) ?
Is there any better solutions ?
emacs/notmuch-show.el | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index ec998ede..0527c3a5 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -453,13 +453,20 @@ (defun notmuch-show-update-tags (tags)
"Update the displayed tags of the current message."
(save-excursion
(goto-char (notmuch-show-message-top))
-(when (re-search-forward "(\\([^()]*\\))$" (line-end-position) t)
- (let ((inhibit-read-only t))
- (replace-match (concat "("
- (notmuch-tag-format-tags
- tags
- (notmuch-show-get-prop :orig-tags))
- ")"))
+(when (re-search-forward "([^()]*) *\\([^()]*\\)$" (line-end-position) t)
+ (let ((inhibit-read-only t)
+ (tags-str (notmuch-tag-format-tags
+ tags (notmuch-show-get-prop :orig-tags)))
+ (txt (match-string 1)))
+ (replace-match (concat "(" tags-str ")"
+ (and (string-lessp "" txt)
+ (notmuch-show-spaces-n
+(max 0 (- (window-width)
+ (- (match-beginning 0)
+ (notmuch-show-message-top))
+ (length tags-str)
+ (length txt) 3
+ txt))
(defun notmuch-clean-address (address)
"Try to clean a single email ADDRESS for display. Return a cons
--
2.30.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] test: replace aging OpenPGP key used in the test suite
Am Do., 22. Sept. 2022 um 12:14 Uhr schrieb Justus Winter : > > Michael J Gruber writes: > > > Am Do., 22. Sept. 2022 um 10:47 Uhr schrieb Justus Winter > > : > >> > >> This replaces the old OpenPGPv4 key that is used in the test suite > >> with a more modern OpenPGPv4 key. All cryptographic artifacts in the > > > > Both v4? Only one key file is named v4. > > Yes, the old key was also a v4 key. In this context, OpenPGP v4 was > standardized in 1998. So when the old key was created, v4 was and has > been for a long time *the* version of OpenPGP. It didn't seem to make > sense to specify the version. > > Now, v5 is around the corner, so it makes sense to make the version > explicit. That'll help when we introduce v5 artifacts. > > >> @@ -6,7 +6,7 @@ Message-ID: > >> MIME-Version: 1.0 > >> Content-Type: multipart/signed; boundary="=-=-="; > >> protocol="application/pgp-signature"; > >> - micalg=pgp-sha512 > >> + micalg=pgp-sha256 > > > > You are downgrading the hash algo here and in the other regenerated > > signatures. This is not wrong per-se, I'm just wondering whether it is > > intentional (or forced by the standard) when the aim of this series is > > future-proofing. sha256 is the current "replacement" for sha1, which > > means it's the one which will be replaced next ;) > > Yes I am. It happened when I re-created the signature. Recreating the > artifacts was somewhat tedious (I'm working on tooling for that, but the > changes to notmuch I created by hand), so I opted for the easiest fix. > > WRT future proofing: SHA256 is the only mandatory to implement hash > algorithm in v5 OpenPGP. Therefore, when SHA256 falls, we will > hopefully have specified v6 OpenPGP which moved to a new MTI hash > algorithm. So, for a v4 OpenPGP artifact, SHA256 is and will forever be > more than appropriate. > > Best, > Justus Thanks for clarifying, sounds good to me! Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] test: replace aging OpenPGP key used in the test suite
Michael J Gruber writes: > Am Do., 22. Sept. 2022 um 10:47 Uhr schrieb Justus Winter > : >> >> This replaces the old OpenPGPv4 key that is used in the test suite >> with a more modern OpenPGPv4 key. All cryptographic artifacts in the > > Both v4? Only one key file is named v4. Yes, the old key was also a v4 key. In this context, OpenPGP v4 was standardized in 1998. So when the old key was created, v4 was and has been for a long time *the* version of OpenPGP. It didn't seem to make sense to specify the version. Now, v5 is around the corner, so it makes sense to make the version explicit. That'll help when we introduce v5 artifacts. >> @@ -6,7 +6,7 @@ Message-ID: >> MIME-Version: 1.0 >> Content-Type: multipart/signed; boundary="=-=-="; >> protocol="application/pgp-signature"; >> - micalg=pgp-sha512 >> + micalg=pgp-sha256 > > You are downgrading the hash algo here and in the other regenerated > signatures. This is not wrong per-se, I'm just wondering whether it is > intentional (or forced by the standard) when the aim of this series is > future-proofing. sha256 is the current "replacement" for sha1, which > means it's the one which will be replaced next ;) Yes I am. It happened when I re-created the signature. Recreating the artifacts was somewhat tedious (I'm working on tooling for that, but the changes to notmuch I created by hand), so I opted for the easiest fix. WRT future proofing: SHA256 is the only mandatory to implement hash algorithm in v5 OpenPGP. Therefore, when SHA256 falls, we will hopefully have specified v6 OpenPGP which moved to a new MTI hash algorithm. So, for a v4 OpenPGP artifact, SHA256 is and will forever be more than appropriate. Best, Justus signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Possible bug: incorrect processing of multipart, base64-encoded subject lines.
Hi all, Notmuch doesn't parse correctly some Subject lines consisting of multiple base64-encoded snippets. As an example, this is the raw subject line of an e-mail from Amazon: Subject: =?UTF-8?B?TGl2cmFpc29uIHByw6l2dWUgcG91ciBhdWpvdXJk4oCZaHU=?= =?UTF-8?B?aTogUkVTVFJBUCBTYWRkbGUgQmFnIFNhY2NvY2hlLi4u?= Notmuch displays the subject as only the decoded contents of the first fragment (or first line), "Livraison prévue pour aujourd’hu", fully ignoring the second base64 fragment, "i: RESTRAP Saddle Bag Saccoche...". The complete subject line should thus read: > Livraison prévue pour aujourd’hui: RESTRAP Saddle Bag Saccoche... Regards, Thibault ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] test: replace aging OpenPGP key used in the test suite
Am Do., 22. Sept. 2022 um 10:47 Uhr schrieb Justus Winter : > > This replaces the old OpenPGPv4 key that is used in the test suite > with a more modern OpenPGPv4 key. All cryptographic artifacts in the Both v4? Only one key file is named v4. > @@ -6,7 +6,7 @@ Message-ID: > MIME-Version: 1.0 > Content-Type: multipart/signed; boundary="=-=-="; > protocol="application/pgp-signature"; > - micalg=pgp-sha512 > + micalg=pgp-sha256 You are downgrading the hash algo here and in the other regenerated signatures. This is not wrong per-se, I'm just wondering whether it is intentional (or forced by the standard) when the aim of this series is future-proofing. sha256 is the current "replacement" for sha1, which means it's the one which will be replaced next ;) Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] test: replace aging OpenPGP key used in the test suite
This replaces the old OpenPGPv4 key that is used in the test suite
with a more modern OpenPGPv4 key. All cryptographic artifacts in the
test suite are updated accordingly.
Having old cryptographic artifacts in the test suite presents a
problem once the old algorithms are rejected by contemporary
implementations.
For reference, this is the old key.
sec rsa1024 2011-02-05 [SC]
5AEAB11F5E33DCE875DDB75B6D92612D94E46381
uid [ unknown] Notmuch Test Suite
(INSECURE!)
ssb rsa1024 2011-02-05 [E]
And this is the new key. Note that is has the same shape, but uses
Ed25519 and Cv25519 instead of 1024-bit RSA.
sec ed25519 2022-09-07 [SC]
9A3AFE6C60065A148FD4B58A7E6ABE924645CC60
uid [ultimate] Notmuch Test Suite (INSECURE!)
ssb cv25519 2022-09-07 [E]
---
configure | 8 +--
test/T356-protected-headers.sh| 8 +--
test/corpora/crypto/basic-encrypted.eml | 13 +++--
.../crypto/encrypted-rfc822-attachment| 49 +--
test/corpora/crypto/encrypted-signed.eml | 27 +-
test/corpora/mangling/mixed-up.eml| 14 ++
...le-wrapped-with-phony-protected-header.eml | 37 +++---
...pted-message-with-forwarded-attachment.eml | 29 ++-
.../encrypted-signed-not-masked.eml | 25 +-
.../protected-headers/encrypted-signed.eml| 25 +-
.../misplaced-protected-header.eml| 36 --
.../nested-rfc822-message.eml | 23 -
.../no-protected-header-attribute.eml | 16 +++---
.../phony-protected-header-bad-encryption.eml | 13 ++---
.../protected-headers/protected-header.eml| 15 +++---
.../protected-with-legacy-display.eml | 38 +++---
.../signed-protected-header.eml | 11 ++---
.../protected-headers/simple-signed-mail.eml | 11 ++---
.../subjectless-protected-header.eml | 15 +++---
.../wrapped-protected-header.eml | 15 +++---
test/gnupg-secret-key.NOTE| 9
test/gnupg-secret-key.asc | 34 -
test/openpgp4-secret-key.asc | 15 ++
test/openpgp4-secret-key.asc.NOTE | 5 ++
test/test-lib.sh | 6 +--
25 files changed, 236 insertions(+), 261 deletions(-)
delete mode 100644 test/gnupg-secret-key.NOTE
delete mode 100644 test/gnupg-secret-key.asc
create mode 100644 test/openpgp4-secret-key.asc
create mode 100644 test/openpgp4-secret-key.asc.NOTE
diff --git a/configure b/configure
index 5247e05a..be69b34d 100755
--- a/configure
+++ b/configure
@@ -525,9 +525,9 @@ EOF
printf 'No.\nCould not make tempdir for testing session-key support.\n'
errors=$((errors + 1))
elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c
${gmime_ldflags} -o _check_session_keys \
- && GNUPGHOME=${TEMP_GPG} gpg --batch --quiet --import <
"$srcdir"/test/gnupg-secret-key.asc \
+ && GNUPGHOME=${TEMP_GPG} gpg --batch --quiet --import <
"$srcdir"/test/openpgp4-secret-key.asc \
&& SESSION_KEY=$(GNUPGHOME=${TEMP_GPG} ./_check_session_keys) \
- && [ $SESSION_KEY =
9:0BACD64099D1468AB07C796F0C0AC4851948A658A15B34E803865E9FC635F2F5 ]
+ && [ $SESSION_KEY =
9:496A0B6D15A5E7BA762FB8E5FE6DEE421D4D9BBFCEAD1CDD0CCF636D07ADE621 ]
then
printf "OK.\n"
else
@@ -670,7 +670,7 @@ int main () {
body = GMIME_MULTIPART_ENCRYPTED(g_mime_message_get_mime_part
(g_mime_parser_construct_message (parser, NULL)));
if (body == NULL) return !!fprintf (stderr, "did not find a
multipart/encrypted message\n");
-output = g_mime_multipart_encrypted_decrypt (body, GMIME_DECRYPT_NONE,
"9:13607E4217515A70EC8DF9DBC16C5327B94577561D98AD1246FA8756659C7899", ,
);
+output = g_mime_multipart_encrypted_decrypt (body, GMIME_DECRYPT_NONE,
"9:9E1CDF53BBF794EA34F894B5B68E1E56FB015EA69F81D2A5EAB7F96C7B65783E", ,
);
if (error || output == NULL) return !! fprintf (stderr, "decrypt
failed\n");
sig_list = g_mime_decrypt_result_get_signatures (result);
@@ -691,7 +691,7 @@ EOF
printf 'No.\nCould not make tempdir for testing signature verification
when decrypting with session keys.\n'
errors=$((errors + 1))
elif ${CC} ${CFLAGS} ${gmime_cflags} _verify_sig_with_session_key.c
${gmime_ldflags} -o _verify_sig_with_session_key \
- && GNUPGHOME=${TEMP_GPG} gpg --batch --quiet --import <
"$srcdir"/test/gnupg-secret-key.asc \
+ && GNUPGHOME=${TEMP_GPG} gpg --batch --quiet --import <
"$srcdir"/test/openpgp4-secret-key.asc \
&& rm -f ${TEMP_GPG}/private-keys-v1.d/*.key
then
if GNUPGHOME=${TEMP_GPG} ./_verify_sig_with_session_key; then
diff --git a/test/T356-protected-headers.sh b/test/T356-protected-headers.sh
index f0aba14e..9f640331 100755
--- a/test/T356-protected-headers.sh
+++
