Comment 16 for bug 1912371

I reviewed flashrom 1.2-5ubuntu1 as per the debdiff attached to this bug as
applied to 1.2-5 in impish. This shouldn't be considered a full audit but
rather a quick gauge of maintainability.

flashrom is a tool used for reading and flashing BIOS/ROM/firmware onto the
various flash chips within a machine - this can include the UEFI BIOS or
optionROMs plus other devices like NICs etc.

- No CVE History
- Relevant Build-Depends:
  - libpci-dev, libusb-1.0-0-dev, libftdi1-dev
- No pre/post inst/rm scripts
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- 1 binary in PATH
  - /usr/sbin/flashrom
- No sudo fragments
- No polkit files
- 1 udev rules
  - Grants read/write access to the various specific USB devices for users
    in the plugdev group
- Includes unit tests run during build and autopkgtests to do more
  system-level testing via dummy devices
- No cron jobs
- Build logs:
  - No significant warnings during the build other than the following
    lintian issues:
E: libflashrom1: symbols-file-contains-current-version-with-debian-revision on symbol LIBFLASHROM_1.0@LIBFLASHROM_1.0 and 23 others
W: flashrom: appstream-metadata-missing-modalias-provide lib/udev/rules.d/60-flashrom.rules
W: flashrom source: illegal-runtime-test-name emulated_programmer.sh in line 1

- Processes spawned
  - Uses popen() to call dmidecode() to read various hard-coded
    identifiers - as these are hard-coded there is no chance for these to
    be used for command injection so whilst this is a bit ugly it is safe.
- Memory management
  - Being written in C there is a lot of dynamic memory management via
    malloc, realloc and free etc - but in general these seem quite
    defensive, with return values being checked and no instances that I
    could see with obvious chance for integer overflow when calculating
    sizes to allocate etc.
- File IO
  - Opens and reads from a number of hard-coded paths or from paths as
    specified via command-line arguments
  - Can dump out to a user-specified path as well
- Logging
  - Lots of printf() style logging but again this looks pretty defensive
- No environment variable usage
- Uses various privileged ioctl() calls so likely would need to be run as
  root in these cases but again I don't see any obvious chance to abuse
  this
- No use of cryptography / random number sources
- No use of temp files
- Use of networking
  - Supports connecting to a remote serial programmer over TCP/IP - this is
    treated as trusted like a real device
- No use of WebKit
- No use of PolicyKit

- No significant cppcheck/coverity results

flashrom appears to be reasonably defensively written and does not have a
history of security issues, whilst the upstream project seems relatively
healthy so should likely be responsive and supporting for any potential
future security issues.

Security team ACK for promoting flashrom to main assuming this includes the
changes from comment:14 above - can the lintian issues highlighted earlier
please be investigated?