Review for Source Package: libva
[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 is a case with a few more tasks, yet on the other
hand I understand this was in main back when we didn't hold the quality bar
that high, see bug 597354 - but it was demoted as far back as trusty.
Which I think does not translate this into a "ok, based on the old one just
add it back" case. Please have a look at my questions and concerns,
I'm confident you can overcome most easily and for the complex ones
you and Desktop need to make a call and tell us.
This does need a security review, so I'll assign ubuntu-security
Specific binary packages built, but NOT to be promoted to main: unsure,
see below
Required TODOs:
#1 - further dependencies, AFAICS
libva-x11-2/libva-glx2/libva-wayland2/libva-drm2
are the frontends, all then linking to libva2 for the actual
implementation.
Fine so far, but this is all lib/frontend and it makes no sense without
drivers maping it to the hardware.
And indeed there is:
Package: va-driver-all
Depends:
${misc:Depends},
i965-va-driver [any-amd64 any-i386] | i965-va-driver-shaders [any-amd64
any-i386],
intel-media-va-driver [amd64 i386 x32] | intel-media-va-driver-non-free
[amd64 i386 x32],
mesa-va-drivers
But all those are in universe as well.
$ rmadison -u ubuntu -s plucky,plucky-proposed i965-va-driver
i965-va-driver-shaders intel-media-va-driver intel-media-va-driver-non-free
mesa-va-drivers
i965-va-driver | 2.4.1+dfsg1-2 | plucky/universe |
amd64, i386
i965-va-driver-shaders | 2.4.1-2 | plucky/multiverse |
amd64, i386
intel-media-va-driver | 24.3.4+dfsg1-0ubuntu1 | plucky/universe |
amd64, i386
intel-media-va-driver-non-free | 24.3.4+ds1-0ubuntu1 | plucky/multiverse |
amd64, i386
mesa-va-drivers | 24.3.4-3ubuntu1 | plucky/universe |
amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
So I think you'd either need to adopt and process all these drivers for the
expected component mimstahces but also to make it worthwhile (I'd expect a lib
without driver does effectively nothing)
Or if not promoting those assuming it is disfunctional, what is the point in
adding it to gnome. To satisfy the lib but not make it functional until people
manually install the drivers from universe?
This seems wrong, please tell us how to resolve or what we have overlooked
(e.g. if it is useful without the drivers).
#2 - apparmor isolation
You mentioned "apparmor profile copied from evince" - for a library it is fine
or even the only right way to isolate it from the user when the use-cases are
known. Therefore this isn't üart of libva2 or anything, would you mind pointing
us to where the profile you refer to lives (which PKG, where on disk) to allow
a quick look?
#3 - what exactly will gnome-remote-desktop depend on? libva2 or a frontend
for x11/wayland/...? Do you want to promote and support just a subset, if
so which?
#5 - thanks for having and extending a test plan. This is already 90% of what is
needed :-) But this mostly says "we have HW" and "we have a plan" (good
start).
But the plan does not outline anything in regard to libva, being a lib this
is hard I know - but should the plan not describe something like maybe:
"Iterate the above on GPU types X/Y/Z and ensure it loads libva driver
X'/Y#/Z'"
Details are up to you, but something that ensures this isn't just run on
e.g.
on an nvidia gpu laptop and eventually does nothing other than dependency
loading but not using any code of libva.
Recommended TODOs:
#4 - The package should get a team bug subscriber before being promoted
#6 - please have a look at the lto disabling
Ideally and by the rules for main packages that should be fixed or at least
the workaround be in the package (to kind of motivate you to fix it :-) )
But AFAICS here it would be the first delta, which I'm willing to be
convinced to then better keep it in
https://git.launchpad.net/ubuntu/+source/lto-disabled-list/tree/lto-disabled-list#n816
But please have a look, maybe it is no more needed or there is a real fix,
which would be even better?
#7 - curious now, IIRC and checking the old bug 597354 / 595661 this is for
video acceleration on intel cards. Yet as of today my system does not have
libva, yet I think acceleration happily in many cases - are there
alternative, mayme more modern ways to do this that eventually
gnome-remote-desktop should use instead or am I ont understanding the
ecosystem correctly?
[Rationale, Duplication and Ownership]
There is no other package in main providing the same functionality. In a very
abstracted way it is for intel gpus what vdpau is for nvidia and that is in
main already.
A team is committed to own long term maintenance of this package.
The rationale given in the report seems valid and useful for Ubuntu, I remember
long ago pulling it in myself and thought it would no more be important but
gnome now starting to depend on it show it would be used.
Furthermore it is a dependency of most media processing already,
if people install ffmpeg or mplayer or any other classic media processing
directly or via dependencies they will have it installed and I'd expect that to
be the majority. Therefore bumping this up to have a proper owner and be in main
is a benefit to all.
[Dependencies]
OK:
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems:
- other Dependencies to MIR due to this - all the drivers AFAICS - adding a
TODO for it
- -dev/-debug/-doc packages that need exclusion: libva-dev should be excluded
as it would pull in libset-scalar-perl adding a TODO, but this is no blocker
at all
[Embedded sources and static linking]
OK:
- no embedded source present
- 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 expose any external endpoint (port/socket/... or similar)
- 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, ...)
- this makes appropriate (for its exposure) use of established risk
mitigation features (dropping permissions, using temporary environments,
restricted users/groups, seccomp, systemd isolation features,
apparmor, ...) - see the small discussion about the apparmor profile you
mentioned in the TODO section.
Problems:
- does parse data formats from an untrusted source, attacks via crafted videos
isn't unheard. While the CVE track record is good and this is mostly passing
on to the hardware driers still it would parse headers and such be a victim
to potential attacks. No blocker, but needs a security review.
[Common blockers]
OK:
- does not FTBFS currently
- This does seem to need special HW for build or test so it can't be
automatic at build or autopkgtest time. But as outlined
by the requester in [Quality assurance - testing] there:
- is hardware and a test plan or code
- no new python2 dependency
Problems:
- does not have a test suite that runs at build time
- does not have a non-trivial test suite that runs as autopkgtest
=> You explained both with the fact that this can't be easily tested in
build/test environments as it only gets real with the real hardware
and the associated drivers. I agree that and appreciate that you wrote
a test plan. It lacks any explicit check for va based acceleration to be
mentioned though, I've added that to the TODO section.
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place.
- debian/watch is present and looks ok
- Upstream update history is (good/slow/sporadic)
- Debian/Ubuntu update history is (good/slow/sporadic)
- 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
Problems:
- It is on the lto-disabled list, see
https://git.launchpad.net/ubuntu/+source/lto-disabled-list/tree/lto-disabled-list#n816
as far as the ruling goes today the fix or workaround for packages in main
should ideally be fully resolved and not be needed or be in the package.
I'm willing to be convinced to not do that here as it would be the first delta
we add, let me know what you think.
[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
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 or libseed
- not part of the UI for extra checks
- no translation present, but none needed for this case (no end user facing
parts)
Problems: None
** Changed in: libva (Ubuntu)
Assignee: Christian Ehrhardt (paelzer) => Ubuntu Security Team
(ubuntu-security)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libva in Ubuntu.
https://bugs.launchpad.net/bugs/2097800
Title:
[MIR] libva
Status in libva package in Ubuntu:
New
Bug description:
[Availability]
The package libva is already in Ubuntu universe.
The package libva build for the architectures it is designed to work on.
It currently builds and works for all Ubuntu architectures
Link to package https://launchpad.net/ubuntu/+source/libva
[Rationale]
- The package libva is required in Ubuntu main for gnome-remote-desktop
- The package libva will generally be useful for a large part of our user base
- The package libva is a new runtime dependency of package
gnome-remote-desktop 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 binary package TBD needs to be in main to achieve keeping
gnome-remote-desktop up-to-date and supported.
- The package libva is required in Ubuntu main no later than February
20 due to Ubuntu 25.04 Feature Freeze. Practically, we will likely
need a Feature Freeze Exception for this.
[Security]
- Had 1 security issue in the past
https://ubuntu.com/security/CVE-2023-39929
https://security-tracker.debian.org/tracker/CVE-2023-39929
The CVE is unclear; it might not have affected Ubuntu.
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Security has been kept in mind and common isolation/risk-mitigation
patterns are in place utilizing the following features:
+ apparmor profile copied from evince
- Packages does not open privileged ports (ports < 1024).
- Package does not expose any external endpoints
- 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 Debian/Ubuntu/Upstream and does not have
too many, long-term & critical, open bugs
+ Ubuntu https://bugs.launchpad.net/ubuntu/+source/libva
+ Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libva
+ Upstream https://github.com/intel/libva/issues
- The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
- The package does not run a test at build time because none is provided
upstream because it is difficult to test hardware accelerated video processing
with build tests.
- The package does not run an autopkgtest because it is difficult to
test hardware accelerated video processing with autopkgtests.
- The package can not be well tested at build or autopkgtest time because it
is difficult to test hardware accelerated video processing that way. To make up
for that:
+ We have access to such hardware in the team
+ Based on that access outlined above, here are the details of the test
plan/automation
test plan is in comments but will be moved to wiki
+ We will execute that test plan on-uploads regularly (for SRUs and at
Feature Freeze)
- This package is minimal and will be tested in a more wide reaching solution
https://wiki.ubuntu.com/DesktopTeam/TestPlans/RemoteDesktop
The initial gnome-remote-desktop implementation in gnome-remote-
desktop 48 Beta hides the new zero copy feature behind a debug flag
but it is expected to be the default in later GNOME/Ubuntu releases.
[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- 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
- Packaging and build is easy, link to debian/rules
https://salsa.debian.org/multimedia-team/libva/-/blob/master/debian/rules
[UI standards]
- Application is not end-user facing (does not need translation or .desktop
file)
[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]
- The owning team will be Desktop Packages and I have their acknowledgement
for that commitment
- The future owning team is not yet subscribed, but will subscribe to the
package before promotion
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package has been built within the last 3 months in the archive
- Build link on launchpad: https://launchpad.net/ubuntu/+source/libva/2.22.0-2
[Background information]
The Package description explains the package well
Upstream Name is libva
Link to upstream project https://github.com/intel/libva
libva was previously in main but was demoted once it was no longer required
for build dependencies to be in main
previous MIR: LP: #597354
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libva/+bug/2097800/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
