Review for Source Package: src:libfyaml [Summary] The libfyaml offers a YAML 2.0 compliant parser. Though it covers the same use-case as libyaml, it has certain advantages over the latter. It offers a better C API. It parses faster than libyaml and has zero-copy API that reduces the memory usage, making it easier to parse large YAML data.
Though there are no CVEs reported against libfyaml, a significant number of memory-corruption issues have been reported. 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: bin:libfyaml0 Specific binary packages built, but NOT to be promoted to main: bin:libfyaml-utils, bin:libfyaml-dev Notes: Required TODOs: #0 - Please add a team bug subscriber to the package. Recommended TODOs: #1 - Please consider evaluating/addressing the open memory-corruption issues reported upstream. #2 - There are a few minor build warnings. Please consider fixing them. #3 - Some upstream files (e.g: blake3/*) do not have license headers. Can this be represented in d/copyrights? [Rationale, Duplication and Ownership] OK: - There is no other package in main providing the same functionality. => As reported, src:libyaml provides similar functionality. However, the rationale provided by the reporter makes a good case for why src:libfyaml should co-exist with the former, in main. Porting all the uses of libyaml by libfyaml, or vice-versa, are significant, impractical undertaking. So this appears like a tactical solution, for now. - The rationale given in the report seems valid and useful for Ubuntu. Problems: - A team is committed to own long term maintenance of this package. => No team is subscribed to the package yet. [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 => only bin:libfyaml0 is required to be in main, bin:libfyaml-dev should remain in universe - 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 - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source. => parses YAML oblivious of the source - 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, ...) => includes XXHash implementation used in the de-duplication allocator => includes blake3 hash implementation used in the fy-tool b3sum tool - 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 a yaml parsing library, exposure-based risk mitigation is not relevant Problems: - The reporter has quoted unresolved memory corruption issues. [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. - This does not need special HW for build or test - if a non-trivial test on this level does not make sense (the lib alone is only doing rather simple things), is the overall solution (app+libs) extensively covered i.e. via end to end autopkgtest ? => the appstream autopkgtests cover bin:libfyaml0 in the "as-test_yaml" test. - no new python2 dependency Problems: None [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking is in place. - debian/watch is present and looks ok (if needed, e.g. non-native) - Upstream update history is sporadic - Debian/Ubuntu update history is 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 - It is not on the lto-disabled list Problems: None [Upstream red flags] OK: - no Errors 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' 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: - A couple of build warnings are noted https://launchpadlibrarian.net/827289425/buildlog_ubuntu-resolute-amd64.libfyaml_0.9-2_BUILDING.txt.gz - Some files like blake3/* have no license headers. Can this be represented in d/copyright? ** Changed in: libfyaml (Ubuntu) Assignee: Pushkar Kulkarni (pushkarnk) => 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/2131216 Title: [MIR] libfyaml To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libfyaml/+bug/2131216/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
