1. 01 Jan, 2018 4 commits
    • Michael Natterer's avatar
      Bug 776994 - Gimp fails to open corrupted JPG image · abcf372d
      Michael Natterer authored
      Load as much of a broken/truncated JPEG as possible:
      
      As soon as loading the scanlines has started, set a new setjmp()
      location that doesn't abort loading alltogether but keeps the loaded
      part of the image.
      abcf372d
    • Tobias Stoeckmann's avatar
      Bug 789612 - Prevent heap overflow in GBR parser · 764056e1
      Tobias Stoeckmann authored
      It is possible to trigger a heap overflow with insanely large GBR
      files with a deprecated file format on 32 bit systems.
      
      The problem is that old versions of GBR allowed an additional pattern
      after the brush data. These patterns have always 4 bytes per pixel,
      but the initial size check is performed with the bytes per pixel of
      the brush, which can be different.
      
      If the brush has 1 byte per pixel and the dimensions are sufficiently
      large, this can trigger a heap overflow with attacker-controlled
      amount and content of data.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
      764056e1
    • Massimo Valentini's avatar
      Bug 783336: exported openraster (.ora) missing... · cd4a0a18
      Massimo Valentini authored
      ...mergedimage.png
      
      fix also the thumbnail creation, that:
      must be 8 bit; should not be upscaled; should not have frame
      or decoration, that I interpreted as when there are transparent
      areas they should not be blended with a background color,
      so instead of image_flatten use  image_merge_visible_layers
      (also for the merged_image)
      cd4a0a18
    • Alexis Wilhelm's avatar
      Bug 663576 - make -C plug-ins/script-fu check-for-deprecated-procedures-in-script-fu... · a51efd09
      Alexis Wilhelm authored
      ...lists files that do not use deprecated functions
      
      Better regex that matches the right stuff.
      a51efd09
  2. 31 Dec, 2017 2 commits
  3. 29 Dec, 2017 1 commit
  4. 26 Dec, 2017 3 commits
  5. 25 Dec, 2017 1 commit
  6. 23 Dec, 2017 1 commit
  7. 22 Dec, 2017 4 commits
    • Jehan's avatar
      Bug 791514 - Cannot export to webp file. · 317f7fa5
      Jehan authored
      fopen() modes "wb+" and "w+b" are aliases of the same opening mode
      (truncate/create in binary read/write). But it turns out that Windows
      implementation does not understand "wb+". The alias "w+b" works fine in
      my tests.
      317f7fa5
    • Jehan's avatar
      plug-ins: clean the rest of the file-fli plug-in. · eb218190
      Jehan authored
      While I am at it, let's just do all the files in there. Other also had a
      bunch of tabs and wrong coding style.
      eb218190
    • Jehan's avatar
      plug-ins: clean-up coding style of fli plug-in code. · 375b7679
      Jehan authored
      There should be absolutely no code change semantic in this commit. If
      there is, that's a mistake and it's on me. I only cleaned up the syntax
      in the C file which basically was following none of GIMP coding style
      (tabs everywhere, brackets at end of lines, nearly no space anywhere so
      all the code was a compressed mess which was hard to read, indentation
      absolutely wrong everywhere, etc.).
      I cleaned it up with a bunch of regexp search-and-replace followed by a
      lot of manual cleaning and verification as well.
      
      I also tested with various FLI files found on the web, and they were
      loading fine in GIMP. So I believe/hope that I didn't mess up somewhere,
      but it looks as the cleaning went all fine.
      375b7679
    • Tobias Stoeckmann's avatar
      Bug 739133 - (CVE-2017-17785) Heap overflow while parsing FLI files. · edb251a7
      Tobias Stoeckmann authored
      It is possible to trigger a heap overflow while parsing FLI files. The
      RLE decoder is vulnerable to out of boundary writes due to lack of
      boundary checks.
      
      The variable "framebuf" points to a memory area which was allocated
      with fli_header->width * fli_header->height bytes. The RLE decoder
      therefore must never write beyond that limit.
      
      If an illegal frame is detected, the parser won't stop, which means
      that the next valid sequence is properly parsed again. This should
      allow GIMP to parse FLI files as good as possible even if they are
      broken by an attacker or by accident.
      
      While at it, I changed the variable xc to be of type size_t, because
      the multiplication of width and height could overflow a 16 bit type.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
      edb251a7
  8. 21 Dec, 2017 8 commits
  9. 20 Dec, 2017 4 commits
  10. 17 Dec, 2017 6 commits
  11. 16 Dec, 2017 2 commits
    • Jehan's avatar
      plug-ins: add a SCREENSHOT_CAN_SHOOT_WINDOW capability. · 80490a2c
      Jehan authored
      And add the relevant option for when such capability is absent. Right
      now it is absent only from the new Freedesktop API.
      80490a2c
    • Jehan's avatar
      plug-ins: implementation of the Freedesktop portal for screenshot. · 53a03b38
      Jehan authored
      I am told by the GNOME/Flatpak people that this is what we will
      ultimately need to implement. Basically this portal is supposed to work
      everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
      of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
      should be the unique API we will have to implement in the end, and every
      desktop environment/sandbox will need to implement this API (which is
      good!).
      Apparently it is not part of default GNOME yet, but has to be installed
      separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
      xdg-desktop-portal-kde for KDE).
      
      Now there are currently many shortcomings, and in particular, the
      screenshot API has apparently no advanced features (at all!). No window
      snap, no rectangular selection, no delaying, no choice on including
      cursor or decoration, nothing! Apparently this is normal that the API
      presents no feature, because "the API itself is not meant to specify the
      details how the screenshot is obtained. Instead the portal will present
      the user a dialog to take a screenshot, and that screenshot will be
      given back to the sandboxed app".
      This is acceptable behavior, except that currently, the dialog has none
      of the basic features so this is a very bad regression. This is why I
      test the freedesktop API last, which basically means it will likely
      never be actually used. That's on purpose. At least, the code is in and
      will be easy to improve later. Of course, when the Freedesktop portal
      for screenshot will finally be featureful, it is meant to be tested
      first.
      
      See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
      53a03b38
  12. 13 Dec, 2017 2 commits
    • Jehan's avatar
    • Jehan's avatar
      Bug 791397 - Gimp import multi page PDF only imports first page. · a207570c
      Jehan authored
      Poppler and poppler-data are now hard dependencies.
      PDF is a common-enough format nowadays that import support is likely
      considered as a granted feature by everyone. Moreover the current
      fallback to the PostScript plug-in for PDF support just gives a degraded
      experience with less features (and probably a lot of bugs since
      basically nobody uses this code).
      Poppler-data is also considered mandatory because non-western language
      support should never be considered an "option". People using non-western
      languages are not second class citizens and therefore if we say that PDF
      import is now a hard feature, it should also include PDF using CJK or
      Cyrillic languages.
      a207570c
  13. 12 Dec, 2017 1 commit
  14. 10 Dec, 2017 1 commit
    • Jehan's avatar
      plug-ins: auto-detect HGT variants. · e0c36f3e
      Jehan authored
      Since SRTM-1 and SRTM-3 data have a fixed image size, it is actually
      very easy to auto-detect these by checking the file size. There is no
      need to ask the user to select between the 2 variants (even though these
      values are made quite obvious by official download links).
      I still left the dropdown appear optionally if the detection fails for
      some reason (we never know, at least that makes a fallback, for instance
      to be able to load partial data!). Yet now by default, HGT file settings
      should be fully auto-detected.
      e0c36f3e