I reviewed libsdl2 2.0.14+dfsg2-3 as checked into impish.  This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

libsdl2 is a replacement for libsdl1.2 and provides abstractions over
access to video devices, audio, and input devices, often used by games or
game engines and other applications wishing to provide user interfaces.

- CVE History:
  - 16 historical CVEs over a large code-base written in C
    - I expected more to be honest so this is encouraging
- Build-Depends
  - Large list of depends, none out of the ordinary or sensitive
- No pre/post inst/rm scripts
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- 1 binary in PATH from the libsdl2-dev package:
  - -rwxr-xr-x root/root      1307 2021-01-19 01:05 ./usr/bin/sdl2-config
  - this is equivalent of pkg-config and is used to get cflags/ldflags etc
    when compliling and application against libsdl2
- No sudo fragments
- No polkit files
- No udev rules
- No cron jobs
- unit tests / autopkgtests
  - No unit tests run during build that I could see but autopkgtests
    include a basic test to ensure compiling against libsdl2-dev works via
    both cmake and using pkg-config directly
- Build logs:
  - Lots of doxygen related noise in the build logs but nothing of note.

- No Processes spawned
- Memory management is all manual
  - libsdl2 is written in C so all memory management is done manually,
    however looking over a sample of the code this looks relatively careful
    and defensive. There were some instances where callers would not check
    for a NULL return value on memory allocation (which could occur when no
    memory is available), however this likely would only lead to a crash on
    a NULL ptr dereference in subsequent code and hence a denial-of-service
    but given these cases occur when low on memory anyway the impact is not
    much different so they are not too concerning.
- File IO
  - Open joystick device-files etc and these are names are detected by
    walking sysfs etc so are safe from untrusted input
- Logging appears to be careful to avoid format string vulns etc
- Uses lots of environment variables to allow to specify various device
  names or even location of configuration files etc. Whilst they might be
  able to be abused by the user of the library, since libsdl2 is a library
  it does not have elevated privileges to cause any effect as a result so
  this is generally not likely to be an issue.
- Lots of use of privileged functions (e.g. ioctl()) but this is expected
  and again not likely able to cross any security boundary
- No use of cryptography / random number sources etc
- No use of temp files
- No obvious use of networking
- No use of WebKit
- No use of PolicyKit

- No significant cppcheck results
- A large number of issues reported by Coverity, most are likely false
  positives or perhaps of low impact, again since the use of libsdl2 does
  not cross a privilege boundary

For a very large library written in C, libsdl2 is in better shape than I
had feared. The extensive use of manual memory management and the handling
of various APIs and devices means there would be a lot of scope for errors
but I did not see any evidence of anything that would give me significant
cause for concern.

Security team ACK for promoting libsdl2 to main.