Shell command injection in delegate code (via file names)

[Debian Bug Importer]

Automatically imported from Debian bug report #345238 http://bugs.debian.org/345238

[Florian Weimer (fw)]

severity 345238 grave
thanks

With some user interaction, this is exploitable through Gnus and
Thunderbird. I think this warrants increasing the severity to
"grave".

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #345238 http://bugs.debian.org/345238

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 29 Dec 2005 22:15:19 +0100
From: Florian Weimer <email address hidden>
To: <email address hidden>
Subject: Shell command injection in delegate code (via file names)

Package: imagemagick
Version: 6.2.4.5-0.3
Tags: security

The delegate code in Imagemagick is vulnerable to shell command
injection, using specially crafted file names:

$ cp /usr/lib/openoffice/share/template/en-US/wizard/bitmap/germany.wmf \
  '" ; echo "Hi!" >&2; : "'.gif
$ display '" ; echo "Hi!" >&2; : "'.gif

It should work with other file formats besides WMF (those for which
delegates are defined).

I'm leaving the severity at normal, because it doesn't seem to be
*that* important. Perhaps this is exploitable through MIME-enabled
MUAs, which would warrant a higher severity.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 30 Dec 2005 14:19:27 +0100
From: Florian Weimer <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Shell command injection in delegate code (via file names)

severity 345238 grave
thanks

With some user interaction, this is exploitable through Gnus and
Thunderbird. I think this warrants increasing the severity to
"grave".

[Florian Weimer (fw)]

retitle 345238 [CVE-2005-4601] Shell command injection in delegate code (via file names)
thanks

This issue has been assigned CVE-2005-4601. Please mention this
identifier in the changelog when fixing this bug.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 02 Jan 2006 10:51:51 +0100
From: Florian Weimer <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#345238: Shell command injection in delegate code (via file names)

retitle 345238 [CVE-2005-4601] Shell command injection in delegate code (via file names)
thanks

This issue has been assigned CVE-2005-4601. Please mention this
identifier in the changelog when fixing this bug.

[Daniel Kobras (kobras)]

tag 345238 + patch
thanks

On Fri, Dec 30, 2005 at 02:19:27PM +0100, Florian Weimer wrote:
> With some user interaction, this is exploitable through Gnus and
> Thunderbird. I think this warrants increasing the severity to
> "grave".

Here's the vanilla fix from upstream SVN, stripped off whitespace changes.
I wonder why they've banned ` but still allow $(...), though.

Regards,

Daniel.

[Florian Weimer (fw)]

* Daniel Kobras:

> tag 345238 + patch
> thanks
>
> On Fri, Dec 30, 2005 at 02:19:27PM +0100, Florian Weimer wrote:
>> With some user interaction, this is exploitable through Gnus and
>> Thunderbird. I think this warrants increasing the severity to
>> "grave".
>
> Here's the vanilla fix from upstream SVN, stripped off whitespace changes.
> I wonder why they've banned ` but still allow $(...), though.

> +#define ProhibitedAlphabet "*?\"'<>|`"

This choice of characters is indeed strange. Perhaps some of them are
Windows-related.

> + if ((strpbrk(image_info->filename,ProhibitedAlphabet) != (char *) NULL) ||
> + (strpbrk(image->filename,ProhibitedAlphabet) != (char *) NULL))
> + {
> + ThrowFileException(exception,FileOpenError,
> + "FilenameContainsProhibitedCharacters",image->filename);
> + return(MagickFalse);
> + }

Wrong direction of test. You should only pass on known-good
characters, not reject bad characters.

A better fix would be to bypass the shell and invoke the delegate
directly (using fork and execve). If this is not feasible, the file
name should be translated according to this pseudo-code:

    def translate(name):
        result = '\''
        for char in name:
            if name == '\'':
                result += "'\\''"
            else:
                result += char
        result += '\''
        return result

Using ' instead of " as the string terminator ensures that variable
expansion is disabled in the string. If a single quote is contained
in the input string, it is replaced with '\'' (including the quotes),
which terminates the string processing, inserts a quoted "'"
character, and continues with string processing. This way, all
characters (except ASCII NUL, naturally) can be safely passed through
the shell to the delegate. The delegate, however, must have been
written to deal with arbitrary file names.

Unfortunately, is unlikely work on native Windows because command line
parsing is application-specific.

Please pass this message to upstream nevertheless (I couldn't find a
security contact on their web pages).

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 5 Jan 2006 13:49:11 +0100
From: Daniel Kobras <email address hidden>
To: Florian Weimer <email address hidden>, <email address hidden>
Subject: Re: Bug#345238: Shell command injection in delegate code (via file names)

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

tag 345238 + patch
thanks

On Fri, Dec 30, 2005 at 02:19:27PM +0100, Florian Weimer wrote:
> With some user interaction, this is exploitable through Gnus and
> Thunderbird. I think this warrants increasing the severity to
> "grave".

Here's the vanilla fix from upstream SVN, stripped off whitespace changes.
I wonder why they've banned ` but still allow $(...), though.

Regards,

Daniel.

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename="CVE-2005-4601.diff"

--- delegate.c.orig 2006-01-05 13:37:47.000000000 +0100
+++ delegate.c 2006-01-05 13:45:00.000000000 +0100
@@ -701,6 +701,8 @@
 MagickExport MagickBooleanType InvokeDelegate(ImageInfo *image_info,
   Image *image,const char *decode,const char *encode,ExceptionInfo *exception)
 {
+#define ProhibitedAlphabet "*?\"'<>|`"
+
   char
     *command,
     **commands;
@@ -753,11 +755,11 @@
         }
       image_info->temporary=MagickTrue;
     }
- if (delegate_info->mode != 0)
- if (((decode != (const char *) NULL) &&
+ if ((delegate_info->mode != 0) &&
+ (((decode != (const char *) NULL) &&
          (delegate_info->encode != (char *) NULL)) ||
         ((encode != (const char *) NULL) &&
- (delegate_info->decode != (char *) NULL)))
+ (delegate_info->decode != (char *) NULL))))
       {
         char
           *magick;
@@ -771,6 +773,13 @@
         /*
           Delegate requires a particular image format.
         */
+ if ((strpbrk(image_info->filename,ProhibitedAlphabet) != (char *) NULL) ||
+ (strpbrk(image->filename,ProhibitedAlphabet) != (char *) NULL))
+ {
+ ThrowFileException(exception,FileOpenError,
+ "FilenameContainsProhibitedCharacters",image->filename);
+ return(MagickFalse);
+ }
         if (AcquireUniqueFilename(image_info->unique) == MagickFalse)
           {
             ThrowFileException(exception,FileOpenError,
@@ -850,18 +859,25 @@
   for (i=0; commands[i] != (char *) NULL; i++)
   {
     status=MagickFalse;
+ if ((strpbrk(image_info->filename,ProhibitedAlphabet) != (char *) NULL) ||
+ (strpbrk(image->filename,ProhibitedAlphabet) != (char *) NULL))
+ {
+ ThrowFileException(exception,FileOpenError,
+ "FilenameContainsProhibitedCharacters",image->filename);
+ break;
+ }
     if (AcquireUniqueFilename(image_info->unique) == MagickFalse)
       {
         ThrowFileException(exception,FileOpenError,
           "UnableToCreateTemporaryFile",image_info->unique);
- return(MagickFalse);
+ break;
       }
     if (AcquireUniqueFilename(image_info->zero) == MagickFalse)
       {
         (void) RelinquishUniqueFileResource(image_info->unique);
         ThrowFileException(exception,FileOpenError,
           "UnableToC...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 05 Jan 2006 14:04:39 +0100
From: Florian Weimer <email address hidden>
To: Daniel Kobras <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#345238: Shell command injection in delegate code (via file names)

* Daniel Kobras:

> tag 345238 + patch
> thanks
>
> On Fri, Dec 30, 2005 at 02:19:27PM +0100, Florian Weimer wrote:
>> With some user interaction, this is exploitable through Gnus and
>> Thunderbird. I think this warrants increasing the severity to
>> "grave".
>
> Here's the vanilla fix from upstream SVN, stripped off whitespace changes.
> I wonder why they've banned ` but still allow $(...), though.

> +#define ProhibitedAlphabet "*?\"'<>|`"

This choice of characters is indeed strange. Perhaps some of them are
Windows-related.

> + if ((strpbrk(image_info->filename,ProhibitedAlphabet) != (char *) NULL) ||
> + (strpbrk(image->filename,ProhibitedAlphabet) != (char *) NULL))
> + {
> + ThrowFileException(exception,FileOpenError,
> + "FilenameContainsProhibitedCharacters",image->filename);
> + return(MagickFalse);
> + }

Wrong direction of test. You should only pass on known-good
characters, not reject bad characters.

A better fix would be to bypass the shell and invoke the delegate
directly (using fork and execve). If this is not feasible, the file
name should be translated according to this pseudo-code:

    def translate(name):
        result = '\''
        for char in name:
            if name == '\'':
                result += "'\\''"
            else:
                result += char
        result += '\''
        return result

Using ' instead of " as the string terminator ensures that variable
expansion is disabled in the string. If a single quote is contained
in the input string, it is replaced with '\'' (including the quotes),
which terminates the string processing, inserts a quoted "'"
character, and continues with string processing. This way, all
characters (except ASCII NUL, naturally) can be safely passed through
the shell to the delegate. The delegate, however, must have been
written to deal with arbitrary file names.

Unfortunately, is unlikely work on native Windows because command line
parsing is application-specific.

Please pass this message to upstream nevertheless (I couldn't find a
security contact on their web pages).

[Daniel Kobras (kobras)]

On Thu, Jan 05, 2006 at 02:04:39PM +0100, Florian Weimer wrote:
> A better fix would be to bypass the shell and invoke the delegate
> directly (using fork and execve). If this is not feasible, the file
> name should be translated according to this pseudo-code:

I went for an even more simple fix: pass a temporary, securely named
symlink to external delegates, instead of the user-supplied filename. We
get rid of the problem this way without any restrictions on allowed
characters in filenames. There's still the problem of information
disclosure because the symlink in /tmp displays the full path to the
image file, but I think that's less severe than the original problem.
Furthermore, users can easily circumvent it setting MAGICK_TMPDIR to a
700 directory. Unfortunately, even though the hack should be good enough
for Debian, it is not suitable for upstream because of portability
issues.

> Please pass this message to upstream nevertheless (I couldn't find a
> security contact on their web pages).

Assuming you were referring to me, I'm currently too short on time to act
as an intermediary for problems in packages I'm not even the maintainer
of. Therefore, I'd be grateful if someone else stepped in and worked
with upstream to settle on a long-term solution. I'm not aware of a
specific security contact, but a message to one of their web forums
usually gets fast attention.

Regards,

Daniel.

[Daniel Kobras (kobras)]

tag 344997 + fixed
tag 345238 + fixed
tag 345595 + fixed
tag 345876 + fixed
tag 347486 + fixed

quit

This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 17 Jan 2006 18:33:58 +0100
Source: imagemagick
Binary: perlmagick libmagick9 libmagick9-dev imagemagick libmagick++9-dev libmagick++9c2a
Architecture: source i386
Version: 6:6.2.4.5-0.6
Distribution: unstable
Urgency: high
Maintainer: Daniel Kobras <email address hidden>
Changed-By: Daniel Kobras <email address hidden>
Description:
 imagemagick - Image manipulation programs
 libmagick++9-dev - The object-oriented C++ API to the ImageMagick library--developme
 libmagick++9c2a - The object-oriented C++ API to the ImageMagick library
 libmagick9 - Image manipulation library
 libmagick9-dev - Image manipulation library -- development
 perlmagick - A perl interface to the libMagick graphics routines
Closes: 344997 345238 345595 345876 347486
Changes:
 imagemagick (6:6.2.4.5-0.6) unstable; urgency=high
 .
   * Non-maintainer upload.
   * magick/display.c: In DisplayImageCommand(), expand command line before
     allocating ressources based on argc. Patch and analysis thanks to
     Eero Häkkinen. Closes: #345595
   * magick/{animate.c,blob.c,display.c,image.c,log.c,montage.c,string.c,
     string_.h}: Implement new utility function FormatMagickStringNumeric()
     to securely expand a user-supplied format string with a single numeric
     argument. Adjust code to use this function where appropriate.
     (CVE-2006-0082) Closes: #345876
   * coders/pdf.c,coders/ps.c,magick/delegate.c,magick/delegate.h,
     magick/methods.h: Do not call external delegates with user-supplied
     filename, but with securely named symlinks only to prevent shell command
     injection (CVE-2005-4601). Closes: #345238
   * debian/rules: Make sure to include trailing spaces in multi-line
     commands to keep recent make happy. Cures problems with ghostscript
     font path. Fix thanks to Jeff Lessem. Closes: #347486
   * debian/imagemagick.mime: Rather than autodetect the type of an image,
     derive it from the mime type. As a side effect, this change allows to
     use arbitrary filenames with the 'see' command, even if they have
     special meaning to imagemagick internally. Also clean up some typos
     and superfluous entries once we're at it. Closes: #344997
Files:
 30814283b7a2257d49bc44b0b1b0de97 893 graphics optional imagemagick_6.2.4.5-0.6.dsc
 ea4efd97b724dc512db2a5a9d8fd4581 32179 graphics optional imagemagick_6.2.4.5-0.6.diff.gz
 f611cd8c9f58f199a610b17d1fd6c7dc 1614628 graphics optional imagemagick_6.2.4.5-0.6_i386.deb
 ac0eeefb70766c3ea21eed536e26b7ef 1309702 libs optional libmagick9_6.2.4.5-0.6_i386.deb
 574ca13393d8d0807b11ac4ca6fcf1e6 1662360 libdevel optional libmagick9-dev_6.2.4.5-0.6_i386.deb
 44f050ec89912e6fc5ba42216dc9784b 167724 libs optional libmagick++9c2a_6.2.4.5-0.6_i386.deb
 02a57c2d5427de29e293c99294e5da32 226508 libdevel optional libmagick++9-dev_6.2.4.5-0.6_i386.deb
 bcb5b44c1a9d0f56ef9cc1d9a3acd41c 170192 perl optional perlmagick_6.2.4.5-0.6_i386.deb

-----BEG...

[Daniel Kobras (kobras)]

found 345238 4:5.4.4.5-1woody7
found 345238 6:6.0.6.2-2.5
thanks

On Thu, Jan 05, 2006 at 01:49:11PM +0100, Daniel Kobras wrote:
> On Fri, Dec 30, 2005 at 02:19:27PM +0100, Florian Weimer wrote:
> > With some user interaction, this is exploitable through Gnus and
> > Thunderbird. I think this warrants increasing the severity to
> > "grave".
>
> Here's the vanilla fix from upstream SVN, stripped off whitespace changes.
> I wonder why they've banned ` but still allow $(...), though.

The security updates for woody and sarge (DSA-957) use a backport of
upstream's fix without further modifications, ie. this hole can still be
exploited through $(...) expansion. The following test case works on
woody and sarge with the latest imagemagick security updates installed:

% ls
test$(touch boo).fig
% display 'test$(touch boo).fig'
File "test.fig" does not exist
display: Delegate failed `"fig2dev" -L ps "%i" "%o"'.
% ls
boo test$(touch boo).fig

Regards,

Daniel.

[Martin Schulze (joey-infodrom)]

Daniel Kobras wrote:
> found 345238 4:5.4.4.5-1woody7
> found 345238 6:6.0.6.2-2.5
> thanks
>
> On Thu, Jan 05, 2006 at 01:49:11PM +0100, Daniel Kobras wrote:
> > On Fri, Dec 30, 2005 at 02:19:27PM +0100, Florian Weimer wrote:
> > > With some user interaction, this is exploitable through Gnus and
> > > Thunderbird. I think this warrants increasing the severity to
> > > "grave".
> >
> > Here's the vanilla fix from upstream SVN, stripped off whitespace changes.
> > I wonder why they've banned ` but still allow $(...), though.
>
> The security updates for woody and sarge (DSA-957) use a backport of
> upstream's fix without further modifications, ie. this hole can still be
> exploited through $(...) expansion. The following test case works on
> woody and sarge with the latest imagemagick security updates installed:
>
> % ls
> test$(touch boo).fig
> % display 'test$(touch boo).fig'
> File "test.fig" does not exist
> display: Delegate failed `"fig2dev" -L ps "%i" "%o"'.
> % ls
> boo test$(touch boo).fig

Gnah. You are correct. I'm extending the list of forbidden characters
by $().

Thanks,

 Joey

--
The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin

Please always Cc to me when replying to me on the lists.

[Daniel Kobras (kobras)]

On Fri, Jan 27, 2006 at 10:32:51PM +0100, Martin Schulze wrote:
> Daniel Kobras wrote:
> > On Thu, Jan 05, 2006 at 01:49:11PM +0100, Daniel Kobras wrote:
> > > On Fri, Dec 30, 2005 at 02:19:27PM +0100, Florian Weimer wrote:
> > > > With some user interaction, this is exploitable through Gnus and
> > > > Thunderbird. I think this warrants increasing the severity to
> > > > "grave".
> > >
> > > Here's the vanilla fix from upstream SVN, stripped off whitespace changes.
> > > I wonder why they've banned ` but still allow $(...), though.
> >
> > The security updates for woody and sarge (DSA-957) use a backport of
> > upstream's fix without further modifications, ie. this hole can still be
> > exploited through $(...) expansion. The following test case works on
> > woody and sarge with the latest imagemagick security updates installed:
> >
> > % ls
> > test$(touch boo).fig
> > % display 'test$(touch boo).fig'
> > File "test.fig" does not exist
> > display: Delegate failed `"fig2dev" -L ps "%i" "%o"'.
> > % ls
> > boo test$(touch boo).fig
>
> Gnah. You are correct. I'm extending the list of forbidden characters
> by $().

Upstream has reverted the blacklist and instead went for an improved
version of the symlink fix I added to ImageMagick in unstable. The patch
is more involved, but also more robust and doesn't impose limits on
allowed filenames. If you're interested I can extract the changes from
upstream SVN.

Regards,

Daniel.

[Martin Schulze (joey-infodrom)]

Daniel Kobras wrote:
> > Gnah. You are correct. I'm extending the list of forbidden characters
> > by $().
>
> Upstream has reverted the blacklist and instead went for an improved
> version of the symlink fix I added to ImageMagick in unstable. The patch
> is more involved, but also more robust and doesn't impose limits on
> allowed filenames. If you're interested I can extract the changes from
> upstream SVN.

I've sen your patch and decided against it since it is quite intrusive.
The blacklist approach should be sufficient for the updates in our stable
releases.

Regards,

 Joey

--
The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin

Please always Cc to me when replying to me on the lists.

[Daniel Kobras (kobras)]

On Fri, Jan 27, 2006 at 10:59:34PM +0100, Martin Schulze wrote:
> Daniel Kobras wrote:
> > > Gnah. You are correct. I'm extending the list of forbidden characters
> > > by $().
> >
> > Upstream has reverted the blacklist and instead went for an improved
> > version of the symlink fix I added to ImageMagick in unstable. The patch
> > is more involved, but also more robust and doesn't impose limits on
> > allowed filenames. If you're interested I can extract the changes from
> > upstream SVN.
>
> I've sen your patch and decided against it since it is quite intrusive.
> The blacklist approach should be sufficient for the updates in our stable
> releases.

Yes, but then '(' and ')' are quite commonly found in filenames, so
someone might trip over this change. The previous fix for CAN-2005-0397
already partially broke support for movies and multi-layered images, so
I'm not that happy seeing even more functionality taken away. Hm, how
about we go with the quick fix for now, and I'll prepare a slightly more
complex but less user-visible patch for proposed-updates that you can
review later with your SRM hat on?

Regards,

Daniel.

[Martin Schulze (joey-infodrom)]

Daniel Kobras wrote:
> On Fri, Jan 27, 2006 at 10:59:34PM +0100, Martin Schulze wrote:
> > Daniel Kobras wrote:
> > > > Gnah. You are correct. I'm extending the list of forbidden characters
> > > > by $().
> > >
> > > Upstream has reverted the blacklist and instead went for an improved
> > > version of the symlink fix I added to ImageMagick in unstable. The patch
> > > is more involved, but also more robust and doesn't impose limits on
> > > allowed filenames. If you're interested I can extract the changes from
> > > upstream SVN.
> >
> > I've sen your patch and decided against it since it is quite intrusive.
> > The blacklist approach should be sufficient for the updates in our stable
> > releases.
>
> Yes, but then '(' and ')' are quite commonly found in filenames, so
> someone might trip over this change. The previous fix for CAN-2005-0397

I've decided that they're not dangerous on their own, but only the $
sign, so the patch doesn't touch () at all.

Regards,

 Joey

--
Computers are not intelligent. They only think they are.

Please always Cc to me when replying to me on the lists.

[Matt Zimmerman (mdz)]

This same CVE is also associated with Bug #27952, but that looks like a different issue...please verify

[Martin Pitt (pitti)]

Fixed two months ago in USN-246-1

[Adam D. Barratt (debian-bts-adam-barratt)]

Hi,

You should have recently received (or will soon receive) an e-mail
telling you that I've closed Debian bug #345238 in the imagemagick
package, which you reported.

Due to the fact that the package was uploaded by someone who does not
normally do so, the bug was marked as "fixed" rather than closed.

Debian's bug tracking system now allows for this information to be
recorded in a more useful manner, enabling these bugs to be closed.

Due to the volume of bugs affected by this change, we are unfortunately
not sending individualized explanations for each bug. If you have
questions about the fix for your particular bug or about this email,
please contact me directly or follow up to the bug report in the Debian
BTS.

[It's possible you may receive multiple messages stating that the bug
was fixed in several different versions of the package. There are two
common reasons for this:

  - the bug was fixed in one version but subsequently found to exist
    in a later version

  - the bug existed in multiple distributions (for instance, "unstable"
    and "stable") and was thus fixed in a separate upload to each
    distribution
]

Regards,

Adam

[Adam D. Barratt (debian-bts-adam-barratt)]

# Hi,
#
# Now that the BTS supports version-tracking, bugs that were
# fixed in NMUs but never acknowledged can be marked as
# closed in the relevant version. In the case of the bugs listed
# below, they're marked as release-critical in the version of the
# package to which they apply. The release team need to be able to
# accurately determine whether any of the bugs still affect "etch", so
# they're now being closed with version information.
#
# This doesn't affect the maintainer's ability to tell whether
# the bug is currently fixed in any particular Debian distribution
# as the BTS can now display "bugs open in unstable", "bugs open in
# version X-Y" and so on.
#
# See http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html
# and http://lists.debian.org/debian-devel-announce/2005/10/msg00006.html
# for more information on version tracking.
#
# Separate mails are being sent to each bug's submitter

close 345238 6:6.2.4.5-0.6
close 345238 4:5.4.4.5-1woody8
close 345238 6:6.0.6.2-2.6
close 352714 0.3.14-10.1
close 345595 6:6.2.4.5-0.6
close 345595 4:5.4.4.5-1woody8
close 345595 6:6.0.6.2-2.6
close 345876 6:6.2.4.5-0.6
close 345905 0.2.7-2.sarge2
close 346085 1.0-1.1
close 346244 1.4pre.20050518-0.2
close 346262 0.50.0-1.3
close 346263 2.0.12-1.6
close 346264 1:1.2.3-9.2
close 346284 0.50.0-1.4
close 362912 0.50.0-1.4
close 346485 1.4pre.20050518-0.3
close 346610 1.8-1.1
close 346613 3.7p3-2.1
close 346615 0.8.0-3.1
close 346616 1.1-1.1
close 346617 1.0-7.1
close 346627 0.9.1-13
close 346630 1.1-13.1
close 346634 1.5-3.2
close 346635 0.2.4-4.2
close 346659 0.9.14-1.1
close 346664 0.2.3-1.1
close 346668 3.1.0-5.1
close 346669 1:1.18-2.2
close 346676 1.0.0-2.1
close 349381 1.0.0-2.1
close 346678 0.4.1-1.1
close 346693 0.70-1.1
close 346698 0.2-1.1
close 346699 0.11.46-1.1
close 346705 0.5-2.1
close 346711 3.2.1-3.1
close 346713 3.1.0-7.1
close 347155 3.1.0-7.1
close 346723 0.9.8beta2-4.2
close 346724 2.0.12-8.1
close 346740 1:0.71-1.3
close 346741 0.8.0-1.1
close 346746 0.2002083100+1.0Beta6-2.2
close 346758 1.0-11.1
close 346769 2.5.2.99.pre2+cvs20030224-1.1
close 346772 2.7-3.1
close 346780 2.3.04.3-3.1
close 346782 0.5-5.1
close 346784 5.0.4-2.1
close 346787 3.3.0-5.1
close 346792 2.1a-6.1
close 346797 2.3.02-6.1
close 346807 0.9d-2.1
close 346819 1.2-5.2
close 346821 1.1-1.3
close 346824 2.6-17.1
close 346831 2.2-23.1
close 346836 5.85-3.2
close 346837 3.3.1-8.2
close 346838 2.6-2.1
close 346844 1.0-7.2
close 346852 1:0.5-1.1
close 346864 1.3-2.1
close 346868 9.02-7.1
close 346869 1.10-2.1
close 346870 1.12-13.1
close 346875 0.9.6-1.1
close 346884 1.99.16-8.1
close 346886 0.3-2.1
close 346895 0.6c-1.1
close 346899 0.5.1-1.1
close 346909 8.0.5-11.1
close 347163 8.0.5-11.1
close 346910 1.2-1.1
close 346912 4.0b2-15.2
close 346915 1.9-3-4.1
close 346918 0.9.33-1.1
close 346935 1.2.0-1.1
close 346941 1.1.1-4.1
close 346949 0.85-5.6
close 346952 3.0-9.1
close 346953 1.0.1-2.1
close 346954 0.2.9b-2.1
close 346959 0.5-7.1
close 346962 2.13.2-7.1
close 346966 1.0.3-1.1
close 346969 0.98-6.1
close 346973 1.3.1-4.1
close 346979 1.5-16.1
close 368565 6.3.2-2.1
close 368913 0.4.1-1.2
close 368938 0.3.0-alpha1-8.1
close 368962 3.003-gm1-2.1
...

[Daniel Kobras (kobras)]

Source: imagemagick
Source-Version: 7:6.2.4.5.dfsg1-1

We believe that the bug you reported is fixed in the latest version of
imagemagick, which is due to be installed in the Debian FTP archive:

imagemagick_6.2.4.5.dfsg1-1.diff.gz
  to pool/main/i/imagemagick/imagemagick_6.2.4.5.dfsg1-1.diff.gz
imagemagick_6.2.4.5.dfsg1-1.dsc
  to pool/main/i/imagemagick/imagemagick_6.2.4.5.dfsg1-1.dsc
imagemagick_6.2.4.5.dfsg1-1_i386.deb
  to pool/main/i/imagemagick/imagemagick_6.2.4.5.dfsg1-1_i386.deb
libmagick++9-dev_6.2.4.5.dfsg1-1_i386.deb
  to pool/main/i/imagemagick/libmagick++9-dev_6.2.4.5.dfsg1-1_i386.deb
libmagick++9c2a_6.2.4.5.dfsg1-1_i386.deb
  to pool/main/i/imagemagick/libmagick++9c2a_6.2.4.5.dfsg1-1_i386.deb
libmagick9-dev_6.2.4.5.dfsg1-1_i386.deb
  to pool/main/i/imagemagick/libmagick9-dev_6.2.4.5.dfsg1-1_i386.deb
libmagick9_6.2.4.5.dfsg1-1_i386.deb
  to pool/main/i/imagemagick/libmagick9_6.2.4.5.dfsg1-1_i386.deb
perlmagick_6.2.4.5.dfsg1-1_i386.deb
  to pool/main/i/imagemagick/perlmagick_6.2.4.5.dfsg1-1_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Kobras <email address hidden> (supplier of updated imagemagick package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 28 Apr 2007 18:00:10 +0200
Source: imagemagick
Binary: perlmagick libmagick9 libmagick9-dev imagemagick libmagick++9-dev libmagick++9c2a
Architecture: source i386
Version: 7:6.2.4.5.dfsg1-1
Distribution: unstable
Urgency: high
Maintainer: Luciano Bello <email address hidden>
Changed-By: Daniel Kobras <email address hidden>
Description:
 imagemagick - Image manipulation programs
 libmagick++9-dev - The object-oriented C++ API to the ImageMagick library--developme
 libmagick++9c2a - The object-oriented C++ API to the ImageMagick library
 libmagick9 - Image manipulation library
 libmagick9-dev - Image manipulation library -- development
 perlmagick - A perl interface to the libMagick graphics routines
Closes: 214623 317083 318176 325651 325720 330666 333616 335111 339548 340401 344997 345238 345595 345876 347486 349264 351498 352575 358148 360362 360400 364826 381831 383314 383314 385062 386964 393025 395830 398183 401047 404477 410435 412945 417237 418057 419274 420353
Changes:
 imagemagick (7:6.2.4.5.dfsg1-1) unstable; urgency=high
 .
   * New maintainers.
   * debian/compat: Splice debhelper version out of debian/rules into
     separate file (but don't bump version).
   * debian/control: Adjust jasper dependencies to current package names.
     Closes: #419274, #420353
   * Documentation minors improvements:
     - Manpages says SEE ALSO, not SEE-ALSO. Closes: #333616
     - Escaped specials chars in manpages. Closes: #381831
     - External reference in convert(1). Closes: #398183
     -...