summaryrefslogtreecommitdiff
path: root/gdk-pixbuf
Commit message (Collapse)AuthorAgeFilesLines
* Use Unicode in translatable stringsPiotr Drąg2017-12-0511-50/+50
| | | | | | See https://developer.gnome.org/hig/stable/typography.html https://bugzilla.gnome.org/show_bug.cgi?id=772216
* icns: Protect against too short blocklen (CVE-2017-6313)Bastien Nocera2017-12-051-1/+2
| | | | | | | The blocklen needs to be at least header sized to be valid, otherwise we can underflow picture data or mask data lengths. https://bugzilla.gnome.org/show_bug.cgi?id=779016
* tiff: Avoid overflowing buffer size computationBastien Nocera2017-12-051-2/+9
| | | | | | | Use g_uint_checked_mul() to avoid overflowing the guint used for buffer size calculation. https://bugzilla.gnome.org/show_bug.cgi?id=779020
* jpeg: Remove debug error messageBastien Nocera2017-12-051-1/+0
| | | | Introduced by error in commit fa472afe93
* jpeg: Prevent crashes when stopping loading files with errorsBastien Nocera2017-12-051-14/+17
| | | | | | | | This time, we want to make sure to avoid accessing JPEG internals when an error has already been set, in which case the file is irrecoverable. Reproducer in pixbuf-randomly-modified, with file valid.2.jpeg and seed R02S3d1f92e3076dbe16d2840cc408188f81
* jpeg: Prevent crashes when stopping loading broken filesBastien Nocera2017-12-051-1/+2
| | | | | A follow-up from commit b99e04f, to avoid trying to access pixel data in a pixbuf that doesn't exist any more.
* build: Remove "with" from Meson build optionsBastien Nocera2017-12-051-1/+1
| | | | | | As per https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting https://bugzilla.gnome.org/show_bug.cgi?id=790995
* build: Remove "enable" from Meson build optionsBastien Nocera2017-12-051-6/+6
| | | | | | As per https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting https://bugzilla.gnome.org/show_bug.cgi?id=790995
* jpeg: Fix loading truncated incremental inputsBastien Nocera2017-12-051-2/+19
| | | | | | | | | | | When loading incremental inputs through a GdkPixbufLoader, we didn't have any code replicating the stdio_fill_input_buffer() hack to finish up a file. Adding those markers makes libjpeg think that the file was at least closed properly, and will attempt decoding. https://bugzilla.gnome.org/show_bug.cgi?id=753605
* jpeg: Use a temporary variableBastien Nocera2017-12-051-4/+7
| | | | | | To avoid using context->cinfo all the time. https://bugzilla.gnome.org/show_bug.cgi?id=753605
* docs: Fix link to "Image data" section in API docsBastien Nocera2017-12-041-2/+2
| | | | | | Reference links use "[title][id]" not "[title](id)", that's for URLs. https://bugzilla.gnome.org/show_bug.cgi?id=765282
* gif: Initialise code_last_byte to not cause undefined behaviourTobias Mueller2017-12-041-1/+6
| | | | | | | | | | | | | | | | | | Currently, code_last_byte is set only after it has been used, i.e. context->block_buf[0] = context->block_buf[context->code_last_byte - 2]; comes before anything has touched context->code_last_byte yet. Except for the initialisation. context->code_last_byte is set a few lines later, though. And nowhere else, except for the initialisation which sets it to 0. That will inevitably lead to context->block_buf[-2] which is undefined behaviour. We hence set the code_last_byte to 2 in order to not make that array index invalid. https://bugzilla.gnome.org/show_bug.cgi?id=778584
* gif: Preventing undefined behaviour by making left shift unsignedTobias Mueller2017-12-041-1/+1
| | | | | | | | io-gif.c:509:44: runtime error: index -2 out of bounds for type 'guchar [280]' io-gif.c:510:44: runtime error: index -1 out of bounds for type 'guchar [280]' io-gif-animation.c:422:68: runtime error: left shift of 249 by 24 places cannot be represented in type 'int' https://bugzilla.gnome.org/show_bug.cgi?id=778584
* gif: Prevent access to negative array indexesTobias Mueller2017-12-041-0/+8
| | | | | | | | | It seems that a pathological gif file can cause a negative array index to be read. UBSAN reported this: io-gif.c:509:44: runtime error: index -2 out of bounds for type 'guchar [280]' io-gif.c:510:44: runtime error: index -1 out of bounds for type 'guchar [280]' https://bugzilla.gnome.org/show_bug.cgi?id=778584
* ico: Fix potential integer overflowDhiru Kholia2017-11-301-4/+5
| | | | | | | | | | Which relies on undefined behaviour. Instead of checking for an overflowed integer after the fact, check whether the addition would be possible at all. Fixes: CVE-2017-6312 https://bugzilla.gnome.org/show_bug.cgi?id=779012
* io-tiff: Correctly work with WIN32-IO version of libtiffРуслан Ижбулатов2017-11-291-1/+25
| | | | | | | | If libtiff is compiled with WIN32-IO (which is the default, unless it's built for Cygwin), it works with HANDLEs, not C runtime FDs. https://bugzilla.gnome.org/show_bug.cgi?id=788388
* gdk-pixbuf-scale: Fix retval introspection for scale_simple()Iñaki García Etxebarria2017-11-281-1/+1
| | | | | | | Add nullable return introspection annotation for gdk_pixbuf_scale_simple() as per existing API documentation. https://bugzilla.gnome.org/show_bug.cgi?id=789934
* io: Only ref pixbuf if it is not NULLBenjamin Otte2017-11-201-1/+5
|
* gdk-pixbuf-io: Implement async loading without threadsBenjamin Otte2017-11-201-31/+74
| | | | | | | The new GTK4 clipboard input streams don't like threads very much. So don't use them. https://bugzilla.gnome.org/show_bug.cgi?id=790584
* io-gif: Fail quickly when image dimensions are too bigBastien Nocera2017-09-191-7/+23
| | | | | | | | | Fail quickly when the dimensions would create an image that's bigger than MAXINT bytes long. See https://bugzilla.gnome.org/show_bug.cgi?id=765094 https://bugzilla.gnome.org/show_bug.cgi?id=785973
* build: Fix invalid syntaxBastien Nocera2017-09-191-1/+1
| | | | WARNING: Passed invalid keyword argument "source" in gdk-pixbuf/meson.build line 243.
* build: Fix TIFF loader compilation with autotoolsBastien Nocera2017-09-121-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=786342
* build: Support Windows components-based loaderChun-wei Fan2017-09-071-3/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is currently a GDI+ image loader that is within the GDK-Pixbuf codebase, which can serve as a basis for improvements to it or for moving on to more modern Windows APIs/Frameworks such as Windows Imaging Component (WIC). Provide a Windows-only option to build it with Meson, which will mean that when it is used the TIFF and JPEG loaders will not require libtiff and libjpeg-turbo/IJG JPEG, but will use the GDI+ component of Windows to deal with these images, along with BMP, GIF, ICO and images. This will also enable the support of EMF and WMF images. For building this set of loaders into the GDK-Pixbuf DLL, pass in 'windows' as a part of the loaders passed into builtin_loaders, or pass in 'all' to builtin_loaders in conjunction with this option. This also means that by using this set of GDI+ loaders, we cannot use any of the loaders (either in-house or those using the various opensource libraries) for these formats, so these loaders will be disabled as a result, since the MIME types, extensions and signature of these formats are the same in the GDI+ loaders with their respective counterparts that are otherwise built. Note that PNG support still requires libpng, and JPEG2000 support still requires libjasper, and in its current state, the TIFF and JPEG and ICO (and hence ANI) support that are done by the opensource libraries and/or the in-house loaders are still preferred over the GDI+-based ones since in the current state they tend to work better, so this is provided as an option. https://bugzilla.gnome.org/show_bug.cgi?id=785767
* build: Fix libjasper detection and usage on Meson/MSVCChun-wei Fan2017-09-071-3/+5
| | | | | | | | | | | | | In order for MSVC builds that utilize libjasper to work, we need to ensure that JAS_WIN_MSVC_BUILD is defined when we check for jasper/jasper.h, and that same macro is defined when we compile io-jasper.c on MSVC. We also need to look for libjasper.lib on MSVC in case that jasper.lib cannot be found, as the Visual Studio projects for libjasper produces libjasper.lib upon build. https://bugzilla.gnome.org/show_bug?id=785767
* gif: Fix compiler warning reg. type conversionTobias Mueller2017-08-241-3/+3
| | | | | | | | | | | | | | | | | With -Wconversion gcc complains with the following warning: io-gif.c: In function ‘gif_read’: io-gif.c:246:20: warning: conversion to ‘guint {aka unsigned int}’ from ‘size_t {aka long unsigned int}’ may alter its value [-Wconversion] context->ptr += len; ^ io-gif.c:258:28: warning: conversion to ‘guint {aka unsigned int}’ from ‘size_t {aka long unsigned int}’ may alter its value [-Wconversion] context->amount_needed = len - (context->size - context->ptr); This change simply changes their types to match the rhs. https://bugzilla.gnome.org/show_bug.cgi?id=786261
* build: Allow 'all' shorthand for builtin_loaders build optionChun-wei Fan2017-08-211-2/+2
| | | | | | | | | | To ease packaging of the built binaries, provide an 'all' shorthand for making all the buildable loaders built into the main GDK-Pixbuf library, so that we do not need to distribute them as well, and makes it easier so that one will not have to try to find and enter all the names of the loaders that are shipped with GDK-Pixbuf. https://bugzilla.gnome.org/show_bug.cgi?id=785767
* build: Build the .rc file on WindowsChun-wei Fan2017-08-171-0/+12
| | | | | | | | Like the autotools and Visual Studio builds, include the .rc file in the main GDK-Pixbuf DLL so that people can determine its version info more easily. Determine current - age as we did in the autotools builds. https://bugzilla.gnome.org/show_bug.cgi?id=785767
* build: Fix Meson builds using builtin loadersChun-wei Fan2017-08-171-2/+3
| | | | | | | | | | | | | | | | | We need to ensure that the loaders that are to be built into the main GDK-Pixbuf library is built as follows: -The individual loader sources are built with the corresponding INCLUDE_xxx macro defined. -The GDK-Pixbuf library itself must be built with all of the INCLUDE_xxx macros defined for building the individual loaders that we are building into the main GDK-Pixbuf library There is also a typo for the macro to make the loaders built into the GDK-Pixbuf library, so correct that as well (-DINCLUDED_xxx -> -DINCLUDE_xxx). https://bugzilla.gnome.org/show_bug.cgi?id=785767
* queryloaders: Make output more reproducibleJussi Kukkonen2017-08-151-1/+8
| | | | | | | | | | Reproducible builds are good: Sort the output by module name so that same input always leads to same output. This should also make gdk-pixbuf-print-mime-types output and gdk-pixbuf-thumbnailer.thumbnailer reproducible. https://bugzilla.gnome.org/show_bug.cgi?id=783592
* io-gif: Switch arguments to fread() to fix Coverity issuePhilip Withnall2017-08-151-1/+1
| | | | | | | | | | The arguments were provided the wrong way round: the variable number should always be the nmemb argument, rather than loading a single element of variable size. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=785696
* meson: Use include_directories references throughoutJan Alexander Steffens (heftig)2017-08-131-3/+5
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=785964
* Move all aux scripts to their own directoryEmmanuele Bassi2017-08-032-75/+0
| | | | This makes it easier to find them and reference them.
* io-ico: Add an assertion to clarify buffer managementPhilip Withnall2017-08-031-0/+3
| | | | | | | | | | | The code is correct (the line buffer is set when DecodeHeader() returns successfully with a non-zero-length line), but that’s not at all obvious from the code, and is tripping Coverity up. Add an assertion to make it clearer. Coverity ID: 1400057 https://bugzilla.gnome.org/show_bug.cgi?id=778943
* meson: Support installed testsEmmanuele Bassi2017-08-021-1/+1
| | | | | We want to be able to run the gdk-pixbuf tests after installing them in a known system location, especially when running CI.
* meson: Install enum types header in the right placeEmmanuele Bassi2017-08-021-1/+2
|
* meson: Generate introspection dataEmmanuele Bassi2017-08-021-6/+30
| | | | | | | Just like the Autotools build does. We also provide a simple escape hatch for platforms where building introspection data is too complicated at the moment.
* meson: Use the appropriate name for the shared libraryEmmanuele Bassi2017-08-021-1/+1
| | | | | The name is `gdk_pixbuf-2.0`, not `gdk-pixbuf-2.0`, I guess for historical reasons.
* meson: Add gdk-pixbuf-macros.h to the installed headersEmmanuele Bassi2017-08-021-3/+4
| | | | It was lost in the port.
* Build gdk-pixbuf-marshal.cEmmanuele Bassi2017-08-011-1/+2
| | | | | | Commit 591f959adb0d1f85a869dfc14b9b21a0de8417eb moved to including the header, instead of including the source. This means that we need to build the source, in order to get the marshallers.
* Initial implementation of a Meson buildEmmanuele Bassi2017-08-012-0/+187
| | | | | | | | | | | | | | Meson is a better build system than Autotools that has gotten traction in the GNOME community. The build is pretty much equivalent between Autotools and Meson, but at this point it needs further testing to verify complete matching behaviour. The GDI-plus loaders are not currently built, as that will require access to a platform I don't have in order to test them. Additionally, the API reference is not being generated yet in Meson.
* Include the generated marshallers headerEmmanuele Bassi2017-08-011-1/+1
| | | | | Do not include the source, otherwise we're going to compile symbols twice.
* bmp: Avoid allocating large buffers when not neededBastien Nocera2017-07-281-13/+15
| | | | | | | | | Avoid allocating nearly 6 gigs of data when parsing the CVE-2015-4491 test only to free it when we've calculated that the rowstride * height would overflow by calculating the rowstride before doing the allocation, using the new gdk_pixbuf_calculate_rowstride() helper. https://bugzilla.gnome.org/show_bug.cgi?id=765094
* gdk-pixbuf: Add gdk_pixbuf_calculate_rowstride()Bastien Nocera2017-07-282-13/+53
| | | | | | To calculate the rowstride without allocating memory! https://bugzilla.gnome.org/show_bug.cgi?id=765094
* ico: Return an error when the ICO didn't loadBastien Nocera2017-07-271-1/+10
| | | | | | | | If we don't even read enough data to fill the header, return an error. This doesn't cover everything that could go wrong with the ICO incremental loader, but this is a good first throw. https://bugzilla.gnome.org/show_bug.cgi?id=778204
* io: Fix GError leak in gdk_pixbuf_new_from_stream()Robert Ancell2017-07-271-19/+10
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=783538
* gdk-pixbuf: Tighten rowstride overflow checkBastien Nocera2017-07-271-2/+2
| | | | | | | | | The rowstride is stored as an int, and is an int in the public API. Making it an unsigned int for those calculations would increase the limit, which would obviously cause problems when the calculated value ends up between G_MAXUINT and G_MAXINT in the positives. https://bugzilla.gnome.org/show_bug.cgi?id=765094
* jpeg: Restore grayscale image supportA. Bosch2017-07-271-0/+3
| | | | | | | | | | Commit c2a40a92fe3df4111ed9da51fe3368c079b86926 restricts the jpeg loader to files with 3 or 4 color components. Also allow JCS_GRAYSCALE images with only 1 color component. These grayscale images are supported through explode_gray_into_buf. https://bugzilla.gnome.org/show_bug.cgi?id=785171
* bmp: Tighten image dimension checksBastien Nocera2017-07-261-1/+4
| | | | | | | The rowstride *could* be negative if the pixbuf is invalid. Check that it is valid before using it to sanity check the image's dimensions. See https://bugzilla.gnome.org/show_bug.cgi?id=776694
* ico: Fix icon quality sortingBastien Nocera2017-07-261-2/+2
| | | | | | | Despite the inherited comment, commit 99508c7 sorted the icons by increasing instead of decreasing quality. https://bugzilla.gnome.org/show_bug.cgi?id=785447
* ico: Try to skip over broken icon entriesBastien Nocera2017-07-131-13/+12
| | | | | | | If an icon entry is broken, skip over it, but report the breakage if we could not find a single valid entry. https://bugzilla.gnome.org/show_bug.cgi?id=776040
View Lorry Controller Status