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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2097800
Title:
[MIR] libva
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libva/+bug/2097800/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
