GNU bug report logs - #36773
27.0.50; Accessing a cached SVG with eww can cause Emacs to crash

Previous Next

Full log

Message #47 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, plaiceadam <at> gmail.com, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Thu, 25 Jul 2019 14:14:43 +0000

[Message part 1 (text/plain, inline)]

On Thu, Jul 25, 2019 at 12:55 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Thu, 25 Jul 2019 11:51:16 +0000
> > Cc: Adam Plaice <plaiceadam <at> gmail.com>, 36773 <at> debbugs.gnu.org
> >
> > > Perhaps url-store-in-cache should take a parameter to remove the
> > > Content-Encoding header (i.e. "gzip")?  It should really be up to the
> > > program that uses url.el (i.e. shr) whether to cache the data or not...
> >
> > I misread what you wrote at first, but I like my misreading better:
> > url-handle-content-transfer-encoding modifies the message, but not its
> > headers. Why shouldn't it do both?
>
> Yes, I think it should.  Because that's the root cause of the problem:
> the data is uncompressed, but the headers still say it is compressed.

Okay, I think it's likely we're going to require something similar for
other headers, so I added an argument to mail-fetch-field to delete
the fetched field's header line(s).

Patches attached (the first should be unmodified). Appears to work here.

[0001-Don-t-crash-when-parsing-bad-SVG-data-bug-36773.patch (text/x-patch, attachment)]

[0002-Don-t-double-decompress-cached-HTTP-responses-bug-36.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.