Activity for tkImg
-
Paul Obermeier committed [r980] on Code
Released version 2.1.1 on 2026/03/04
-
tkImg updated /tkimg/2.1/tkimg 2.1.1/Img-2.1.1.tar.gz
-
-
-
-
-
Updates for upcoming 2.1.1 release.
-
Updated libtiff to version 4.7.1.
-
Updated libpng to version 1.6.55.
-
Updated libjpeg to version 10.0.
-
Updated zlib to version 1.3.2.
-
Changed variable name from "img-be" to "img".
-
Due to the write algorithm used in XPM parser, color palettes are written in different order on big vs. little endian systems.
-
Added checks for writing, which is npt supported for FLIR images.
-
Renamed test constraint "Tk87" to "Tk9", as there was no official Tk 8.7 release.
-
Updasted Img version to 2.1.1.
-
Adapted to work correctly on big-endian systems (tested on SGI).
-
Adapted to work correctly on big-endian systems (tested on SGI).
-
No need to add TCL_LIBS to SHLIB_LD_LIBS.
-
Corrected verbose message of "Bytes per line" on big-endian systems.
-
Adapted to work correctly on big-endian systems (tested on SGI).
-
window.c: resources leaked on error in StringRead()
-
Used goto approach. Tested on Windows and Linux.
-
Issue #119: Corrected resource leaks in StringRead.
-
demo.tcl: avoid toolhelp display issue on Tk Aqua 9.0 (macOS)
-
Corrected with commit #963. Your patch did not work. Solved by creating and destroying the tooltip window.
-
Issue #35: Corrected tooltip display on macOS.
-
Christopher Chavez created ticket #35
demo.tcl: avoid toolhelp display issue on Tk Aqua 9.0 (macOS)
-
window.c: resources leaked on error in StringRead()
-
Improved test, if ghostscript exists and is working.
-
Released version 2.1.0 on 2025/06/22
-
Stack smashing detected on MSYS2/Clang64
-
Fix included in new version 2.1.0.
-
-
-
Updates for upcoming 2.1.0 release.
-
-
Removed obsolete procedure SetFileTypes.
-
ofv posted a comment on ticket #118
For the record, the commit in Mingw-packages is cf52b888301d4e0f66cf5116b0d9f4955876cb54 link to commit in github That commit included the proposed change to tif_ojpeg.c, which I reckon it is unnecessary. Thank you.
-
Checked in tkimg.h with proposed change: #if defined(__MINGW32__) && !defined(__aarch64__) && !defined(__clang__) Works for all of my test systems.
-
Builtin versions of setjmp/longjmp only needed for mingw64 (gcc/msvcrt).
-
Tested with unpatched 2.0.1 on mingw64 (gcc/msvcrt), ucrt64 (gcc/ucrt), clang64 (clang/ucrt), plus patched 2.0.1 (clang/ucrt). Same output as yours on all cases.
-
I used the following script and attached (incorrect) TIFF file for testing. Note, that the TIFF file is marked as suspicious (TIFF.CVE-2017-3042) by the TACHYON virus scanner on VirusTotal. set tkVersion [package require Tk] puts "Tk : $tkVersion ([expr 8 * $tcl_platform(pointerSize)]-bit)" set imgVersion [package require Img] puts "Img: $imgVersion" set f id_003177,src_001927,op_havoc,rep_1.tif puts "Checking $f ..." set retVal [catch {set phImg [image create photo -file $f -format {TIFF -verbose...
-
Thanks for the reference. oscar@w10x64-vm-sky CLANG64 /d $ echo | clang -dM -E - | grep clang #define __clang__ 1 #define __clang_literal_encoding__ "UTF-8" #define __clang_major__ 20 #define __clang_minor__ 1 #define __clang_patchlevel__ 5 #define __clang_version__ "20.1.5 " #define __clang_wide_literal_encoding__ "UTF-16" oscar@w10x64-vm-sky CLANG64 /d $ echo | clang -dM -E - | grep -i gnu #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC_STDC_INLINE__ 1 #define __GNUC__ 4 So...
-
The commit message from 2023-04-23 says: Added macros SETJMP and LONGJMP as workaround for incorrect setjmp and longjmp in MINGW. For a discussion of the error see ex. [https://stackoverflow.com/questions/53709069/setjmp-longjmp-in-x86-64-w64-mingw32] I don't know, which gcc versions are affected by the error. If only "old" compilers are affected (ex. gcc 4.x), a more clean and simple solution would be: #if defined(__MINGW32__) && __GNUC__ < 5 #define SETJMP(jbuf) __builtin_setjmp(jbuf) #define LONGJMP(jbuf,...
-
We fixed the problem by applying the patch below. It also modifies tif_ojpeg.c for consistency. Do you remember why mingw32 was changed to use __builtin_setjmp/__builtin_longjmp? Index: base/tkimg.h =================================================================== --- a/base/tkimg.h (revision 957) +++ b/base/tkimg.h (working copy) @@ -24,7 +24,7 @@ # define tkimg_vsnprintf vsnprintf #endif /* _MSC_VER_ */ -#if defined(__MINGW32__) +#if defined(__MINGW32__) && !defined(__aarch64__) && !defined(_UCRT)...
-
Changing base/tkimg.h to use plain setjmp/longjmp instead of the __builtin variants removes the crash, as well as the warnings. I'll ask some people about what's going on and come back with a patch. Thank you.
-
Changing base/tkimg.h to use plain setjmp/longjmp instead of the __builtin variants removes the crash. I'll ask some people about what's going on and come back with a patch. Thank you.
-
This looks like Tk is trying to load the jpg file as if it were a png, isn't it? #0 png_error (png_ptr=png_ptr@entry=0x30fb890, error_message=0x7ff980e71222 <.refptr.png_sRGB_table+1418> "Not a PNG file") at D:/dev/other/tkimg-code/compat/libpng/pngerror.c:82 #1 0x00007ff980e5431e in png_read_sig (png_ptr=png_ptr@entry=0x30fb890, info_ptr=<optimized out>) at D:/dev/other/tkimg-code/compat/libpng/pngrutil.c:139 #2 0x00007ff980e48f1a in png_read_info (png_ptr=0x30fb890, info_ptr=0x7ff980e71222 <.refptr.png_sRGB_table+1418>)...
-
I'm using tcl/tk 8.6.16. There are no other extensions loaded, just the code above executed with wish. I tried to replicate the problem in Linux, to no avail, even with Valgrind, but please note that Windows and Linux have different ABIs and different C runtimes. It is interesting that the crash does not happen with the MinGW64 environment (which uses the old MSCVCRT runtime). All packages in MSYS2 (a few thousands of them) are built with -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong and AFAIK...
-
I do not have MSYS2/Clang available, but running tests on Debian using similar compiler options (-fsanitize=address,undefined -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -mshstk) on current trunk did not show any stack corruptions. Looking at the source of png.c, your first stack trace, where png_ptr is 0x0 in CommonMatch should not be possible, because png_ptr is checked just before calling CommonMatch. I tested with Tcl/Tk 9.0.1. Which version of Tcl/Tk are you using? Are you loading any other...
-
Stack smashing detected on MSYS2/Clang64
-
Fixed bug in readInfoHeader.
-
Updated libpng to version 1.6.48.
-
Added check for PNG sub-images and submit appropriate error message.
-
Updated copyright date. No code changes.
-
Adapted copyright date and version number.
-
Updated version number to 2.1.0.
-
Added additional test scripts and images for extended RAW functionality.
-
Added expected results in Readme files.
-
Renamed RawWriteOptions.tcl to RawCreatePhoto.tcl
-
Corrected typo in comment.
-
Corrected file extension from .rgb to .tga.
-
Corrected file extension from .rgb to .ras.
-
Extended RAW parser to support 1, 2, 3 and 4 channel files when reading.
-
Updated libpng to version 1.6.47.
-
Delete directories testOut after test execution. Added option "--nodelete" to disable deletion.
-
Released version 2.0.1 on 2024/12/08
-
-
-
-
Added notes regarding afltests not included in distribution files.
-
Added empty directory "templates", which is needed by tclssg.
-
Updates for upcoming 2.0.1 release.
-
Replaced calls to "package require Tk" and "package version Tk" to determine Tk version number with $::tk_patchLevel.
-
Added check, if ghostscript interpreter is available.
-
ryotakatsuki posted a comment on discussion Open Discussion
The problem is not libtiff. The files marked as malicious are in the test images. I created a version of Img-1.4.17 without afltestimgs.7z (I just decompressed, deleted, and recompressed) that have no detections: Img-1.4.17-no-afltestimgs.tar.gz https://www.virustotal.com/gui/file/3eee28c2e6daf343a538d8f7bcbf738dd43808465683f6a0d6962c212f5303d5?nocache=1 And here is just the test images (afltestimgs.7z): afltestimgs.7z https://www.virustotal.com/gui/file/f1b1e7d00ea1358981305c0e3dd3f3238ec977395...
-
Larry W. Virden posted a comment on discussion Open Discussion
The issue probably is use of liftiff. It used to and perhaps still does have security issues On Thu, Nov 28, 2024, 6:52 AM ryotakatsuki takatsuki@users.sourceforge.net wrote: If you could remove the afltests, it would be awesome :) Thanks! tkImg is marked as malicious by multiple vendors in virustotal https://sourceforge.net/p/tkimg/discussion/172363/thread/4a5438d14c/?limit=25#3dcc/02fc Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tkimg/discussion/172363/...
-
If you could remove the afltests, it would be awesome :) Thanks!
-
I used the afltest images with great success to find serious bugs in the Img code, but was not aware of any virus detection problems. If removing the above mentioned TIFF image and generating a new 7z file, it still generates detection alarms, so it seems, there are other problematic images in there. As people downloading the tarball will not likely run the extended tests, I can remove the afltests directory from future tarballs.
-
I don't think any tiff image will trigger the detection. The CVEs mentioned in the detection names are related to a vulnerability that allowed especially crafted tiff images to execute code, so maybe the problematic tiff image is one of those (I assume that it would be for testing purposes).
-
Hmm an image file of type tiff triggering virus concerns. Is the image something that violates standards? How would one test tiff code support without a tiff image? On Tue, Nov 26, 2024, 9:42 AM ryotakatsuki takatsuki@users.sourceforge.net wrote: Hi, The tarball for more recent 1.4.* versions (at least 1.4.17, 1.4.16 and 1.4.15) is marked as malicious in virustotal: https://www.virustotal.com/gui/file/4607abc6d8aa92f6e4f9b337db1df90e76a2dafdf2d53eff296b68ae63bf81aa The cause seems to be the afltests.zip...
-
Hi, The tarball for more recent 1.4.* versions (at least 1.4.17, 1.4.16 and 1.4.15) is marked as malicious in virustotal: https://www.virustotal.com/gui/file/4607abc6d8aa92f6e4f9b337db1df90e76a2dafdf2d53eff296b68ae63bf81aa The cause seems to be the afltests.zip file contained in the tests (beause of id_009971,src_009965,op_flip1,pos_8.tif): https://www.virustotal.com/gui/file/f1b1e7d00ea1358981305c0e3dd3f3238ec977395cfd689623283903e57b4205/relations The asset may be used in the tests and be there...
-
Updated version to 2.0.1.
-
Jan Nijtmans committed [r935] on Code
Fix warning in pixmap.c: pixmap.c:208:71: warning: suggest parentheses around arithmetic in operand of ‘|’
-
If USE_FORMAT_VERSION==1, we need at least Tk 8.7. If TK_MINOR_VERSION is not defined, assume Tk 8.7+
-
Add --with-tk8 configuration option
-
Corrected some comments.
-
Windows executables got lost in merge.
-
Changed EOL to Linux.
-
Changed EOL to Linux.
-
Changed EOL to Linux.
-
Merge branch 1.5.X (containing Img version 2.0.0) into trunk.
-
Create branch for possible 1.4 security fixes.
-
Released version 2.0.0 on 2024/09/30.
-
Released version 1.4.17 on 2024/09/30.
-
Announce: Img 2.0.0
-
-
-
1 >
