#3487: Display problems for mbox-files > 2GiB
------------------------+----------------------
Reporter: antonio@… | Owner: me
Type: defect | Status: assigned
Priority: trivial | Milestone:
Component: mutt | Version: 1.5.21
Resolution: | Keywords: patch
------------------------+----------------------
Changes (by me):
* owner: mutt-dev => me
* status: new => assigned
Old description:
> Forwarding from http://bugs.debian.org/602145
>
> {{{
> I archive some old Mail in mbox files. Recently one of those has become
> larger than 2GiB. Mutt still appears to be able to read the headers
> correctly, but instead of the body it displays some random chunk of the
> mbox file for mails starting after the 2GiB boundary in the mbox. The
> exact conditions appears to be that the body must start before 2GiB for
> everything to work fine, even if the body then crosses the 2GiB barrier.
>
> Here is a collection of what works and what doesn't for mails after the
> 2GiB barrier:
>
> Works:
>
> - Headers are displayed correctly.
>
> - Piping the entire mail to some shell-command.
>
> - Viewing the structure of a MIME-message in the attachmend browser.
>
> - From the attachment browser: Viewing (and piping) some parts of
> MIME-messages, such as a GPG signature.
>
> Doesn't work:
>
> - Displaying the body.
>
> - Verifying GPG-Encrypted messages.
>
> - From the attachment browser: Viewing (and piping) some parts of
> MIME-messages, such as GPG-signed text.
>
> - From the attachment browser: Viewing (and piping) some parts of
> messages such as the body-text of non-multipart mails. I even get a
> different part of the mbox file for the first 5 to 10 tries, until it
> settles to only show me empty text.
>
> The attached perl script will generate a mbox file slightly larger than
> 2GiB on stdout to illustrate the problem. Note that it had to be a
> script because I had to give each mail in the mbox a unique Message-ID,
> otherwise mutt assumes they are all in one thread and takes ages to sort
> the mails for display. In an mbox generated by the unmodified skript the
> last two mails show the broken behaviour.
>
> I suggest to either fix the broken behaviour. If that proves to be too
> difficult, I suggest to refuse opening mbox files larger than 2GiB (at
> least on 32 bit architectures). This smells like some integer overflow
> and those tend to have security implications.
> }}}
New description:
Forwarding from http://bugs.debian.org/602145
{{{
I archive some old Mail in mbox files. Recently one of those has become
larger than 2GiB. Mutt still appears to be able to read the headers
correctly, but instead of the body it displays some random chunk of the
mbox file for mails starting after the 2GiB boundary in the mbox. The
exact conditions appears to be that the body must start before 2GiB for
everything to work fine, even if the body then crosses the 2GiB barrier.
Here is a collection of what works and what doesn't for mails after the
2GiB barrier:
Works:
- Headers are displayed correctly.
- Piping the entire mail to some shell-command.
- Viewing the structure of a MIME-message in the attachmend browser.
- From the attachment browser: Viewing (and piping) some parts of
MIME-messages, such as a GPG signature.
Doesn't work:
- Displaying the body.
- Verifying GPG-Encrypted messages.
- From the attachment browser: Viewing (and piping) some parts of
MIME-messages, such as GPG-signed text.
- From the attachment browser: Viewing (and piping) some parts of
messages such as the body-text of non-multipart mails. I even get a
different part of the mbox file for the first 5 to 10 tries, until it
settles to only show me empty text.
The attached perl script will generate a mbox file slightly larger than
2GiB on stdout to illustrate the problem. Note that it had to be a script
because I had to give each mail in the mbox a unique Message-ID, otherwise
mutt assumes they are all in one thread and takes ages to sort the mails
for display. In an mbox generated by the unmodified skript the last two
mails show the broken behaviour.
I suggest to either fix the broken behaviour. If that proves to be too
difficult, I suggest to refuse opening mbox files larger than 2GiB (at
least on 32 bit architectures). This smells like some integer overflow
and those tend to have security implications.
}}}
--
Comment:
There is a macro LOFF_T for this purpose. Older systems may not have
off_t, so we use LOFF_T and the configure script substitutes the best
possible type available on the system. See the attached patch.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3487#comment:6>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
