I reviewed libei 1.0.0-0ubuntu2 as checked into mantic.  This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

libei is a library to emulate input, particularly for the Wayland graphics stack. It provides 3 components
  - libei - the library to emulate inputs on the client side
  - libeis - a library to process these inputs on the server side
  - oeffis - a library for communicating with the XDG RemoteDesktop Portal

- CVE History
  - None
- Build-Depends
  - No interesting / security relevant dependencies
- No pre/post inst/rm scripts
- No init scripts
- No systemd units
- No dbus system/session services
- No setuid binaries
- No binaries in PATH
- No sudo fragments
- No polkit files
- No udev rules
- unit tests / autopkgtests
  - No autopkgtests but since this package is just a library with minimal external depencies, I don't think this should be a blocker.
  - unit tests look quite comprehensive:

1/9 libei / unit-tests-utils      OK              0.02s
2/9 libei / unit-tests-ei         OK              0.02s
3/9 libei / unit-tests-eis        OK              0.02s
4/9 libei / unit-tests-oeffis     OK              0.01s
5/9 libei / eierpecken            OK              0.08s
6/9 libei:python / python-black   OK              0.49s
7/9 libei:python / scanner-pytest OK              0.52s
8/9 libei:python / oeffis-pytest  OK              2.58s
9/9 libei:python / protocol-test  OK              6.61s

Ok:                 9
Expected Fail:      0
Fail:               0
Unexpected Pass:    0
Skipped:            0
Timeout:            0

- No cron jobs
- Build logs contain a couple warnings - the second of which should ideally be fixed:
../tools/ei-demo-client.c:102:9: warning: ignoring return value of read declared with attribute warn_unused_result [-Wunused-result]
../src/util-sources.c:311:9: warning: ignoring return value of read declared with attribute warn_unused_result [-Wunused-result]


- No processes spawned
- Memory management
  - Given this is written in C there is suprisingly little dynamic memory management - when malloc() etc are used, the code has a tendency to use assert() to die immediately if memory fails to be allocated. Whilst not very graceful, this is pretty standard in higher order libraries like glib etc so is not really concerning to see it here. In general the code appears quite defensive too.
- File IO
  - Only really used for creating a lock file and reading its own cmdline - again this is quite safe.
- Logging
  - Appears quite careful, no apparent uses of directives that might be vulnerable to string-format attacks etc
- Environment variable usage
  - Only uses XDG_RUNTIME_DIR and its own LIBEI_SOCKET environment variables
- No apparent use of privileged functions
- Uses rand() to assign a non-overlapping token for requests to xdg-desktop-portal - this is fine, they are not expected to be cryptographically secure etc, they just need to be unique within a session
- No use of temp files
- Uses AF_UNIX sockets for local communication
- No use of WebKit
- No use of PolicyKit

- No significant cppcheck results
- One significant Coverity result
  - I reported this upstream https://gitlab.freedesktop.org/libinput/libei/-/issues/43 who fixed it within 24 hours - along with a related issue they noticed
- No significant shellcheck results
- No significant bandit results
  - all issues identified are in the test suite and most can be ignored (ie. use of assert etc.)
- No significant govulncheck results
- No significant Semgrep results

In general libei looks to be quite a well-written and maintained code-base. The upstream is responsive to issues and easy to work with as well.

Security team ACK for promoting libei to main.