Activity for Bob Friesenhahn
-
Bob Friesenhahn modified ticket #597
heap-buffer-overflow in function ReadXWDImage of coders/xwd.c
-
heap-buffer-overflow in function CloneImage of magick/image.c
-
use allocate memory before null check
-
On Mon, 4 Mar 2019, Bob Friesenhahn wrote: The '-background white' option would need to occur prior to the -extent command. Order is important. I should mention that RGB white is not the same as CMYK white. It is possible/likely that the sense of the values needs to be inverted (e.g. 00 where FF would appear in a hex color specification). Using hex format is most reliable. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/...
-
On Mon, 4 Mar 2019, Aaron Martinez wrote: When running the following command to resize an image (fix aspect ratio): gm convert <src_img> -gravity Center -extent <w>x<l> <dest_img></dest_img></l></w></src_img> some of the <dest_img> have a black background where the new extent size was added.</dest_img> I noticed that this happened for transparent TIFF images and for images with a CMYK colorspace. I have added a sample image. Through research I believe that it is happening for transparent images b/c...
-
On Wed, 20 Feb 2019, Mattias Wadman wrote: Yes i agree. Do you want me to look into adding such define? Well tested patches are always appreciated. A recent example pertaining to the PNG coder is -define mng:maximum-loops=<value></value> The PNG coder supports PNG, JNG, and MNG so it would need to be decided if all of these should support the same feature and if the same feature should appear with png:, jng:, and mng: prefixes. It is possible for a definition starting with png: to be used by JNG...
-
On Wed, 20 Feb 2019, Mattias Wadman wrote: Not sure if it make sense to use GetMagickResourceLimit(MemoryResource) as limit? It would be an extraordinarily high limit and a huge jump from the default, impacting all users. Intentionally compromised PNG files could take advantage of the weakness. Most format-specific options are supported via the -define mechanism so that they can be carefully targeted. Bob
-
Non-malicious JPEG file fails with "Unreasonable dimensions"
-
This problem is fixed by Mercurial changeset 15898:f756b4df2b14. Testing showed that it was possible to achieve JPEG compression ratios as high as 2400 so we allow up to 2500. Unfortunately, the value of the compression ratio check is diminished by needing to allow such high ratios.
-
"gm convert: Insufficient image data in file" when hinting input image
-
This issue is address by Mercurial changeset 15896:d7c161148b75. Sorry for creating this problem. Thank you for reporting it.
-
I am able to reproduce the problem (due to using -size), although the file I downloaded from SourceForge is not likely to be the file you uploaded. The other complaint about insuffient image data in file seems to be due to a JPEG file with extreme compression whereas this issue is due to using -size to request a larger image than the original. The test for compression ratio should be looking at the original JPEG dimensions and not the scaled dimensions. Hopefully libjpeg makes the original dimensions...
-
What is the origin of the 'cjpeg' you are using which supports the '-block 16' option?
-
I have encountered this sample file before. As far as I am aware, GraphicsMagick has never displayed this image correctly. Instead I get an all black image. Modern ImageMagick seems to display it properly.
-
On Tue, 12 Feb 2019, Mattias Wadman wrote: But im not sure what the most proper solution is. Incerase 512? in our case we just removed the check and rely on resource limits instead A possibility is to only apply this type of test when the pixel dimensions are sufficiently large to be of concern. It still does not avoid the reality that it is possible to create an incredibly small JPEG with a very high compression ratio which can decode to very large dimensions such as 60000x60000. It is also possible...
-
On Tue, 12 Feb 2019, Mattias Wadman wrote: It seems to fail the uncomrpessed file can't the more than 512 times the input file size What is the size (in bytes) of "unreasonable.jpg" and the reported effective compression ratio? I assume that the compression ratio should be included in the traces. Bob
-
heap-buffer-overflow in ReadBMPImage of bmp.c
-
I believe that this issue is finally properly addressed by changeset 15880:c38fc0e3e465. The DIB module was also similarly improved, although the DIB reader already did use pretty good overflow checks.
-
Add fuzzing support for jpeg + freetype delegates
-
Already applied and in use.
-
Pixel cache dimensions incompatible with image dimensions
-
I will work on this issue as available time permits.
-
Indroduce "use-sharp-yuv" WebP encoder option
-
This patch is applied via mercurial changeset 15876:dcb5b3462082. Thanks for the patch!
-
On Mon, 14 Jan 2019, Aaron Martinez wrote: You have been doing your homework. If the documentation still mentions MAGICK_MMAP_WRITE then that is an error in the documentation since support for writing files using mmap() has been removed. Yes, I was looking at an older version of the documentation. Latest version does not have this property. I am sorry that the GraphicsMagick.org site has not been reliably available lately. The problems seen look like a Denial Of Service (DOS) attack with massive...
-
On Fri, 11 Jan 2019, Aaron Martinez wrote: and it depends on the properties of the TIFF file. Given this issue, it would have been good to be able to specify a different size for reads than for writes. How would we specify the different sizes for reads/writes? Looking Someone would need to change the source code. It is unfortunate that I did not think of these factors at the time. at the documentation, I only see these boolean values MAGICK_MMAP_READ/MAGICK_MMAP_WRITE. Do we need to enable these?...
-
On Thu, 10 Jan 2019, Aaron Martinez wrote: Thanks for this information Bob. It was helpful. We opened a case with RedHat about NFS and they said that 8 seconds for NFS was fast and that if it took closer to a minute then that would have been an issue. For GM, I ran test with various MAGICK_IOBUF_SIZE and OMP_NUM_THREADS values for a TIFF image and found the fasteest time to process was 6.71 sec. I will continue to run this test for a batch of different images to see if the same settings would be...
-
On Tue, 8 Jan 2019, Aaron Martinez wrote: Hello, I am using GM to convert images. The images that are being converted are stored in an NFS mount. We noticed that GM runs much slower when it tries to write out the image to an NFS mount point than it does to local directory. There is a 7 second difference in this. Has anyone else experienced this before? Is it a change that we need to do on the NFS mount or are there special flags for GM to improve performance? Disk drives are 3Gbit, 6Gbit, or even...
-
GraphicksMagick - gm montage: Coder did not return an image (this is a bug, please report it!)
-
Still waiting for response from reporter. I was not able to reproduce this issue so closing it until more information is provided.
-
Bug in IsNexusInCore()
-
The use of cache_info->pixels in IsNexusInCore() was only for arithmetic and not a dereference so it is not clear what caused the crash you are seeing. Without adding the assert, I was never able to reproduce a crash. Changeset 15875:733b7e6c2589 moves the IsNexusInCore() code into SetNexus() and adds the check you suggested.
-
heap-buffer-overflow in ReadBMPImage of bmp.c
-
Problem (now identified as CVE-2018-20185) is claimed to still exist after my fix. See https://bugzilla.suse.com/show_bug.cgi?id=1119823#c1
-
Identify lack of data (no Exif) in RAW formats
-
Changeset 78e4ab594165 requests TIFF output from dcraw, which results in some metadata making its way into GraphicsMagick. I see that 'Artist', 'Make', 'Model', 'Comment', and 'Software' re included. However, EXIF data is currently not included (although the TIFF written by dcraw does include an EXIF IFD) because GraphicsMagick still does not decode EXIF from TIFF.
-
On Thu, 3 Jan 2019, Adam wrote: @bfriesen Im using GM for more than 4 years and im pretty sure it was working fine earlier. I really badly need all EXIF that is possible to get from the file and for now i can't even get Mark/Model or even shutter time and there is so much more to get (GPS etc.) So is there any option / flow to get it or it's planned to fix it somehow? I will try option with -T in a minutes. Not being an expert on RAW files, I was not aware that it was an issue until this bug report...
-
On Thu, 3 Jan 2019, Adam wrote: *As a "not returning any data" i mean any EXIF It is true that GraphicsMagick uses 'dcraw' to convert RAW formats to PNM formats which do not support any metadata at all. Investigation shows that if 'dcraw' is built to support TIFF format and if TIFF output is requested (-T option), it appears that 'dcraw' does put some useful metadata in the TIFF file. I don't think that GM currently extracts EXIF from TIFF, although it will extract a ICC color profile. Bob Bob Friesenhahn...
-
I tried your sample commands and the null pointer issue did not occur. It may well occur with older versions of GraphicsMagick. What version of GraphicsMagick are you testing with? Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
-
Bug in IsNexusInCore()
-
In the code I am reading, this function is only ever called if cache_info->pixels is not NULL. Do you have evidence that this function is ever called with cache_info->pixels NULL?
-
convert +dither does not work as expected
-
Please try putting your +dither request immediately after the input file name (e.g. right before -colors or -map) rather than before the input file name. The -fuzz option is used for color matching but is not used when reducing to a colormap with -colors or -map so it serves no purpose for your command.
-
Identify returning wrong compression values
-
This problem is fixed by Mercurial changeset 15873:8b84cdc9f9cd. Thanks for reporting this issue.
-
gm identify with format "%[JPEG-Colorspace-Name]" does not work
-
This issue is fixed by Mercurial changeset 15873:8b84cdc9f9cd. Thanks for the prompt report.
-
WebP and ZStd for TIFF not supported on Windows
-
Artifacts when scaling a PNG with semi-transparent pixels
-
Thanks to Troy, this problem is finally solved. See Mercurial changesets 15870:113103cc7272 and 15871:e82340b7c814.
-
Executing with -format identity does not return correct jpg compression values. gm identify -format '%f: %Q\n' * ``` new2.jpg: 75 photo.jpg: 75 profimg.JPG: 75 This is a new problem added in the latest release. I changed the JPEG reader 'ping' operation to quit sooner than it did before due to a denial of service (DOS) opportunity. If you add the +ping option, then the results will be as before, but this causes the image pixels to be read. Bob
-
Assertion Failure in coders/png.c:7503
-
The problem is that the DIB file claims to have aspects of both a colormapped file and one containing direct pixel values. It claims to have a colormap yet it also claims to be 32-bits. Only 8-bit/sample and less use a colormap. The end result is that the direct case is used and so the indexes data is never initialized. This problem is fixed by Mercurial changeset changeset 15869:648e2b406589.
-
It seems likely that the DIB reader is doing something wrong since valgrind also shows issues during encoding if the output is written to MIFF format.
-
heap-buffer-overflow in ReadBMPImage of bmp.c
-
heap-buffer-overflow in WriteTGAImage of tga.c
-
This issue is fixed by changeset 15865:15d1b5fd003b. Thanks for the report.
-
Assertion Failure in coders/png.c:7503
-
It seems that the POC file may be ok. It appears to be a DIB file and not a PNG file. Valgrind shows that there is definitely something wrong.
-
It is recommended to attach the POC file in a zip or tar wrapper since SourceForge has a habit of re-writing image formats that it understands. What I download may have no resemblance to what you uploaded. Bob
-
I see multiple problems to fix here. The first is that there should be code to reject the XWD file because it is too small (even though we rely on X11 to actually decode it). The second is that the TGA format only supports a maximum pixel dimensions of 64k by 64k and so the writer needs to report an error immediately.
-
I my testing, this test case gets severely hung up in X11 library code reading the (claimed to be) huge XWD file. I did not wait a long time to see what might happen.
-
This issue is fixed by changeset 15864:648e3977a293
-
On Tue, 11 Dec 2018, galycannon wrote: yes,my environment is 32-bit ubuntu 16.04 machine and I build with 32-bit ASAN I did notice that it was necessary to enlarge the image pixel limits beyond the default before the problem is encountered. This means that most users are defended from this issue. There are likely many more similar issues to be discovered in the 32-bit build.
-
I was able to get a working 32-bit ASAN build on my 64-bit machine and can reproduce the issue.
-
A heap-use-after-free problem in function GetLocaleExceptionMessage in ../magick/error.c:521
-
This issue was already fixed on November 22nd via changeset 15849:94c8be10147f. GraphicsMagick does not support writing to XCF format. It can only read from it.
-
heap-buffer-overflow in WriteTGAImage of tga.c
-
heap-buffer-overflow in ReadBMPImage of bmp.c
-
I assume that i686 in the system description means that this is a 32-bit Linux OS?
-
Animated WebP is not currently supported. We would like to support it but there has not been enough available free time for this development. In the past, useful WebP additions have come from interested external parties. I think that supporting animated WebP properly is a bit of work and it is essentially a different format than normal still-photo WebP. Bob
-
I did some experimentation using the commands found in gm-error.zip. I substituted a different ICC color profile since one was not provided. I did not encounter the reported error and a useful output image was produced. Please provide the full outputs from 'gm -version' and 'gm convert -list formats'. It is also useful to set the MAGICK_DEBUG environment variable to 'exception' (e.g. export MAGICK_DEBUG=exception) and try running the commands. Perhaps something will be revealed by this (e.g. a useful...
-
Configure script picks wrong xml2-config
-
User reports success (apparently due to using pkg-config) with implementation now included in GM 1.3.31.
-
dcraw not returning 16 bit image eventough quantum depth is set to 16
-
This issue is resolved by Mercurial changeset 15853:1c8134c0f191. The -6 option is added if QuantumDepth is greater than 8. This might option not be ideal for Octave power-users but it is best for normal users.
-
dcraw not returning 16 bit image eventough quantum depth is set to 16
-
As you noticed, the arguments used for dcraw may be adusted by editing the delegates.mgk file. When dcraw outputs 16-bit data (depending on version) it may skip some transformations such as gamma encoding or skip white balance processing so the output is not similar to the 8-bit data it outputs. There are many different versions of dcraw and they do not all support the same options or behave the same. For a fairly new dcraw I have here (v9.27), using -6 would produce output which is most similar...
-
GraphicksMagick
-
In your example command line, I do not see single or double quotes around the '30x20>' argument to -resize and the '30x20>' argument to -size. I think that such quoting should be required since the shell should interpret the '>' as a request to execute the text up to that point as a command and send its output to the filename listed to the right of it. Also, using '>' with size like -size 30x20> is meaningless and possibly harmful since it only has meaning for an image which has already been rea...
-
On Thu, 29 Nov 2018, Tomasz Kłoczko wrote: My build was with --disable-static. I think that instead of static linking it should be possible to use LD_LIBRARY_PATH pointing to ${topbuiild_dir}/<sibdir lib="" .libs=""></sibdir> What you describe was supported by GraphicsMagick long ago. I removed built-in support for this since behavior is not portable or it may introduce a security hazard. For example, it would be bad if built objects remembered a library path in the build tree so that someone could...
-
On Thu, 29 Nov 2018, Tomasz Kłoczko wrote: Version 1.3.31. "make check" fails 7 times on prl tests not able to load Graphics::Magick module like below: Is this the first time you have done this or is it believed to be new behavior for this release? On first look loks like all faiils because there is no passed base path pointong to project source tree where is Graphics::Magick module. For many years, it has been necessary to formally install GraphicsMagick prior to building PerlMagick although Makefile...
-
gm identify with format "%[JPEG-Colorspace-Name]" does not work
-
This change is due to 'ping' mode (used implicitly by 'identify') doing less when reading JPEG files. The normal intention of 'ping' mode is to obtain major details about the image such as the file format, pixel dimensions, and if the image is colormapped. This information is normally obtained from the file header. The code path used in previous releases was subject to arbitrarily long run-times (depending on the JPEG file) even though the image pixels were not being read. Users expect that 'identify'...
-
'diagnostic pop' pragma without 'diagnostic push' in Drawable.h
-
This issue should be fixed by changeset 15850:d4a5e3d16957. Please verify that it is fixed on your end. It is odd that this warning was not produced when compiling the Magick++ test programs and demos.
-
On Wed, 28 Nov 2018, Roland Denis wrote: Since version 1.3.31, Clang raises two warnings in Drawable.h: ``` /usr/local/include/GraphicsMagick/Magick++/Drawable.h:2925:26: error: pragma diagnostic pop could not pop, no matching push [-Werror,-Wunknown-pragmas] pragma clang diagnostic pop ^ /usr/local/include/GraphicsMagick/Magick++/Drawable.h:2926:26: error: pragma diagnostic pop could not pop, no matching push [-Werror,-Wunknown-pragmas] pragma clang diagnostic pop What version of clang is being...
-
On Wed, 28 Nov 2018, Baykalov Pyotr wrote: However, I have this in config.log: ~~~ configure:27615: checking for xml2-config configure:27633: found /usr/bin/xml2-config configure:27645: result: /usr/bin/xml2-config ~~~ Nonetheless, the libraries are not dependent on Cygwin though. This is expected behavior. If pkg-config is not available or does not know about the package, then it will still use the xml2-config script. It tests for the path to the xml2-config in advance in order to avoid possibly...
-
Configure script picks wrong xml2-config
-
GraphicsMagick now uses pkg-config to search for libxml2 prior to looking for an xml2-config program. I don't know how this change impacts your build scenario. What happens now for your build?
-
Improve fonts search and add fallback lists
-
GM searches for Ghostscript in the registry and Ghostscript must be compatible (32/64 bit) with GraphicsMagick. Then once it finds Ghostcript installation location, it uses fonts that it finds there. While the fonts situation can be considerably improved, I don't consider this behavior to be a bug.
-
heap use-after-freee when convert one format into another format
-
This issue should be fixed by changeset 15849:94c8be10147f. Please verify. It would only happen if there was no write format support for the output format which was indicated. If this is continually happening for you for supported formats then something may be wrong with your build.
-
heap use-after-freee when convert one format into another format
-
Please attach the problematic TIFF input file inside a zip archive or a tar file so that SourceForge does not edit it in any way.
-
GraphicsMagick 1.3.31 is now available
-
GraphicsMagick 1.3.30 is now available
Oh no! Some styles failed to load. 😵