Hello David, I can confirm that this patch works fine for the s390x architecture. I have a setup with postfix and two opendkim instances for RSA and ED25519 dual signing running bullseye on a IBM system z15 (in fact it's the same host where zelenka and zandonai are hosted on). I've not tested this patch on x86 yet. If you want, I can build a test system for x86. But maybe you already have a system to give it a try?
I've split the patch in a fix for s390x and a cleanup patch on purpose to keep things separated. Feel free to ignore the cleanup patch. From my understanding upstream opendkim seams pretty much dead, so I've little hope to get those fixes upstream. Ciao Martin ________________________________________ Von: David Bürgin <[email protected]> Gesendet: Freitag, 18. November 2022 18:19 An: Martin Grimm; [email protected] Betreff: Re: Bug#1012506: Fix for 64bit big-endian systems Hello Martin, thank you for the patches. Martin Grimm: > Building opendkim with --with-gnutls disables support for ed25519, so I've > taken a closer look at the problematic code and found the culprit code. > > The error comes from the call to the openssl function RSA_sign in > libopendkim/dkim.c:3945: > > RSA_sign takes as fifth argument a reference to an unsigned int (4 byte) > variable to return the length of the signature. > The opendkim-code uses a reference to the variable l of type size_t (unsigned > long, 8 bytes on s390x) casted as (signed) int reference for this. > This is fatal for a big endian system. > > I've attached to patches: > 1.) fix-RSA_sign-call.patch: fixes the call to RSA_sign by using a temporary > variable ui_l of the correct type unsigned int to get back the length from > RSA_sign and savely assigns the returned value to l after the call. > 2.) fix-printf-types.patch: fixes several calls of printf in dkim.c that use > the signed int specifier "%d" to print size_t arguments. For C99-code "%zu" > should be used for size_t variables. Regarding patch 1: I don’t have access to an s390x machine and I don’t want to spend too much time assessing this patch. I can apply it, but please confirm that you have verified that this is the right fix and that it does not impact the current working build. If someone else can try it and report back, that would be useful, too. Regarding patch 2: There are lots of compiler warnings today (eg also for our current use of OpenSSL APIs). I can apply the patch, but generally code cleanup is something I prefer done upstream (yeah, I know …) instead of maintained as Debian patches. Ciao, David
