Review for Package: x265 [Summary] MIR team ACK under the constraint (quite a few) to resolve the below listed required TODOs and as much as possible having a look at the recommended TODOs. Please ping back for a re-evaluation once they are resolved. This does need a security review, so I'll assign ubuntu-security List of specific binary packages to be promoted to main: libx265-doc, libx265-dev, libx265-199 Specific binary packages built, but NOT to be promoted to main: x265 This isn't forbidden, but the use by libheif will not pull it in. If wanted this would need to be seeded as supported. Required TODOs: #1 - as i said on 2004449 libde265 - it would be great if we could pick just one. Please have an investigation with upstream before supporting both. From far away it seems x265 is preferred for encoding (as it is under development in de265 still) but vice versa libde265 for decoding (no reason given/found) #2 - There is code for that in source/test/regression-tests.txt and it would be great to run this at build time and autopkgtest time. #3 - engage with the community on the example of bug 1915012. This isn't so much about this particular bug but about ensuring if mail or bug tracking or all that which you'd expect works well. Please check that way if this can be a healthy two way relationship or if we'd sign up for something with a dying community (more examples why that could be below) Recommended TODOs: #4 - it is great that this has tests at all (based on ffmpeg + x265) but please ensure that here or in libheif (or both) there is a test for libheif using x265 as autopkgtest #5 - if you are in a bug fix frenzy maybe try to understand and fix https://bugs.launchpad.net/ubuntu/+source/x265/+bug/1909949 [Duplication] As mentioned in 2004449 libde265, in theory both libraries provide the same. There seems to be a preference to use one for decoding and one for encoding. But it feels one should give a try to settle on one, it seems libde has more frequent fixed and releases. While I'd wish we could pick just one, it seems that isn't working well. I'll add a todo to at least try this and maybe disuss it upstream. => There is no other package in main providing the same functionality (kind of). [Dependencies] OK: - no -dev/-debug/-doc packages that need exclusion - there is libx265-doc but is only needs libjs-sphinxdoc which is in main - there also is libx265-dev but it has no external dependencies - 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 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 (a few in the past as expected, but no open ones nor too many) - 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 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 (video, audio) from an untrusted source. => this has been a common attack vector and needs a security review. [Common blockers] OK: - does not FTBFS currently - does have a non-trivial test suite that runs as autopkgtest - This does not need special HW for build or test - no new python2 dependency Problems: - does have a test suite that runs at build time There is code for that in source/test/regression-tests.txt and it would be great to run this at build and autopkgtest time. [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking is in place - d/watch is present and looks ok - Debian/Ubuntu update history is ok (matches upstream) - 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 - d/rules is ok, not too clean but that is due to enable/disable via flags - It is not on the lto-disabled list Problems: - Upstream update history is quite slow, maybe/hopefully that means there is not much to do anymore. But some other indicators do not look too good: + d/watch downloads from https://bitbucket.org/multicoreware/x265_git/downloads/ but the own donwload page https://www.x265.org/downloads/ does not list anything after v3.3 (3.5 is current). On the github mirrror is only 3.4 It just seems uncoordinated or out of sync. + No release for 1.5+ years (depending where you look) + Furthermore lots of the links from https://www.x265.org/developers/ are broken 404 links, so how would we engage with upstream + I also couldn't find an active bug tracker + the documentation links are a 404 as well https://x265.readthedocs.io/en/default/ + There are long term reasonable feature requests like https://bugs.launchpad.net/ubuntu/+source/x265/+bug/1915012 But then we find in d/rules 16 # no shared libs are built if HDR10+ is enabled 17 # FLAGS += -DENABLE_HDR10_PLUS=ON => I've added a recommended to do about that overall topic [Upstream red flags] OK: - no Errors/warnings during the build - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside tests) - no use of user nobody - no use of setuid - 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? Problems: - important open bugs with a crasher. Sadly upstream bugtracking isn't easily accessible it seems. Ubuntu reports a crash but no investigation happened. It would be great to have a look, added to TODOs.