I reviewed nullboot 0.4.0-0ubuntu1 as checked into kinetic. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

nullboot is a specialized lightweight boot manager for environments that don't need one. It works by directly managing the UEFI boot entries. For TPM enabled systems, it also handles the resealing
of the disk encryption key to support boot asset update operations.

- CVE History:
  - No
- Build-Depends?
  - boot and secure boot related libraries
      - canonical/go-efilib
      - canonical/go-tpm2
      - canonical/tcglog-parser
      - snapcore/secboot
  - crypto libraries
      - go.mozilla.org/pkcs7
      - golang.org/x/crypto
- pre/post inst/rm scripts?
  - single postinst script which runs nullbootctl
- init scripts?
  - No
- systemd units?
  - No
- dbus services?
  - No
- setuid binaries?
  - No
- binaries in PATH?
  - /usr/bin/nullbooctl
- sudo fragments?
  - No
- polkit files?
  - No
- udev rules?
  - No
- unit tests / autopkgtests?
  - efibootmgr folder contains an extensive test suite
  - no testsuite for the main application
- cron jobs?
  - No
- Build logs:
  - Warnings:
    - dh_auto_install: warning: LTO opimize is enable in buildflags. But cgo doesn't support it. LTO flags will be stripped in cgo.
    - dh_golang: warning: LTO opimize is enable in buildflags. But cgo doesn't support it. LTO flags will be stripped in cgo.
    - dpkg-gencontrol: warning: package nullboot: substitution variable ${misc:Static-Built-Using} unused, but is defined
    - update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
  - Lintian warnings:
    - W: nullboot: no-manual-page [usr/bin/nullbootctl]
    - W: nullboot source: unknown-field Go-Import-Path
    - W: nullboot: unknown-field Important
    - W: nullboot: unknown-field Protected
- Processes spawned?
  - multiple calls to Go's `exec.Command` in vendored Go libraries. No issues identified.
- Memory management?
  - Written in Go. No issues identified.
- File IO?
  - No issues.
- Logging?
  - No issues.
- Environment variable usage?
  - only in unreachable paths in vendored code. No issues.
- Use of privileged functions?
  - only in unreachable paths in vendored code. No issues.
- Use of cryptography / random number sources etc?
  - Go's crypto library for hashing.
- Use of temp files?
  - Creation of temp files (where applicable) is done inside trusted directories.
- Use of networking?
  - No
- Use of WebKit?
  - No
- Use of PolicyKit?
  - No

- Any significant cppcheck results?
  - No
- Any significant Coverity results?
  - No. Multiple of low impact in vendored code mostly (see attached coverity.txt for a full list)
- Any significant shellcheck results?
  - No
- Any significant bandit results?
  - No
- govulncheck
  - No. 4 vulnerabilities of negligible impact.
- gosec
  - No but
  - several unhandled errors reported such as (see attached gosec.txt for a full list):
    - efibootmgr/bootmgr.go|122 col 2| binary.Write(optionalData, binary.LittleEndian, efi.ConvertUTF8ToUCS2(entry.Options+"\x00"))
    - efibootmgr/reseal.go|183 col 2| binary.Write(h, binary.LittleEndian, uint32(0))

Most of the automated tools findings were either false positives or of negligible impact.

- On vendoring
The package vendors all of its dependencies, some negligible issues were found in some of them
with govulncheck. Project is maintained on Github and seems to be receiving version updates
for its dependencies with the help of dependabot too.

- Maintenance status
Unsure about the project's maintenance status as it seems to have some open issues for quite
some time:
- https://bugs.launchpad.net/ubuntu/+source/nullboot
- https://github.com/canonical/nullboot/issues

Some of these issues could be easily caught if there was a minimal e2e test suite of sorts that
tests:
- when nullbootctl can run.
- if basic resealing with nullbootctl results in a bootable secure-boot enabled system etc.

General comments:
Rest of the project is coded defensively against the biggest concern which is TOCTOU type
of bugs when hashing and loading PE images and needs to be run as root in order to access
files in sensitive locations.

Security team ACK for promoting nullboot to main.