Created attachment 878656 [details] build.log of mhash Steps to reproduce: 1. Emerge with GCC 14 Reproducible: Always tiger.c:257:30: error: initialization of 'uint8_t *' {aka 'unsigned char *'} from incompatible pointer type 'uint64_t *' {aka 'long unsigned int *'} [-Wincompatible-pointer-types] 257 | mutils_word8 *temp = temp_64bit; | ^~~~~~~~~~ libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CO $ gcc-config -l ... [3] x86_64-pc-linux-gnu-13 [4] x86_64-pc-linux-gnu-14 * (first 2 are crossdev compilers)
Created attachment 878666 [details, diff] changes the temp type to a 64-bit uint
*** Bug 920268 has been marked as a duplicate of this bug. ***
The Fedora fix is https://src.fedoraproject.org/rpms/mhash/blob/rawhide/f/mhash-0.9.9.9-force64bit-tiger.patch.
(In reply to Sam James from comment #3) > The Fedora fix is > https://src.fedoraproject.org/rpms/mhash/blob/rawhide/f/mhash-0.9.9.9- > force64bit-tiger.patch. sorry, no, ignore this
(In reply to Christopher Fore from comment #1) > Created attachment 878666 [details, diff] [details, diff] > changes the temp type to a 64-bit uint Does the test suite pass for you with this? I get two failures with it: ``` FAIL: frag_test FAIL: rest_test ``` and this is in test-suite.log: ``` FAIL: rest_test =============== *** stack smashing detected ***: terminated Aborted (core dumped) FAIL rest_test (exit status: 134) FAIL: frag_test =============== Checking fragmentation capabilities of MD5: OK Checking fragmentation capabilities of SHA1: OK Checking fragmentation capabilities of HAVAL256: OK Checking fragmentation capabilities of RIPEMD160: OK Checking fragmentation capabilities of TIGER: *** stack smashing detected ***: terminated Aborted (core dumped) FAIL frag_test (exit status: 134) ``` I also get the following new warnings with your patch: ``` tiger.c: In function 'tiger_final': tiger.c:279:29: warning: array subscript [57, 63] is outside array bounds of 'uint64_t[8]' {aka 'long unsigned int[8]'} [-Warray-bounds=] 279 | temp[j] = 0; | ~~~~^~~ tiger.c:256:23: note: at offset [456, 504] into object 'temp_64bit' of size 64 256 | mutils_word64 temp_64bit[TIGER_DATASIZE/8]; | ^~~~~~~~~~ ```
Created attachment 881434 [details, diff] casts temp_64bit to mutils_word* This should do it, removing the `/8` in the array size and keeping the type change (while removing the casts below it) seemed to also have fixed the stack smashing tests but then changed the hash values so it doesn't seem like changing the type is doable, at least in a way obvious to me.
Confirmed patch fixes the issue. PASS: hmac_test PASS: keygen_test PASS: rest_test PASS: frag_test PASS: hash_test.sh =================================== Testsuite summary for MHASH 0.9.9 =================================== # TOTAL: 5 # PASS: 5 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ===================================
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2da114edf6cb70c8e2a05a1e337330144abd21ad commit 2da114edf6cb70c8e2a05a1e337330144abd21ad Author: Christopher Fore <csfore@posteo.net> AuthorDate: 2024-01-06 00:06:11 +0000 Commit: Yixun Lan <dlan@gentoo.org> CommitDate: 2024-01-06 10:23:23 +0000 app-crypt/mhash: fix compilation on GCC 14 Closes: https://bugs.gentoo.org/919700 Closes: https://github.com/gentoo/gentoo/pull/34665 Signed-off-by: Christopher Fore <csfore@posteo.net> Signed-off-by: Yixun Lan <dlan@gentoo.org> app-crypt/mhash/files/mhash-0.9.9.9-cast-temp-64bit.patch | 13 +++++++++++++ app-crypt/mhash/mhash-0.9.9.9-r3.ebuild | 3 ++- 2 files changed, 15 insertions(+), 1 deletion(-)
