munpack -t mishandles DOS line endings "=\r\n"

[John Denker]

** Observed behavior: In quoted-printable parts, munpack -t
converts the following string
        =\r\n
to \377 which is not correct. An example input file is attached.

** Expected and desired behavior: munpack -t should interpret
        =\r\n
the same as:
        =\n
and should convert it to the zero-length string. The example
file should produce "foobar" without any unprintable characters.

** Rationale:
1) MIME-encoded files with DOS line endings are extremely common.

2) This bug often makes the output of munpack completely useless.
The problem is insidious, hard to detect, and hard to understand.
An expert can work around it, but not all users are experts.

3) There is no possible downside to interpreting =\r\n as the
zero-length string.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: mpack 1.6-18
ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17
Uname: Linux 5.19.0-41-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.4
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun Apr 30 20:35:31 2023
InstallationDate: Installed on 2022-07-29 (275 days ago)
InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: mpack
UpgradeStatus: No upgrade log present (probably fresh install)

[John Denker (lp-8)]

The ubuntu manpage for munpack says in part:
       Send all bug reports to <email address hidden>.

Alas that is a non-working email address.

Let me know if you want me to file this as a bug against the documentation.

[John Denker (lp-8)]

Intimately related bug, part of the same DOS line-endings syndrome (but not involving =XX encoding):

When the input file uses DOS line endings, munpack -t emits a spurious \r\n at the top of the output file.

Presumably this comes from the blank line that terminates the MIME header metadata, before the actual data content.

Proper handling of DOS line endings will take care of this along with the =\r\n bug.

The same example file (attached above) suffices to demonstrate this. The desired and expected output should be "foobar" with nothing before it.

By way of comparison, when using non-DOS line endings (plain \n), no such spurious blank line is produced.