Comment 6 for bug 2031491

I reviewed `libemail-simple-perl` `2.218-1` as checked into mantic. This
shouldn't be considered a full audit but rather a quick gauge of
maintainability.

`libemail-simple-perl` is a Perl module that deals with parsing RFC2822 headers
and message format. The RFC defined the syntax for text-based "electronic mail"
messages. It obsoleted RFC 822 and was obsoleted by RFC 5322.

The package provides a Perl module that exposes an object with two constructors:
- `Email::Simple->new`, which parses a string that represents the email; and
- `Email::Simple->create`, which takes multiple parameters for each
characteristic of the email (for example, `body`).

All members and methods of the object are listed here:
https://metacpan.org/pod/Email::Simple#METHODS.

- CVE History
  - No CVE assigned
  - There is no security issue listed in the `CHANGELOG` or reported in the
GitHub issues (`rjbs/Email-Simple`).
  - In the past, there were algorithmic complexity issues
(`rjbs/Email-Simple#8` and `8b6843d55296783ba28e679a877853dff5a17be6`) that
eventually ended up impacting the availability of the module and the
applications using it. These were fixed rapidly and with minimal changes, so
they imply minimal security concerns.
- Build-Depends
  - The single dependency that the module has is `libemail-date-format-perl`.
It is only called once, for getting an RFC 2822-formatted date string.
- pre/post inst/rm scripts
  - N/A
- init scripts
  - N/A
- systemd units
  - N/A
- dbus services
  - N/A
- setuid binaries
  - N/A
- binaries in PATH
  - N/A
- sudo fragments
  - N/A
- polkit files
  - N/A
- udev rules
  - N/A
- unit tests / autopkgtests
  - N/A
- cron jobs
  - N/A
- Build logs
  - N/A

- Processes spawned
  - N/A
- Memory management
  - N/A
- File IO
  - The module operates only with parameters (for example, the email to be
parsed), so no files are involved at all in the code of the module.
  - Files are opened only in the tests from the `t/` folder.
- Logging
  - The module uses `croak()` and `carp()` from the `Carp` module to create
warnings or errors. The original filename and line number (pointing to the
implementation of the library) are changed with the details of the caller from
the user script.
- Environment variable usage
  - N/A
- Use of privileged functions
  - N/A
- Use of cryptography / random number sources etc
  - N/A
- Use of temp files
  - N/A
- Use of networking
  - N/A
- Use of WebKit
  - N/A
- Use of PolicyKit
  - N/A

- Any significant cppcheck results
  - N/A
- Any significant Coverity results
  - Coverity doesn't have support for Perl (as per Coverity's SAT-27514 ticket).
- Any significant shellcheck results
  - N/A
- Any significant bandit results
  - N/A
- Any significant govulncheck results
  - N/A
- Any significant Semgrep results
  - N/A

Another aspect that was checked is the Regex processing (matching, splitting,
and substitution). The points at which injections may have been leading to a
Regex-based denial of service (ReDoS) were dynamically tested. They are safe.

The audit also leveraged fuzzing with an instrumented build of the Perl
interpreter, a custom harness, and AFL++. No issue was detected during the
fuzzing session.

The repository has a few commits and issues. Since 2018, those have been fewer
and fewer (https://github.com/rjbs/Email-Simple/blob/main/Changes), and the
issues starting from that year are still unresolved
(https://github.com/rjbs/Email-Simple/issues?q=is%3Aopen+is%3Aissue). Combining
this information with the lack of a security policy, private reporting, README,
licence, and contact information, it is unclear how well the repository is
maintained and if the maintainer can promptly respond to future security issues
in the package.

Despite the codebase doesn't raise immediate security concerns that may block
the MIR process, the Security team proposes a conditional ACK for promoting
`libemail-simple-perl` into main. The owning team (namely, the Ubuntu Server
Team) needs to commit to the development and testing of security patches for
all Ubuntu releases if we lack upstream support. In addition, the same team
should ask for demoting the package if a more suitable package can be used as
an alternative for `libemail-simple-perl`.

Thanks!