Comment 15 for bug 1935082

I reviewed egl-wayland 1:1.1.7-2build1 as checked into impish. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

egl-wayland is a bit of graphics glue. I don't understand what it does.

- CVE History:
  Nothing in our database
- Build-Depends?
  debhelper-compat (= 12),
   eglexternalplatform-dev,
   libegl1-mesa-dev,
   libwayland-dev,
   libwayland-egl-backend-dev,
   meson,
   pkg-config,
- pre/post inst/rm scripts?
  none
- init scripts?
  none
- systemd units?
  none
- dbus services?
  none
- setuid binaries?
  none
- binaries in PATH?
  none
- sudo fragments?
  none
- polkit files?
  none
- udev rules?
  none
- unit tests / autopkgtests?
  none :(
- cron jobs?
  none
- Build logs:
  clean

- Processes spawned?
  None
- Memory management?
  Mostly good; some malloc() calls may invite integer overflows, but
  untrusted inputs to the functions can probably do worse than this.
- File IO?
  None
- Logging?
  Very little, looked safe.
- Environment variable usage?
  Very little, looked safe
- Use of privileged functions?
  none
- Use of cryptography / random number sources etc?
  none
- Use of temp files?
  none
- Use of networking?
  This *can* use TCP, which is surprising to me, but it's a third-place
  fallback, and the server has gone to efforts to accept a single
  connection. I don't love it.
- Use of WebKit?
  none
- Use of PolicyKit?
  none

- Any significant cppcheck results?
  only false positives
- Any significant Coverity results?
  a few unrelated things, a handful of very low severity things
- Any significant shellcheck results?
  none
- Any significant bandit results?
  none

I don't really understand what this package does, but it's short and seems
to be professionally programmed, with the exception of lacking tests. That
might be difficult if it relies upon specific hardware but it does mean
that the security team will need assistance from the owning team to test
updates.

Security team ACK for promoting egl-wayland to main conditional upon the
owning team comitting to assisting with tests when necessary.

Here's a handful of minor things I found while reviewing the package:

wlEglCreatePbufferSurfaceHook() surface might be leaked in second goto fail

wlEglCreateStreamProducerSurfaceHook() surface might be leaked in second goto fail

wlEglGetPlatformDisplayExport() if (display->ownNativeDpy) NULL derefence,
via goto fail

assignWlEglSurfaceAttribs(), wlEglCreateStreamAttribHook(),
wlEglChooseConfigHook(), use unguarded
integer operations in arguments to malloc(); overflows are very unlikely
since they depend upon memory arrays being passed in with the correct
formats. Probably fine.