Re: T350-crypto T357-index-decryption: possible race condition?
Michael J Gruber writes: > > This one I can fix by serializing the test suite. For whatever reasons > it fails on newer Fedoras when looping through the different tree mode > tests (in parallel). > >> T350-crypto >> T357-index-decryption Because parallel testing only affects running different T* scripts in parallel, there must be some interaction between scripts (possibly just load-related timing issues). I will wait for the gnupg2 fix to propagate to Fedora before I investigate this. In the mean time, any hints to reproduce the failure would be welcome. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
Am Di., 30. Mai 2023 um 18:57 Uhr schrieb Michael J Gruber : > > Am Sa., 27. Mai 2023 um 14:31 Uhr schrieb David Bremner : > > > > Michael J Gruber writes: > > > > > > Are all gpg related tests emacs based? Either gpg or emacs is the red > > > herring here, or both ... > > > > The issue (at least on rawhide) seems to be the interaction between gpg > > and emacs > > > > https://dev.gnupg.org/T6481 > > That was the perfect hint, it seems! > On F39 failing: > T315-emacs-tagging This one I can fix by serializing the test suite. For whatever reasons it fails on newer Fedoras when looping through the different tree mode tests (in parallel). > T350-crypto > T357-index-decryption And these I can fix by using gnupg2 2.4.2 plus the upstream fix from the bug you pointed me to. Hooray! This means that with gnupg2 2.4.1 and 2.4.2 the test suite may fail (I guess emacs/gpg2 will be broken), unless your distro back-ports that fix. (I submitted it for Fedora.) Cheers, Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
Am Sa., 27. Mai 2023 um 14:31 Uhr schrieb David Bremner : > > Michael J Gruber writes: > > > > Are all gpg related tests emacs based? Either gpg or emacs is the red > > herring here, or both ... > > The issue (at least on rawhide) seems to be the interaction between gpg > and emacs > > https://dev.gnupg.org/T6481 > > A fix seems to be in progress. Do you have problems with gpg versions > other than 2.4.1? Yes. "It's complicated". Packages in Fedora copr buildroots: epel-8 gnupg2-2.2.20-3.el8_6 emacs-1:26.1-10.el8_8.2 epel-9 gnupg2-2.3.3-2.el9_0emacs-27.2-8.el9_2.1 fedora-37 gnupg2-2.3.8-1.fc37 emacs-1:28.2-3.fc37 fedora-38 gnupg2-2.4.0-3.fc38 emacs-28.2-4.fc38 fedora-39 gnupg2-2.4.1-1.fc39 emacs-28.2-6.fc39 (39=rawhide) RHEL/EPEL/ELN do not have "dtach" and thus skip the pertaining tests! (I'll try this with dtach one day.) notmuch master 0.37^62.gd155f29e (increased lisp timeout 120) (workee epel-8 epel-9) no workee fedora-37 fedora-38 fedora-39 notmuch 0.37 (standard lisp timeout 0.1) no workee fedora-39 everything else works notmuch 0.37 (increased lisp timeout 120) (workee epel-8 epel-9) no workee fedora-37 fedora-38 fedora-39 That is, on F37 and F38 failing: T315-emacs-tagging T460-emacs-tree On F39 failing: T315-emacs-tagging T350-crypto T357-index-decryption Now, I don't know how the timeouts interact and whether increasing the lisp timeout makes the overall timeout kick-in when it should not, of course. Maybe this produces "false fails" on F37 and F38 because you expect some lisp code to "hang" rather than return, and with the increased timeout the test gets killed instead? "Fixing" T350/T357 for the wrong reasons there, I guess. Based on that new hypothesis, I omitted the lisp timeout again, and sure enough, it's only fedora-39/rawhide failing again with T350/T357. So here is hoping that gnupg2-2.4.0 vs gnupg2-2.4.1 indeed makes the difference! Thanks, Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
Am Sa., 27. Mai 2023 um 14:59 Uhr schrieb David Bremner : > > David Bremner writes: > > > > > I'm not sure if this is the main issue, but in commit bf8aa34324cc91a > > that key was replaced by an ed255519 key > > 9A3AFE6C60065A148FD4B58A7E6ABE924645CC60 > > > > Did the fedora sources get out of synch somehow? > > > > d > > > > PS. Currently spinning up a Fedora Rawhide VM to see if I can duplicate > > the issue without the packaging infrastructure. > > Sorry, that's a silly question, that change is only in master so far. > Not silly at all. I'm seeing this with release (my local mock tests; Fedora koji) and master (Fedora copr). Both build an rpm from a complete tarball (as released resp. git-archive [via rpkg]), so the test suite is in-sync. Cheers, Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
David Bremner venit, vidit, dixit 2023-05-12 21:17:45: > Michael J Gruber writes: > > > oh well, attachments ... > > > > Can you encrypt to the key 6D92612D94E46381 interactively using an > approriately simplified version of that command? Took me a while, sorry. In that chroot: ``` sh-5.2# gpg --no-tty --import ./test/gnupg-secret-key.asc gpg: directory '/builddir/.gnupg' created gpg: /builddir/.gnupg/trustdb.gpg: trustdb created gpg: key 6D92612D94E46381: public key "Notmuch Test Suite (INSECURE!)" imported gpg: key 6D92612D94E46381: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 sh-5.2# echo supersecret | gpg -ear 6D92612D94E46381 gpg: C44D36DEAD54AB16: There is no assurance this key belongs to the named user sub rsa1024/C44D36DEAD54AB16 2011-02-05 Notmuch Test Suite (INSECURE!) Primary key fingerprint: 5AEA B11F 5E33 DCE8 75DD B75B 6D92 612D 94E4 6381 Subkey fingerprint: 8987 5467 478A A81C EBD5 2E7E C44D 36DE AD54 AB16 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) ``` Confirming that works, of course. Also, `gpg --always-trust -ear 6D92612D94E46381` works. ``` sh-5.2# printf '%s:6:\n' "$FINGERPRINT" | gpg --quiet --batch --no-tty --import-ownertrust gpg: inserting ownertrust of 6 ``` (like test-lib.sh does) and then encryption works - no questions asked. So, all that works. Are all gpg related tests emacs based? Either gpg or emacs is the red herring here, or both ... Unfortunately I have no clue about emacs/lisp and cannot dig further there. I just know it's 100% reproducible (for f39 mock on f38, all fedoras in copr, but not f38 mock on f38). Stomped. Cheers Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
David Bremner writes: > > I'm not sure if this is the main issue, but in commit bf8aa34324cc91a > that key was replaced by an ed255519 key > 9A3AFE6C60065A148FD4B58A7E6ABE924645CC60 > > Did the fedora sources get out of synch somehow? > > d > > PS. Currently spinning up a Fedora Rawhide VM to see if I can duplicate > the issue without the packaging infrastructure. Sorry, that's a silly question, that change is only in master so far. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
Michael J Gruber writes: > > Are all gpg related tests emacs based? Either gpg or emacs is the red > herring here, or both ... The issue (at least on rawhide) seems to be the interaction between gpg and emacs https://dev.gnupg.org/T6481 A fix seems to be in progress. Do you have problems with gpg versions other than 2.4.1? d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
Michael J Gruber writes: > David Bremner venit, vidit, dixit 2023-05-12 21:17:45: >> Michael J Gruber writes: >> >> > oh well, attachments ... >> > >> >> Can you encrypt to the key 6D92612D94E46381 interactively using an >> approriately simplified version of that command? > > Took me a while, sorry. In that chroot: > > ``` > sh-5.2# gpg --no-tty --import ./test/gnupg-secret-key.asc > gpg: directory '/builddir/.gnupg' created > gpg: /builddir/.gnupg/trustdb.gpg: trustdb created > gpg: key 6D92612D94E46381: public key "Notmuch Test Suite > (INSECURE!)" imported > gpg: key 6D92612D94E46381: secret key imported > gpg: Total number processed: 1 > gpg: imported: 1 > gpg: secret keys read: 1 > gpg: secret keys imported: 1 > > sh-5.2# echo supersecret | gpg -ear 6D92612D94E46381 > gpg: C44D36DEAD54AB16: There is no assurance this key belongs to the named > user > > sub rsa1024/C44D36DEAD54AB16 2011-02-05 Notmuch Test Suite > (INSECURE!) > Primary key fingerprint: 5AEA B11F 5E33 DCE8 75DD B75B 6D92 612D 94E4 6381 > Subkey fingerprint: 8987 5467 478A A81C EBD5 2E7E C44D 36DE AD54 AB16 > I'm not sure if this is the main issue, but in commit bf8aa34324cc91a that key was replaced by an ed255519 key 9A3AFE6C60065A148FD4B58A7E6ABE924645CC60 Did the fedora sources get out of synch somehow? d PS. Currently spinning up a Fedora Rawhide VM to see if I can duplicate the issue without the packaging infrastructure. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
[now from the subscribed address, sorry] David Bremner venit, vidit, dixit 2023-05-12 21:17:45: > Michael J Gruber writes: > > > oh well, attachments ... > > > > Can you encrypt to the key 6D92612D94E46381 interactively using an > approriately simplified version of that command? Took me a while, sorry. In that chroot: ``` sh-5.2# gpg --no-tty --import ./test/gnupg-secret-key.asc gpg: directory '/builddir/.gnupg' created gpg: /builddir/.gnupg/trustdb.gpg: trustdb created gpg: key 6D92612D94E46381: public key "Notmuch Test Suite (INSECURE!)" imported gpg: key 6D92612D94E46381: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 sh-5.2# echo supersecret | gpg -ear 6D92612D94E46381 gpg: C44D36DEAD54AB16: There is no assurance this key belongs to the named user sub rsa1024/C44D36DEAD54AB16 2011-02-05 Notmuch Test Suite (INSECURE!) Primary key fingerprint: 5AEA B11F 5E33 DCE8 75DD B75B 6D92 612D 94E4 6381 Subkey fingerprint: 8987 5467 478A A81C EBD5 2E7E C44D 36DE AD54 AB16 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) ``` Confirming that works, of course. Also, `gpg --always-trust -ear 6D92612D94E46381` works. ``` sh-5.2# printf '%s:6:\n' "$FINGERPRINT" | gpg --quiet --batch --no-tty --import-ownertrust gpg: inserting ownertrust of 6 ``` (like test-lib.sh does) and then encryption works - no questions asked. So, all that works. Are all gpg related tests emacs based? Either gpg or emacs is the red herring here, or both ... Unfortunately I have no clue about emacs/lisp and cannot dig further there. I just know it's 100% reproducible (for f39 mock on f38, all fedoras in copr, but not f38 mock on f38). Stomped. Cheers Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
Michael J Gruber writes: > oh well, attachments ... > Can you encrypt to the key 6D92612D94E46381 interactively using an approriately simplified version of that command? ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
oh well, attachments ... Am Fr., 12. Mai 2023 um 19:42 Uhr schrieb Michael J Gruber : > > Am Do., 11. Mai 2023 um 22:49 Uhr schrieb David Bremner : > > > > Michael J Gruber writes: > > > ... > > > T350-crypto: Testing PGP/MIME signature verification and decryption > ... > > > PASS signature verification with signer key unavailable > > > ``` > > > There the suite "hangs" for about 2 minutes, followed by > > > > This sounds suspiciously like "timeout" kicking in and killing a test > > that is taking too long. You can set NOTMUCH_TEST_TIMEOUT in the > > environment to some smaller/larger number to test this. > > Yes, when I set the timeout to 10m it hangs for 10min there, > > > The first subtest in T357 is also sending an encrypted message, so it > > Same after that one. I"ll attach "hang1" and "hang2" which are the > process lists during those hangs. Are those subtests the only ones (or > rather, the first subtests in these tests, and those tests the only > ones) sending encrypted messages? > > > looks like some bad interaction between gpg and emacs. Maybe you can try > > sending an encrypted message from emacs interactively in your chroot > > environment. > > > > 0) you will first need to run > > > >gpg --no-tty --import ./test/openpgp4-secret-key.asc > > > > this will create a keyring etc... in the chroot > > > > 1) You can use the script > > > > ./devel/try-emacs-mua -q > > > > > > 2) Copy the following into *scratch* and run with C-j after the last > > closing paren (this is just copied from the test suite internals) > > > > (let ((message-send-mail-function (lambda () t)) > > (mail-host-address "example.com")) > > (notmuch-mua-mail) > > (message-goto-to) > > (insert "test_su...@notmuchmail.org\nDate: 01 Jan 2000 12:00:00 -") > > (message-goto-subject) > > (insert "My Subject") > > (message-goto-body) > > (insert "a body") > > (mml-secure-message-encrypt) > > (let ((mml-secure-smime-sign-with-sender t) > > (mml-secure-openpgp-sign-with-sender t)) > > (notmuch-mua-send-and-exit))) > > > > You will probably need to answer "c" to create the sent-mail folder at > > the prompt. > > Thanks for these instructions. I don't get a prompt: Right after C-j, > that emacs session hangs indefinitely. There was also something about > "require nnheader" or something like that. "hang3" is the hanging > process, which seems to be the same as for the other runs. > > > > At least for T350 this is strange because several subtests ran and > > > passed! This indicates a race or a wrong signal trap. > > > > Note that those files are summaries created by test_done, so it's not > > that surprising that they are not there, since test_done is not reached > > in those files. > > I assumed the subtests would timeout separately and the test framework > would catch that. If the test script itself is killed then yes, that > outcome is expected :) hang1 Description: Binary data hang3 Description: Binary data hang2 Description: Binary data ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
Am Do., 11. Mai 2023 um 22:49 Uhr schrieb David Bremner : > > Michael J Gruber writes: > ... > > T350-crypto: Testing PGP/MIME signature verification and decryption ... > > PASS signature verification with signer key unavailable > > ``` > > There the suite "hangs" for about 2 minutes, followed by > > This sounds suspiciously like "timeout" kicking in and killing a test > that is taking too long. You can set NOTMUCH_TEST_TIMEOUT in the > environment to some smaller/larger number to test this. Yes, when I set the timeout to 10m it hangs for 10min there, > The first subtest in T357 is also sending an encrypted message, so it Same after that one. I"ll attach "hang1" and "hang2" which are the process lists during those hangs. Are those subtests the only ones (or rather, the first subtests in these tests, and those tests the only ones) sending encrypted messages? > looks like some bad interaction between gpg and emacs. Maybe you can try > sending an encrypted message from emacs interactively in your chroot > environment. > > 0) you will first need to run > >gpg --no-tty --import ./test/openpgp4-secret-key.asc > > this will create a keyring etc... in the chroot > > 1) You can use the script > > ./devel/try-emacs-mua -q > > > 2) Copy the following into *scratch* and run with C-j after the last > closing paren (this is just copied from the test suite internals) > > (let ((message-send-mail-function (lambda () t)) > (mail-host-address "example.com")) > (notmuch-mua-mail) > (message-goto-to) > (insert "test_su...@notmuchmail.org\nDate: 01 Jan 2000 12:00:00 -") > (message-goto-subject) > (insert "My Subject") > (message-goto-body) > (insert "a body") > (mml-secure-message-encrypt) > (let ((mml-secure-smime-sign-with-sender t) > (mml-secure-openpgp-sign-with-sender t)) > (notmuch-mua-send-and-exit))) > > You will probably need to answer "c" to create the sent-mail folder at > the prompt. Thanks for these instructions. I don't get a prompt: Right after C-j, that emacs session hangs indefinitely. There was also something about "require nnheader" or something like that. "hang3" is the hanging process, which seems to be the same as for the other runs. > > At least for T350 this is strange because several subtests ran and > > passed! This indicates a race or a wrong signal trap. > > Note that those files are summaries created by test_done, so it's not > that surprising that they are not there, since test_done is not reached > in those files. I assumed the subtests would timeout separately and the test framework would catch that. If the test script itself is killed then yes, that outcome is expected :) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: T350-crypto T357-index-decryption: possible race condition?
Michael J Gruber writes: > Building notmuch 0.37 with my usual spec-file as a rawhide-mock build > (a local chroot for the development "version" of Fedora which will > become Fedora 39) I see: > ``` > T350-crypto: Testing PGP/MIME signature verification and decryption > PASS emacs delivery of signed message via fcc > PASS emacs delivery of signed message via fcc and smtp > PASS signed part content-type indexing > PASS signature verification > PASS detection of modified signed contents > PASS corrupted pgp/mime signature > PASS signature verification without full user ID validity > PASS signature verification with signer key unavailable > ``` > There the suite "hangs" for about 2 minutes, followed by This sounds suspiciously like "timeout" kicking in and killing a test that is taking too long. You can set NOTMUCH_TEST_TIMEOUT in the environment to some smaller/larger number to test this. The first subtest in T357 is also sending an encrypted message, so it looks like some bad interaction between gpg and emacs. Maybe you can try sending an encrypted message from emacs interactively in your chroot environment. 0) you will first need to run gpg --no-tty --import ./test/openpgp4-secret-key.asc this will create a keyring etc... in the chroot 1) You can use the script ./devel/try-emacs-mua -q 2) Copy the following into *scratch* and run with C-j after the last closing paren (this is just copied from the test suite internals) (let ((message-send-mail-function (lambda () t)) (mail-host-address "example.com")) (notmuch-mua-mail) (message-goto-to) (insert "test_su...@notmuchmail.org\nDate: 01 Jan 2000 12:00:00 -") (message-goto-subject) (insert "My Subject") (message-goto-body) (insert "a body") (mml-secure-message-encrypt) (let ((mml-secure-smime-sign-with-sender t) (mml-secure-openpgp-sign-with-sender t)) (notmuch-mua-send-and-exit))) You will probably need to answer "c" to create the sent-mail folder at the prompt. > ``` > In the end, the suite complains: > ``` > '/builddir/build/BUILD/notmuch-0.37/test/test-results/T350-crypto' > does not exist! > '/builddir/build/BUILD/notmuch-0.37/test/test-results/T357-index-decryption' > does not exist! > ``` > At least for T350 this is strange because several subtests ran and > passed! This indicates a race or a wrong signal trap. Note that those files are summaries created by test_done, so it's not that surprising that they are not there, since test_done is not reached in those files. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org