Ubuntu
libei package

[MIR] libei

Bug #2031406 reported by Jeremy Bícha on 2023-08-15

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	libei (Ubuntu)	Fix Released	High	Unassigned

Bug Description

[Availability]
- The package libei is already in Ubuntu universe.
- The package libei builds for the architectures it is designed to work on.
- Link to package https://launchpad.net/ubuntu/+source/libei

[Rationale]
- The package libei is required in Ubuntu main as a new required dependency for Mutter 45
- The package libei will generally be useful for a large part of our user base
- The package libei is a new runtime dependency of package mutter that we already support
- There is no other/better way to solve this that is already in main or should go universe->main instead of this.

The package libei is required in Ubuntu main no later than August 17 due to Ubuntu 23.10 Feature Freeze. Obviously, that's an unrealistic deadline but the dependency is in mantic-proposed now (some other work is necessary for mutter to migrate out of mantic-proposed). It might be possible to temporarily vendor libei into Mutter.

[Security]
- No CVEs/security issues in this software in the past (new software, only packaged now in Ubuntu)

- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024).
- Package does not expose any external endpoints
- Packages does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...)

libei is a library for emulated input. It can forward physical or logical device input for use by things like GNOME Remote Desktop or sandboxed apps or for fake input for automated actions (like could be done with xdotool).

[Quality assurance - function/usage]
- The package works well right after install

[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/libei/
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libei (not in Debian yet)
- Upstream https://gitlab.freedesktop.org/libinput/libei/-/issues

[Quality assurance - testing]
- The package runs a test suite on build time, if it fails it makes the build fail, link to build log
https://launchpad.net/ubuntu/+source/libei/1.0.0-0ubuntu2

Note that the build test failures are temporarily ignored on s390x which is not a supported Ubuntu Desktop architecture, but the issue has been reported upstream and is being worked on:
https://gitlab.freedesktop.org/libinput/libei/-/issues/41

- The package does not run an autopkgtest because we haven't written one yet. We may run upstream's build test with our autopkgtest architecture.

- Some tests using libei also have been added to Mutter and we do run Mutter's tests both at build time and as installed tests with autopkgtest
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628/commits

[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field

- Please link to a recent build log of the package
https://launchpad.net/ubuntu/+source/libei/1.0.0-0ubuntu2

- Please attach the full output you have got from `lintian --pedantic` as an extra post to this bug.
- Lintian overrides are not present

- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies

- The package will be installed by default, but does not ask debconf questions higher than medium

- Packaging and build is easy, link to debian/rules
https://salsa.debian.org/jbicha/libei/-/blob/debian-unstable/debian/rules

[UI standards]
- Application is not end-user facing (does not need translation)

[Dependencies]
- No further depends or recommends dependencies that are not yet in main

[Standards compliance]
- This package correctly follows FHS and Debian Policy

[Maintenance/Owner]
- Owning Team will be Desktop Packages
- Team is not yet, but will subscribe to the package before promotion

- This does not use static builds

- The team Desktop Packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates and backports to the security team for any affected vendored code for the lifetime of the release (including ESM).

Currently, the libei packaging includes a vendored copy of munit since munit is not packaged for Debian or Ubuntu yet. This is an optional build-time dependency only used by the test suite and does not add any run-time dependencies.
https://github.com/nemequ/munit

- This package uses vendored code, refreshing that code is…
… done with uscan's "component" feature for multiple upstream orig tarballs. debian/watch is set to track munit HEAD and updates will be automatically included when packaging new upstream releases of libei. A similar approach was done for editorconfig-core which was promoted to Main last year.

- The package has been built in the archive more recently than the lasttest rebuild

[Background information]
- The Package description explains the package well
- Upstream Name is libei
- Link to upstream project https://gitlab.freedesktop.org/libinput/libei

Timo has agreed to review this package for inclusion in Debian under the Debian X Strike Force team.

See original description

Tags:

Revision history for this message

Jeremy Bícha (jbicha) wrote on 2023-08-15:

I: libei source: adopted-extended-field (in section for source) XSBC-Original-Maintainer [debian/control:5]

I: Lintian run was successful.

description:	updated
tags:	added: mantic
description:	updated

Lukas Märdian (slyon) on 2023-08-15

Changed in libei (Ubuntu):
assignee:	nobody → Lukas Märdian (slyon)

Jeremy Bícha (jbicha) on 2023-08-17

description:

updated

Revision history for this message

Lukas Märdian (slyon) wrote on 2023-08-22:

Download full text (5.8 KiB)

Review for Source Package: libei

[Summary]
libei is a library for simulated input forwarding (client & server), which can
be used to remote control a system, similar to xdotools/libxdo. It seems to be
properly maintained upstream, but is still very new in Ubuntu (and not yet
packaged for Debian).

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: libeis1 (libei1, liboeffis1)
Specific binary packages built, but NOT to be promoted to main: None

Notes:
#0 This parses (simulated) keyboard/mouse input (& XML) and can remote control a
   system, so I'm requesting security review.
#1 There's an embedded copy of the "munit" test framework, but it seems to be
   used at compile/test time only, so I'm not criticizing this. Also, the desktop
   team agreed to provide updates/backports to the security team as needed.
   Also, the vendoring is properly set-up, using debian/watch components.

Required TODOs:
#2 Debian/Ubuntu update history is sporadic, will the desktop team keep track of
new upstream versions and keep the package maintained (supporting Debian's
"X Strike Force" team)?
#3 Please provide proper autopkgtests, see "Common blockers" below

Recommended TODOs:
#4 The package should get a team bug subscriber before being promoted
#5 Help upstream to improving the compiler warnings, see specifics below
#6 Get the package included in Debian and Ubuntu's version in sync
(pending "inclusion in Debian under the Debian X Strike Force team")
#7 Help upstream to resolve the s390x endianess issues, so we can re-enable all tests
https://gitlab.freedesktop.org/libinput/libei/-/issues/41

[Duplication]
There is no other package in main providing the same functionality.
There's xdotool, xautomation, ydotool, wtype that provide similar functionality,
nothing in "main", though.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - SRCPKG checked with `check-mir`
  - all dependencies can be found in `seeded-in-ubuntu` (already in main)
  - none of the (potentially auto-generated) dependencies (Depends
    and Recommends) that are present after build are not in main
  - no -dev/-debug/-doc packages that need exclusion
  - No dependencies in main that are only superficially tested requiring
    more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present (but munit testing framework)
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems:
- embeeded "munit" test framework, but seems to be fine (not used at runtime)

Review for Source Package: libei

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: libeis1 (libei1, liboeffis1)
Specific binary packages built, but NOT to be promoted to main: None

Required TODOs:
#2 Debian/Ubuntu update history is sporadic, will the desktop team keep track of
   new upstream versions and keep the package maintained (supporting Debian's
   "X Strike Force" team)?
#3 Please provide proper autopkgtests, see "Common blockers" below

Recommended TODOs:
#4 The package should get a team bug subscriber before being promoted
#5 Help upstream to improving the compiler warnings, see specifics below
#6 Get the package included in Debian and Ubuntu's version in sync
   (pending "inclusion in Debian under the Debian X Strike Force team")
#7 Help upstream to resolve the s390x endianess issues, so we can re-enable all tests
   https://gitlab.freedesktop.org/libinput/libei/-/issues/41

[Duplication]
There is no other package in main providing the same functionality.
There's xdotool, xautomation, ydotool, wtype that provide similar functionality,
nothing in "main", though.

Problems: None

Problems:
- embeeded "munit" test framework, but seems to be fine (not used at runtime)

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
 - does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems:
- does parse data formats (keyboard/mouse input, xml) from an untrusted source.
- does expose an external endpoint: AF_UNIX socket in src/libei-socket.c (EIS server)

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- no new python2 dependency
- Not a Python package
- Not a go package

Problems:
- does have a non-trivial test suite that runs as autopkgtest
  - This does not need special HW for build or test
- if a non-trivial test on this level does not make sense (the lib alone
  is only doing rather simple things), is the overall solution (app+libs)
  extensively covered i.e. via end to end autopkgtest ?
  - I couldn't find any relevant tests in mutter, using libei[s]
- "The package does not run an autopkgtest because we haven't written one yet."
  - Sorry, but this is not a good excuse. Please provide proper testing, using
    upstream's build time tests, upstream's CI tests or other custom tests. It
    seems to be doable for this kind of simulated input library.

[Packaging red flags]
OK:
- symbols tracking is in place.
- debian/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is good (approx. every 4 months)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- debian/rules is rather clean
- It is not on the lto-disabled list

Problems:
- Ubuntu does carry a delta (going ahead of Debian)
- Debian/Ubuntu update history is sporadic
  - Only a single upload in Ubuntu, not included in Debian
- s390x dh_auto_test disabled in debian/rules
  https://gitlab.freedesktop.org/libinput/libei/-/issues/41

[Upstream red flags]
OK:
- no Errors during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside tests)
- no use of user nobody
- no use of setuid / setgid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (user visible)?

Problems:
- warnings during the build (ignoring a few in the munit subproject):
  + src/util-sources.c:311:9: warning: ignoring return value of ‘read’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
  + tools/ei-demo-client.c:102:9: warning: ignoring return value of ‘read’ declared with attribute ‘warn_unused_result’ [-Wunused-result]

Changed in libei (Ubuntu):
assignee:	Lukas Märdian (slyon) → Ubuntu Security Team (ubuntu-security)
Changed in mutter (Ubuntu):
assignee:	nobody → Ubuntu Desktop (ubuntu-desktop)
tags:	added: update-excuse

Mark Esler (eslerm) on 2023-08-28

tags:

added: sec-2617

Revision history for this message

Marco Trevisan (Treviño) (3v1n0) wrote on 2023-08-29:

> #7 Help upstream to resolve the s390x endianess issues, so we can re-enable all tests
https://gitlab.freedesktop.org/libinput/libei/-/issues/41

I've done some analisys there of the remaining issue, we should be green soon!

Revision history for this message

Alex Murray (alexmurray) wrote on 2023-08-30:

Download full text (3.6 KiB)

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:

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.freedesk...

Other bug subscribers

Remote bug watches

auto-gitlab.freedesktop.org-libinput-libei-- #41
[closed] Edit
auto-gitlab.freedesktop.org-libinput-libei-- #43
[closed] Edit

Bug watches keep track of this bug in other bug trackers.

Changed in libei (Ubuntu):
importance:	Undecided → High
status:	New → Fix Released

Changed in libei (Ubuntu):
assignee:	Ubuntu Security Team (ubuntu-security) → nobody

Ubuntulibei package

[MIR] libei

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
libei package