[Availability]
The package webp-pixbuf-loader is already in Ubuntu universe.
The package webp-pixbuf-loader build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64 arm64 armhf ppc64el riscv64
s390x is failing tests in which seems a big endian issue, reported upstream https://github.com/aruiz/webp-pixbuf-loader/issues/39
Link to package https://launchpad.net/ubuntu/+source/webp-pixbuf-loader
[Rationale]
- The package webp-pixbuf-loader is required in Ubuntu main to be able to open webp image from the standard viewer (eog) and get thumbnails in the filemanage
- The package webp-pixbuf-loader will generally be useful for a large part of our user base
- The package webp-pixbuf-loader 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 new in Debian/Ubuntu and has currently no bug reported
- The package does not deal with exotic hardware we cannot support
[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://launchpadlibrarian.net/607631911/buildlog_ubuntu-kinetic-amd64.webp-pixbuf-loader_0.0.5-2_BUILDING.txt.gz
- The package does not run an autopkgtest because image loaders aren't easy to verify in that setup, but we will open example webp files as a manual testcase before doing package updates.
[Quality assurance - packaging]
- debian/watch is present and works
- the package is in sync with Debian and has a valid maintainer definition
- The package displays no lintian warnings
- Please link to a recent build log of the package https://launchpadlibrarian.net/607631911/buildlog_ubuntu-kinetic-amd64.webp-pixbuf-loader_0.0.5-2_BUILDING.txt.gz
- Lintian overrides are not present
[Maintenance/Owner]
- Owning Team will be desktop-packages
- Team is already subscribed to the package
- This does not use static builds
- This does not use vendored code
- The package has been built in the archive more recently than the last test rebuild
[Background information]
The Package description explains the package well
Upstream Name is webp-pixbuf-loader
Link to upstream project https://github.com/aruiz/webp-pixbuf-loader/
Review for Package: webp-pixbuf-loader
[Summary]
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: webp-pixbuf-loader
Specific binary packages built, but NOT to be promoted to main: -
Notes:
Required TODOs:
- Automated tests do not seem too complex to add, please:
- bump the testsuite to also run at autopkgtest time
- consider adding a set of "known content" webp pictures that you can
compare against expected results in the way the gnome thumbnailer will
use them (details see below).
Recommended TODOs:
- fix the s390x build before kinetic releases
[Duplication]
There is no other package in main providing the same functionality.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- libc6 (>= 2.14), libgdk-pixbuf-2.0-0 (>= 2.38.1), libglib2.0-0 (>= 2.37.3),
libwebp7, libwebpdemux2 are all 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
- 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:
- history of CVEs does not look concerning
- but webp in general (as all media formats) had a bunch
https:/
- does not open a port/socket
- 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 not parse data formats (files [images, video, audio,
xml, json, asn.1], network packets, structures, ...) from
an untrusted source.
To be fair There isn't much code and the actual content handling is
primarily in dependencies libwebp7 and libgdk-
But such code has been attack surface often enough, it should be checked.
[Common blockers]
OK:
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- No special HW needed
- no new python2 dependency
Problems:
- does FTBFS currently (on s390x)
You have filed this upstream, sicne s390x has no GUI this isn't a blocker
but would be great to be resolved before kinetic releases
- does not have a non-trivial test suite that runs as autopkgtest.
You've said you might want to do that as manual test before upload, but
TBH we all know they are often too easily forgotten and have no way to catch
dependencies breaking you.
Furthermore in this case it doesn't even seem too hard to add tests.
1. The runtime tests are good - please run that in autopkgtest context will
easily allow to catch dependencies changing in a bad way
2. It seems deterministic, so yo...