BUG.md

gistfile1.txt

I reviewed foo as checked into bar.  This shouldn't be
considered a full audit but rather a quick gauge of maintainability. ANY
OTHER NOTES REGARDING THE NATURE OF THE REVIEW ITSELF.

foo is a FILL IN DESCRIPTION HERE TO DEMONSTRATE YOU HAVE REVIEWED THE
PACKAGE IN ENOUGH DETAIL TO UNDERSTAND WHAT IT IS AND HOW IT WORKS.

FOR EACH OF THE FOLLOWING ADD RELEVANT DETAILS AS NEEDED SO THAT NONE ARE
QUESTION MARKS ANYMORE AND REMOVE THESE ALL-CAPS HINTS.

- CVE History:
  - ANY APPLICABLE COMMENTS ON TIME TO RESOLVE, UPSTREAM RESPONSIVENESS ETC
  - RUN: $UCT/scripts/pkg_history foot
  - RUN: $UCT/scripts/pkg_status foot
- Build-Depends?
  - ENCRYPTION / NETWORKING LIBRARIES IN PARTICULAR
  - CAN USE ldd FOR C OR 'grep import' FOR PYTHON
- pre/post inst/rm scripts?
  - SEE packaging.txt
  - WHAT DO THEY DO?
  - DOES pre/postrm CLEANUP pre/postinst?
- init scripts?
  - SEE packaging.txt
  - WHAT DO THEY DO?
- systemd units?
  - SEE packaging.txt
  - WHAT DO THEY DO?
- dbus services?
  - SEE packaging.txt
  - WHAT DO THEY DO?
- setuid binaries?
  - SEE packaging.txt
  - SETUID BINARIES SHOULD BE TREATED WITH CAUTION AS VULNERABILITIES IN
    THESE COULD LEAD TO PRIVILEGE ESCALATION
- binaries in PATH?
  - SEE packaging.txt
- sudo fragments?
  - SEE packaging.txt
- polkit files?
  - SEE packaging.txt
- udev rules?
  - SEE packaging.txt
- unit tests / autopkgtests?
  - HOW DOES IT INTERACT WITH THE CODE?
  - CAN YOU SUCCESSFULLY RUN THEM LOCALLY?
- cron jobs?
  - SEE packaging.txt
  - WHAT DO THEY DO?
  - ARE THEY SAFE? (SEE LP: #973687)
- Build logs:
  - ERRORS / WARNINGS?
  - LINTIAN FAILURES?

[FOR THE FOLLOWING LOOK AT THE VARIOUS code-*.txt FILES WHICH TRY TO DETECT
 CODE SITES WHICH MAKE USE OF THESE]
- Processes spawned?
  - ARE THEY DONE SAFELY TO AVOID SHELL INJECTION?
  - WHAT IS IT DOING / WHAT IS IT CALLING?
- Memory management?
  - IS IT DONE CAREFULLY / DEFENSIVELY?
- File IO?
  - HOW ARE PATHS TO FILES DETERMINED?
  - HOW ARE FILE CONTENTS SANITIZED?
  - IS umask USED CORRECTLY?
- Logging?
  - IS IT CAREFUL TO AVOID OVERFLOWS / FORMAT STRING VULNS?
- Environment variable usage?
  - ARE THEY SANITIZED?
  - CAN THEY BE ABUSED?
- Use of privileged functions?
- Use of cryptography / random number sources etc?
  - DOES IT VALIDATE CERTIFICATE CHAIN CORRECTLY?
  - DOES IT DO SERVER HOSTNAME CHECKING CORRECTLY (both Common Name and
    Subject Alternate Names)
- Use of temp files?
  - LOOK FOR UNSAFE USE OF /tmp VIA PREDICTABLE NAMES ETC
- Use of networking?
  - LOOK FOR DEFENSIVE CODE WHICH ASSUMES ALL INPUT IS UNTRUSTED
  - IS INPUT FILTERED / SANITIZED?
- Use of WebKit?
- Use of PolicyKit?
  - DOES IT HAVE A PRIVILEGED BACKEND THAT USES POLICYKIT?
  - VERIFY IT EITHER PASSES PID + START TIME + UID, OR PASSES SYSTEM-BUS-NAME
     (ONLY PASSING PID, OR ONLY PASSING PID + START TIME WILL RESULT IN A RACE WHEN POLICYKIT LOOKS UP UID)
     (IE: IF USING THE API, polkit_unix_process_new_for_owner() IS OK, polkit_unix_process_new() AND
      polkit_unix_process_new_full() ARE UNSAFE)

- Any significant cppcheck results?
  - SEE cppcheck.txt
- Any significant Coverity results?
  - SEE coverity.txt
- Any significant shellcheck results?
  - SEE shellcheck.txt
- Any significant bandit results?
  - SEE bandit.txt

FILL IN GENERAL COMMENTS HERE

Security team ACK/NACK for promoting foot to main (FEEL FREE TO INCLUDE
ANY CONDITIONS ON THIS, THINGS TO BE RESOLVED FIRST ETC.)