Comment 17 for bug 1912371

I reviewed libftdi1 1.5-5build1 as checked into impish. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

libftdi1 is a library and CLI tool (ftdi-eeprom) for reading/writing to
FTDI chips used in many USB-Serial converters and other USB peripheral
controllers.

- No CVE History
- Relevant Build-Depends
  - libusb-1.0, libconfuse2
- pre/post inst/rm scripts
  - python3-ftdi contains prerm/postinst scripts auto-generated by
    dh_python3 to precompile its python code
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- binaries in PATH
  - ftdi-eeprom provides:

    -rwxr-xr-x root/root 30952 2020-12-08 19:01 ./usr/bin/ftdi_eeprom

    which is a CLI tool to read/write to the EEPROM of FTDI chips

  - libftdi1-dev provides:

    -rwxr-xr-x root/root 1276 2020-12-08 19:01 ./usr/bin/libftdi1-config

    which is a CLI tool similar to pkg-config, used to get CFLAGS/LDFLAGS
    for applications that want to link against libftdi
- No sudo fragments
- No polkit files
- No udev rules
- No cron jobs
- unit tests / autopkgtests
  - unit tests are run during the build - this does a very test to just
    init the library, and also to test the code which calculates baud rates
  - autopkgtest runs the same tests as the unit test but recompiles it from
    scratch
  - these tests are only very basic so it would be useful for more tests to
    be added to ensure other parts of libftdi1 are tested to avoid any
    regressions on future changes
- No significant warnings/errors etc seen in the build logs

- No processes spawned
- Memory management appears to be careful and defensive, return values are
  checked on allocation and bounds are respected on memcpy(), memmove() is
  used where appropriate etc
- File IO
  - libftdi does no direct file IO - libusb is used to interface with USB
    devices, whilst ftdi-eeprom uses a configuration file which is handled
    by libconfuse2 - the path to this is specified on the command-line
- No logging in libftdi other than printing errors when failing to parsing
  configuration options in ftdi-eeprom - these are safe from format string
  vulns
- No environment variable usage
- No use of privileged functions
- No use of cryptography / random number sources etc
- No use of temp files
- No use of networking
- No use of WebKit
- No use of PolicyKit

- No significant cppcheck results
- No significant Coverity results (all false-positives or just minor issues
  in test/example code, not in the actual library/application code)

libfdti1 appears well written and quite defensive, plus seems well
maintained upstream and does not have any history of security
issues. Whilst there is some small unit tests already present it would be
useful if these could be expanded to test more of the functionality of the
library etc to try and ensure any future regressions that may be introduced
via security updates etc can be caught in testing before being released.

Security team ACK for promoting libftdi1 to main.