dkimpy

tests miltertest sigabort

Asked by Gene

I wonder if this works for other folks.
Just updated python to 3.11 (on Arch) , and rebuilding dkimpy package.

When I run the tests the miltertest dies:

I build opendkim along with miltertest.

cd tests
$ miltertest -vvv -s 00_minimal.miltertest
Aborted (core dumped)

The gdb back trace shows it dies in lua:

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
    at pthread_kill.c:44
Downloading source file /usr/src/debug/glibc/glibc/nptl/pthread_kill.c
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;

   (gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
    at pthread_kill.c:44
#1 0x00007ffff7de4953 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff7d95ea8 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff7d7f53d in __GI_abort () at abort.c:79
#4 0x00007ffff7f62041 in luaD_throw (L=L@entry=0x5555555642a8, errcode=<optimized out>, errcode@entry=2)
    at /usr/src/debug/lua/lua-5.4.4/src/ldo.c:132
#5 0x00007ffff7f6c8ed in luaG_errormsg (L=L@entry=0x5555555642a8)
    at /usr/src/debug/lua/lua-5.4.4/src/ldebug.c:815
#6 0x00007ffff7f6caab in luaG_runerror (L=L@entry=0x5555555642a8,
    fmt=fmt@entry=0x7ffff7f90156 "attempt to %s a %s value%s") at /usr/src/debug/lua/lua-5.4.4/src/ldebug.c:829
#7 0x00007ffff7f6e1c0 in typeerror (extra=0x7ffff7f92f47 "", op=0x7ffff7f92347 "call", o=0x555555564910,
    L=0x5555555642a8) at /usr/src/debug/lua/lua-5.4.4/src/ldebug.c:725
#8 luaG_callerror (o=0x555555564910, L=0x5555555642a8) at /usr/src/debug/lua/lua-5.4.4/src/ldebug.c:748
#9 luaD_tryfuncTM (L=L@entry=0x5555555642a8, func=func@entry=0x555555564910)
    at /usr/src/debug/lua/lua-5.4.4/src/ldo.c:396
#10 0x00007ffff7f6c631 in luaD_precall (L=L@entry=0x5555555642a8, func=func@entry=0x555555564910,
    nresults=nresults@entry=0) at /usr/src/debug/lua/lua-5.4.4/src/ldo.c:589
#11 0x00007ffff7f6e4e9 in ccall (inc=65537, nResults=0, func=0x555555564910, L=0x5555555642a8)
    at /usr/src/debug/lua/lua-5.4.4/src/ldo.c:607
#12 luaD_callnoyield (nResults=0, func=0x555555564910, L=0x5555555642a8)
    at /usr/src/debug/lua/lua-5.4.4/src/ldo.c:627
#13 callclosemethod (yy=0, err=0x5555555643c0, obj=0x555555564900, L=0x5555555642a8)
    at /usr/src/debug/lua/lua-5.4.4/src/lfunc.c:118
#14 prepcallclosemth (yy=0, status=-1, level=0x555555564900, L=0x5555555642a8)
    at /usr/src/debug/lua/lua-5.4.4/src/lfunc.c:153
#15 luaF_close (L=L@entry=0x5555555642a8, level=level@entry=0x555555564900, status=status@entry=-1, yy=yy@entry=0)
    at /usr/src/debug/lua/lua-5.4.4/src/lfunc.c:234
#16 0x00007ffff7f6e642 in lua_settop (L=0x5555555642a8, idx=<optimized out>)
    at /usr/src/debug/lua/lua-5.4.4/src/lapi.c:205
#17 0x000055555555737a in main ()

Question information

Language:
English Edit question
Status:
Solved
For:
dkimpy Edit question
Assignee:
No assignee Edit question
Solved by:
Gene
Solved:
Last query:
Last reply:
Revision history for this message
Scott Kitterman (kitterman) said : 		#1

That looks like a Lua issue. I would guess it's something in Lua or the opendkim Lua bindings (probably not).

If you download the source for dkimpy, the README.md file describes how to do standalone testing of dkimpy. If any of those tests fail, then I think you have a dkimjpy issue. I'm reasonably confident it's not implicated in that back trace.

Revision history for this message
Gene (gene-arch) said : 		#2

Thanks Scott - agree completely the crash was all lua. Was just curious if it worked for other folks.

I didn't actually see any standalone testing notes in the README file.

dkimpy has been working well for quite some time now using postfix.

 I did update the mail servers (dkimpy package rebuilt against 3.11 ) and it has continued to work well after the python update to 3.11.

It is running in verify mode on the border router and signing/verify on the interior mail server - everything continues to work great. Sign is with both ed25519 and rsa (though I've yet to see any others validating the elliptic curve, according the dmarc reports.

Any thoughts to adding a pyproject.toml?

Thank you for your work - it is very much appreciated.

gene

Revision history for this message
Scott Kitterman (kitterman) said : 		#3

Eventually, yes on pyproject.toml. Unfortunately there's not yet a way to replicate the custom setup.py extensions that the package uses.

There are two packages:

dkimpy - the Python module for doing DKIM signing/verifying

dkimpy-milter - the milter application that integrates with Sendmail/Postfix.

I think we can have been slightly miscommunicating on the tests. It's the dkimpy-milter tests that use miltertest. Since this question was filed under dkimpy, that's what I was referring to for README.md. Either way, I'm glad it's working for you.

I recently got my first bug report related to error handling for ed25519 signature verification, so it's apparently starting to be used.

Revision history for this message
Gene (gene-arch) said (last edit ): 		#4

Bah my bad - very sorry - while they are indeed completely different in my 'head' they are a couple that live together :)

The dkimpy tests ran fine.
For dkimpy-milter - the only issue I found was the lua one above with miltertest.

Glad to hear there is some traction on EC. Certainly the google and yahoo mailers don't yet handle them. Bit surprising really.

I wrote a little python script to make text based dmarc report so its easy for me to keep an eye on them. Interestingly for one newly registered domain with no emails yet, other than a few tests - every single dmarc fail came from faked mail directly from ASN 4827 (China169 Backbone). Happened within short period of domain registration - and has continued daily for the few weeks since the domain was registered. Interesting. I block some countries and ASNs inbound, otherwise I'd be curious if same source would be prodding.

My apologies for blending dkimpy and the companion milter.

I will be more careful next time.

Thanks again Scott.

gene

PS - I did notice the exception fix you quickly resolved a day or so back..

Revision history for this message
Scott Kitterman (kitterman) said : 		#5

Don't worry about the confusion. Easy enough thing to do. I only mentioned it for clarity regarding where to look for the tests. I just did a new dkimpy release, which includes the exception fix.

Revision history for this message
Gene (gene-arch) said : 		#6

Terrific - rebuilding it now - thank you