[MIR] libwpe

[Sebastien Bacher]

[Availability]
The package libwpe is already in Ubuntu universe.
The package libwpe build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64 arm64 armhf i386 ppc64el riscv64 s390x
Link to package https://launchpad.net/ubuntu/+source/libwpe

[Rationale]
The package libwpe is required in Ubuntu main as a dependency of webkit2gtk. The dependency is optional but the default upstream and in other distributions and the only one upstream is really testing (turned out some of the issues we had previous cycle are because we aren't using the default backend, which also made a lower priority for upstream to work on fixes). Upstream is also planning to deprecate the nonwpe codepath.

- The package wpebackend-fdo is required in Ubuntu main no later than aug 25 due to feature freeze

[Security]
- No CVEs/security issues in this software in the past

- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software

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

[Quality assurance - maintenance]
- The package is maintained well in Ubuntu and Debian and has currently no reports
  - Ubuntu https://bugs.launchpad.net/ubuntu/+source/libwpe/+bug
  - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libwpe

[Quality assurance - testing]
- The package does not run a test at build time because upstream doesn't have one. That's something we need to work on.
BLOCKER ^

If webkit2gtk is built with it as it default backend then the webkitgtk autopkgtests are going to exercise wpe, is that enough?
BLOCKER? ^

We need to work on the testing story, backup plan is to write some manual test plans. It's likely that the test plan for wpebackend-fdo will cover the library.

[Quality assurance - packaging]
- debian/watch is present and works

-- There is only one lintian warning

# lintian --pedantic
P: libwpe source: package-uses-old-debhelper-compat-version 12

12 isn't that old but we will work on updating to 13

- 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 question

- Packaging and build is easy, link to d/rules https://salsa.debian.org/webkit-team/libwpe/-/blob/master/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
- This does not use vendored code

- The package successfully built during the most recent test rebuild

[Background information]
The Package description explains the package well
Upstream Name is libwpe
Link to upstream project https://github.com/WebPlatformForEmbedded/libwpe

[Sebastien Bacher (seb128)]

The testing story needs work but we are putting in the queue already since that should block review, especially if that needs input from the security team as a future dependency of webkitgtk

[Christian Ehrhardt  (paelzer)]

Review for Package: libwpe

[Summary]
This library LGTM, it is well maintained and written as far as I could check.
The only sad aspect is the suboptimal test story that you already identified
yourself.

MIR team ACK.
I was going back and forth if in this case adding more tests is required or
recommended. I've ended up with "recommended" as high level tests are done as
part of higher level autopkgtest. But consider at least trying to add at
least some unit-tests at build time rather strongly recommended.

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

List of specific binary packages to be promoted to main: libwpe-1.0-1
Specific binary packages built, but NOT to be promoted to main: <none>

Notes:
Recommended TODOs:
- You already know the testing is weak, the higher level tets in webkit2gtk
  seems fine for autopkgtest, but is there something we could do at the lower
  level in the lib itself for build time checks?
- The package should get a team bug subscriber before being promoted, but I know
  you are aware of that already

[Duplication]
There is no other package in main providing the same functionality.
The renderer used right now is actively deprecated by upstream as outlined in
the initial report.

[Dependencies]
OK:
- No other Dependencies to MIR due to this (all in main already)
- No -dev/-debug/-doc packages that need exclusion (all follow on deps in main)
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- embedded source present (directory subprojects) but not used in Ubuntu builds
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- does not run a daemon as root
- does not use webkit1,2 (in fact it is the inverse, allowing webkit on gtk)
- does not use lib*v8 directly
- does not open a port/socket
- does not use centralized online accounts
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)

Problems:
- history of CVEs does look concerning - not for this library in particular
  but for the overall webkitgtk stack there are many
- does not integrate arbitrary javascript into the desktop - I can't say it is
  aritrary but it is an HTML renderer for GTK, so it will have all the
  attack surface of such.
- does parse data formats
- does process arbitrary web content - again maybe not arbitrary, but definetly
  it will parse content from various sources

=> This clearly is enough to need also a security review.

[Common blockers]
OK:
- does not FTBFS currently
- does not need special HW to test
- no new python2 dependency

Problems:
- does not have a non-trivial test suite that runs as autopkgtest
  But since this is just a lib it is ok to test it at a higher level
  which happens once we build webkit2gtk with it as backend.
  That seeems sufficient to me for autopkgtests.
- does not have a test suite that runs at build time
  That - at least for the micro-levels e.g. a unit test to ensure
  fixes/delta/build-options do not break thing...

[Sebastien Bacher (seb128)]

I've sent an upstream report on https://github.com/WebPlatformForEmbedded/libwpe/issues/110 about the missing tests which I think is the best we can do at this point.

[Spyros Seimenis (sespiros)]

I reviewed libwpe 1.12.0-1 as checked into kinetic. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

libwpe provides a common interface between WPE WebKit (and potentially any WebKit ports)
and its rendering backends.

- CVE History:
  - No CVEs
- Build-Depends?
  - No encryption or networking build dependencies
- pre/post inst/rm scripts?
  - No
- init scripts?
  - No
- systemd units?
  - No
- dbus services?
  - No
- setuid binaries?
  - No
- binaries in PATH?
  - No
- sudo fragments?
  - No
- polkit files?
  - No
- udev rules?
  - No
- unit tests / autopkgtests?
  - No test suite or autopkgtests
  - There seem to be some higher level tests in webkit2gtk
- cron jobs?
  - No
- Build logs:
  - CMake Warning (dev) at /usr/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
      The package name passed to `find_package_handle_standard_args`
      (LIBXKBCOMMON) does not match the name of the calling package
      (Libxkbcommon). This can lead to problems in calling code that expects
      `find_package` result variables (e.g., `_FOUND`) to follow a certain
      pattern.
    Call Stack (most recent call first):
      cmake/FindLibxkbcommon.cmake:63 (find_package_handle_standard_args)
      CMakeLists.txt:49 (find_package)
    This warning is for project developers. Use -Wno-dev to suppress it.
  - CMake Warning:
      Manually-specified variables were not used by the project:

        CMAKE_EXPORT_NO_PACKAGE_REGISTRY
        CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
        FETCHCONTENT_FULLY_DISCONNECTED
  - No Lintian errors/warnings
- Processes spawned?
  - No
- Memory management?
  - src/pasteboard-generic.cpp:54: calloc second argument may overflow leading to a heap OOB write in line 60
  - src/input.c:231: Original object may leak if realloc fails (also reported by cppcheck)
  - Both issues reported to upstream and are now fixed
- File IO?
  - No other than the paths to the backend WPE libraries to be loaded with dlopen()
- Logging?
  - No issues
- Environment variable usage?
  - Uses WPE_BACKEND_LIBRARY but in debug builds only
- Use of privileged functions?
  - No
- Use of cryptography / random number sources etc?
  - No
- Use of temp files?
  - No
- Use of networking?
  - No
- Use of WebKit?
  - No. Although related.
- Use of PolicyKit?
  - No

- Any significant cppcheck results?
  - src/input.c:231:29: error: Common realloc mistake: 'array' nulled but not freed upon failure [memleakOnRealloc]
                                array = (struct wpe_input_xkb_keymap_entry*)realloc(array, array_allocated_size * sizeof(struct wpe_input_xkb_keymap_entry));
                                ^
  - This issue is also now fixed
- Any significant Coverity results?
  - No
- Any significant shellcheck results?
  - No
- Any significant bandit results?
  - No
- Any significant flawfinder results?
  - No

Development is active with frequent releases but it follows a release model similar
to wpewebkit (and webkitgtk) which has been historically difficult to maintain, from
the security team's point of view, due to their release model (minor version releases
with limited information related to se...

[Christian Ehrhardt  (paelzer)]

Adding tests depends on upstream, thanks for filing it there.
This should be fine to be promoted now, once subscribed by the team.

Assigning seb128 to subscribe (and to promote then)

[Sebastien Bacher (seb128)]

~desktop-packages has been subscribed and https://launchpad.net/ubuntu/+source/webkit2gtk/2.36.4-1ubuntu1 uploaded

[Didier Roche-Tolomelli (didrocks)]

$ ./change-override -c main -S libwpe
Override component to main
libwpe 1.12.0-1 in kinetic: universe/misc -> main
libwpe-1.0-1 1.12.0-1 in kinetic amd64: universe/libs/optional/100% -> main
libwpe-1.0-1 1.12.0-1 in kinetic arm64: universe/libs/optional/100% -> main
libwpe-1.0-1 1.12.0-1 in kinetic armhf: universe/libs/optional/100% -> main
libwpe-1.0-1 1.12.0-1 in kinetic i386: universe/libs/optional/100% -> main
libwpe-1.0-1 1.12.0-1 in kinetic ppc64el: universe/libs/optional/100% -> main
libwpe-1.0-1 1.12.0-1 in kinetic riscv64: universe/libs/optional/100% -> main
libwpe-1.0-1 1.12.0-1 in kinetic s390x: universe/libs/optional/100% -> main
libwpe-1.0-dev 1.12.0-1 in kinetic amd64: universe/libdevel/optional/100% -> main
libwpe-1.0-dev 1.12.0-1 in kinetic arm64: universe/libdevel/optional/100% -> main
libwpe-1.0-dev 1.12.0-1 in kinetic armhf: universe/libdevel/optional/100% -> main
libwpe-1.0-dev 1.12.0-1 in kinetic i386: universe/libdevel/optional/100% -> main
libwpe-1.0-dev 1.12.0-1 in kinetic ppc64el: universe/libdevel/optional/100% -> main
libwpe-1.0-dev 1.12.0-1 in kinetic riscv64: universe/libdevel/optional/100% -> main
libwpe-1.0-dev 1.12.0-1 in kinetic s390x: universe/libdevel/optional/100% -> main
Override [y|N]? y
15 publications overridden.

[Sebastien Bacher (seb128)]

Targetting 22.04 there now as we would like to build webkit2gtk with wpe support enabled also in the LTS since that's the codepath which has the best upstream support and it would resolve some existing issues we have from building without it.

@MIR team, could you review the request of promoting the package also in 22.04? The version available in 22.04 is slightly older than the one which got promoted in kinetic but we could try to SRU first the newer version if that's preferred.
There was not packaging change between the concerned version that should make a difference on the MIR review outcome.

Speaking with Marc from the security team who is usually doing the webkitgtk security update he was on board with the idea of building webkitgtk with wpe going forward.

[Sebastien Bacher (seb128)]

In fact upstream is sort of forcing us to go that way now

https://webkitgtk.org/2022/11/11/webkitgtk2.39.1-released.html
> Remove internal nested wayland compositor making libwpe mandatory when building with wayland enabled.

if we want to keep rolling newer webkitgtk version as security updates we will need to build with wpe

[Ioanna Alifieraki (joalif)]

Review for Package: libwpe

[Summary]
The package looks good, it also has been MIR approved for kinetic.
This is for Jammy.
The main problem is the lack of tests but since this was not a blocker
for the kinetic MIR, I assume it is the same for this one.

MIR team ACK

The package has already gone under sec review, so not sure if it needs
to undergo a second one.
I'll discuss it in todays MIR meeting.

List of specific binary packages to be promoted to main: libwpe-1.0-1

TODOs:
Recommended:
1. The version in jammy is a bit old. Owning team may want to bump versions.

[Duplication]
This package in main from kinetic onwards. Now it is required in jammy too because upstream
removed internal nested wayland compositor for WebKitGTK, which makes libwpe mandatory
when building it with wayland enabled.
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- 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:
- embedded source present but not used in ubuntu builds
- 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: None

[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 open a port/socket
- does not use centralized online accounts
- 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 not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- does not process arbitrary web content
- does not integrate arbitrary javascript into the desktop

[Common blockers]
OK:
- does not FTBFS currently
- no new python2 dependency

Problems:
- does not have a test suite that runs at build time
- does have a non-trivial test suite that runs as autopkgtest

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- debian/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is good
- Debian/Ubuntu update history is good
- 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:
- the current release is not packaged, but again this is for jammy.

[Upstream red flags]
OK:
- no Errors/warnings 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
- no use of user nobody
- no use of setuid
- 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 check...

[Ioanna Alifieraki (joalif)]

I am assigning this to security to give it a look and the final ack for promotion.

[Seth Arnold (seth-arnold)]

Security team ACK to promote libwpe to main in jammy. There were some nice cleanups as a result of our review but nothing looks critical enough to ask for preemptive fixes before promotion.

Thanks

[Sebastien Bacher (seb128)]

We can't change the jammy pocket but I've copied to jammy-updates and promoted it there

[Timo Aaltonen (tjaalton)]

libwpe-1.0-1 binary is still in universe for jammy