Receiving consistent FRU (Field Replaceable Unit) information is critical to managing IPMI. Open GitHub issues such as "`fru print` exit status depends on the last processed item" gives me strong reservations about this package. I ended the review prematurely after reading build logs and reading through upstream's GitHub repo.

These are my notes.

* create a new no-change rebuild of ipmitool against openssl3 security updates
* Debian has not updated in awhile
  * https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1971281
* are all patches still relevant?
* upstream repo: https://github.com/ipmitool/ipmitool/
* tests could be built with https://github.com/ipmitool/fake-ipmistack
  * also see https://github.com/ipmitool/ipmitool/pull/338
* related tools in main: freeipmi, openipmi, and ipmiview
* related tools in universe: freeipmi

* github issues and pull requests:
  * 82 open issues and 54 open pull requests
  * many issues may relate to discrepancies caused by BMC
  * pull requests to fix issues are not being reviewed
  * several password related
    * https://github.com/ipmitool/ipmitool/issues/347
    * https://github.com/ipmitool/ipmitool/issues/229 (also see PR #243)
  * dev on exit codes:
    * "I'd say that ipmitool is generally very inconsistent about exit codes, and needs major refactoring regarding that."
    * https://github.com/ipmitool/ipmitool/issues/326
  * PRs are force merged and not closed--difficult to tell state of project
    * appears that build tests fail and block merge, so maintainers force push patches and leave PR open (?)
    * https://github.com/ipmitool/ipmitool/pull/63
    * https://github.com/ipmitool/ipmitool/pull/214
    * https://github.com/ipmitool/ipmitool/pull/110
    * https://github.com/ipmitool/ipmitool/pull/171
  * many PRs being blocked by CodeFactor
      * e.g., https://github.com/ipmitool/ipmitool/pull/338/checks?check_run_id=5764904551
  * PRs to patch FRU code discouaged by devs
    * https://github.com/ipmitool/ipmitool/pull/209
    * """I'm not surpised. As I said here: #191 (comment), the fru code is inherently awful. In general it's a "HERE BE DRAGONS" territory. I'm not sure I will accept your PR before the rewrite of fru is done."""
    * From referenced comment:
      * "The whole fru support is rusty, buggy, spaghetti-like and generally awful."
      * https://github.com/ipmitool/ipmitool/pull/191#issuecomment-659721389
  * claim that CVE-2020-5208 patch created unsolved regression
    * https://github.com/ipmitool/ipmitool/pull/191#issuecomment-661109548

* many -Wsign-compare and -Wpointer-sign warnings during build
  * e.g., helper.c's __min definition has sign comparison warning. __min variable used by memcpy often
  * -Wsign-compare warning in 'ipmi_gendev_write_file' during `if(fileLength != eeprom_size)` (!!!)
* many -Wformat, -Wlto-type-mismatch, -Wmaybe-uninitialized warnings
* many -Warray-bounds, especially in ipmp_fru.c
* -Wtype-limits (ipmi_ime.c:895 always false)
* code in ipmi_fru.c `if (((header.offset.internal * 8) > (header.offset.internal * 8)) &&` always False
  * dates back to 2005's 6514de2b139f58620bc08ef0659816c6b6ef44ef
  * pattern repeats many times across several files
* -Wstringop-overflow MANY times (!)

Changes between ipmitool-1.8.18-11ubuntu2 and current upstream (4d25a93f4922885c3d557bf4f9a83968ad2edee9) has addressed some build warnings:

warning type count:  1.8.18-11ubuntu2 -> upsteam
sign-compare: 62 -> 57
pointer-sign: 13 -> 11
format: 98 -> 87
lto-type-mismatch: 4 -> 0
maybe-uninitialized: 16 -> 5
array-bounds: 25 -> 0
type-limits: 2 -> 2
stringop-overflow: 8 -> 8

Security Team NAKs promotion of ipmitools to main. After FRU code is rewritten, build warnings are addressed, tests are added, and (ideally) the GitHub backlog is cleaned this package will be ready for a new MIR.