Review for Source Package: simdutf [Summary] The essence of the review result from the MIR is that simdutf is a high-quality source package with a justified need in main, excellent unit testing, active upstream maintenance, and clean Debian packaging files. MIR team ACK under the constraint to resolve the below listed required TODOs. This does need a security review, so I'll assign ubuntu-security. List of specific binary packages to be promoted to main: libsimdutf29, libsimdutf-dev, libsimdutf-tools.
Notes: Required TODOs: 1. Addition of autopkgtests or an explanation as to why they are absent as per L#168 of the MIR Reporter’s Template. 2. This package lacks a .symbols tracking file. Please either add symbols tracking to this package or make a justification as to the efforts made and why it is not feasible. More details starting at L#303 of https://documentation.ubuntu.com/project/MIR/mir-reviewers-template/#mir-reviewers-template [Rationale, Duplication and Ownership] There is no other package in main providing the same functionality. A team is committed to own long term maintenance of this package - ~debcrafters-packages The rationale given in the report seems valid and useful for Ubuntu. It is understood that due to Debian switching to using the newer simdutf package as a build dependency and promoting this package to main would significantly reduce the maintenance burden on Ubuntu. [Dependencies] OK: - no other runtime Dependencies to MIR due to this - no other build-time Dependencies with active code in the final binaries 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: - 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 - No vendoring used, all Built-Using are in main - not a rust package, no extra constraints to consider in that regard - Does not include vendored code 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 parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source. Unicode text and base64 encoded data is parsed by this library. This presents a risk of parsing data from untrusted sources and a security review is recommended to assess this risk. - 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, ...). This is just a library that other consuming applications link against but for its exposure level, the risk is appropriate. Problems: As this library can parse data formats from an untrusted source (unicode text and base64 encoded data in this case), a security review is recommended. [Common blockers] OK: - does not FTBFS currently - does have a test suite that runs at build time - test suite fails will fail the build upon error. - does not 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: - No autopkgtests present. As per the MIR reporter’s template, autopkgtests or a justification as to why there are no autopkgtests is required. [Packaging red flags] OK: - Ubuntu does not carry a delta - Symbols tracking is not in place. The reporter needs to add it or attempt to add it as per the section from the MIR Reviews Template below: RULE: - If it's a library, does it either have a symbols file or use an empty RULE: argument to dh_makeshlibs -V? (pass such a patch on to Debian, but RULE: don't block on it). RULE: Note that for C++, see https://wiki.ubuntu.com/DailyRelease/FAQ RULE: for a method to demangle C++ symbols files. RULE: - There are shared object only meant for internal use, examples RULE: that come to mind are .so for perl or python implementation. RULE: in such cases symbols tracking is not needed as it isn't meant RULE: to expose an external API/ABI. But then in return we should ensure RULE: the package does not ship external headers to build against e.g. RULE: in a -dev package or similar. TODO-B: For c++ libraries - symbols tracking isn't in place but the owning TODO-B: team tried to set it up and came back with a reasonable rationale TODO-B: of why it isn't practical to do for the package. TODO-B: If symbols tracking isn't used then it's recommended to investigate TODO-B: using an alternative like abigail or abi-compliance-check in CI TODO-B: or bumping SOVER with every package update. - debian/watch is not present but there is a debian/upstream/metadata file in its place. - Upstream update history is good. Commits at least weekly. - Debian/Ubuntu update history is good. THough this is a new package, Ubuntu has been on top of keeping the latest version packaged. - 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 - It is not on the lto-disabled list Problems: - Symbols tracking is not in place for this package. The reporter needs to add symbols tracking or justify why it is not present and evaluate alternatives such as abigail or abi-compliance-check in CI. [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (as far as we can check it) - no incautious use of malloc/sprintf (the language has no direct MM) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside tests) - no use of user 'nobody' outside of tests - 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 (user visible)? Problems: None ** Changed in: simdutf (Ubuntu) Assignee: Myles Penner (mylesjp) => (unassigned) ** Changed in: simdutf (Ubuntu) Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security) ** Changed in: simdutf (Ubuntu) Status: Confirmed => New ** Changed in: simdutf (Ubuntu) Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned) ** Changed in: simdutf (Ubuntu) Assignee: (unassigned) => Sebastien Bacher (seb128) ** Changed in: simdutf (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2131217 Title: [MIR] simdutf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/simdutf/+bug/2131217/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
