** Attachment added: "report.json" https://bugs.launchpad.net/ubuntu/+source/upki/+bug/2166514/+attachment/5997470/+files/report.json
** Description changed: MIR report for source package: upki Target series: devel [Availability] - The source package upki is published in Ubuntu (universe). - Current Launchpad builds pass on: amd64, amd64v3, arm64, armhf, ppc64el, riscv64, s390x. - Source package: https://launchpad.net/ubuntu/+source/upki [Rationale] - The package src:upki is required in Ubuntu main for integrating it into most applications by default - The package src:upki will generally be useful for a large part of our user base. - No prior MIR bug was found for this source or identified predecessor names. - The package src:upki is required in Ubuntu main no later than 26.10 - No genuine overlap with anything in main exists; the main candidates found (openssl, ssl-cert, libstrongswan, libpq5) are a cryptographic utility, a simple wrapper, a VPN library, and a database client, respectively, rather than dedicated PKI management systems or certificate authority tools. (The search identified four packages in main: `openssl` (a low-level cryptographic utility), `ssl-cert` (a simple debconf wrapper for generating self-signed certificates), `libstrongswan` (a VPN utility and crypto library), and `libpq5` (a PostgreSQL database client). None of these provide the high-level PKI management or Certificate Authority functionality implied by the search terms, whereas the universe candidates (e.g., `easy-rsa`, `gnomint`, `ruby-certificate-authority`) do fit that description.) - The binary packages upki, libupki1, libupki-openssl1 need to be in main to achieve integration into crypto libraries by default [Security] - No package-associated CVEs were found in the queried trackers. (Sourcing: the Ubuntu CVE tracker plus the cross-vendor cvelistV5/NVD corpus, which also covers Debian-relevant CVE identifiers - no separate Debian or NVD check is needed. The OSS-security mailing list (pre-CVE-assignment chatter) is not covered by these adapters; flag it yourself if you are aware of such a discussion.) - No AppArmor profiles, desktop files, translations, or plugin candidates were found. - Mitigations are not proportional to the exposure because the package ships a systemd service that processes untrusted X.509 data but lacks an AppArmor profile to confine its filesystem and network access. (The binary-package-inspection confirms the presence of systemd units (upki-fetch.service, upki-fetch.timer) and the absence of AppArmor profiles (apparmor_profiles: []). The source analysis indicates the package parses X.509 certificates (untrusted input) and handles cryptographic operations. For a service handling such data and likely network activity, the lack of an AppArmor profile represents a security hardening gap.) - The pattern search found deprecated-algorithm indicators in the vendored x509-parser crate, specifically references to SHA1 in ./rust-vendor/x509-parser/src/verify.rs and ./rust-vendor/x509-parser/src/signature_algorithm.rs; the reporter should confirm whether these algorithms are actually used before flagging Security review. As this is a general purpose x509 parser crate and may need to parse such certificates if system policy allows it to deem whether they are revoked this is likely necessary. It cannot mark certificates as trusted, only as revoked, so this is not a security concern. (The evidence field `packaging-source.crypto_pattern_hits` contains a non-empty list of matches, primarily in `rust-vendor/x509-parser`, referencing SHA1 and legacy RSA constants.) - Installed privileged/service surface: systemd units: upki_1.0.0~beta.3-0ubuntu1_amd64/usr/lib/systemd/system/upki- fetch.timer, upki_1.0.0~beta.3-0ubuntu1_amd64/usr/lib/systemd/system/upki- fetch.service. - These services are required for fetching the CRLite data from the + These services are required for fetching the CRLite data from the Ubuntu servers over HTTPS. OpenSSL is used for the TLS layer. [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - No critical Ubuntu or release-critical Debian bugs were found. - The package does not depend on exotic hardware we cannot support. - The package is not in Debian, one low-priority Launchpad bug, and a release cadence averaging 28.5 days across three recent versions. (Evidence shows 0 open bugs in Debian BTS, 1 open bug in Launchpad (ID 2164286, Undecided importance, created 2026-08-18), and a release cadence of 3 versions over 57 days with an average interval of 28.5 days. The upstream tracker shows 0 open issues.) [Quality assurance - testing] - Autopkgtests will be fixed and unit tests enabled, JIRA tasks are created - Upstream tests are not run during build, autopkgtests include smoke test for upki-fetch against sample data - The package does have failing autopkgtests tests right now, they will be fixed. - We are working on running the upstream tests during the build - Build tests are explicitly disabled in debian/rules via an override that comments out the cargo test invocation, and the existing autopkgtest is currently failing on all tested architectures. They will be fixed (The packaging-source.debian_rules_overrides list includes 'dh_auto_test', and the full debian_rules text shows an override where the cargo test command is commented out, indicating build tests are not run. The autopkgtest-db evidence shows that the 'upki-fetch' autopkgtest is failing on all architectures (amd64, arm64, etc.), and the debian_tests_control indicates the test requires root and python3, suggesting it is a functional test rather than a trivial check.) - [Quality assurance - packaging] - A debian/watch upstream-release mechanism is present. - debian/control defines a correct Maintainer field - Lintian reported 0 error(s) and 0 warning(s). - No Python 2, GTK 2, or other catalogued obsolete runtime dependency was found. - Source format: 3.0 (quilt); debconf templates: 0; debian/rules overrides: dh_auto_configure, dh_auto_install, dh_auto_test. - Lintian overrides are absent or already explained by a comment. - Packaging is complex, but unavoidable since we have multiple crates in one package - we don't want to have 4x basically the same source tree (The packaging uses a patched `dh-cargo` wrapper and custom scripts in `debian/bin` to manage a Rust workspace with vendored dependencies and an embedded `aws-lc` library, which standard tooling does not support. It includes manual overrides for configuration, installation (using `cargo cinstall`), and copyright generation. Tests are disabled in `override_dh_auto_test` due to issues with the `dh-cargo-built-using` logic for the embedded library.) [UI standards] - This package is not end-user facing (server, CLI-only tool, daemon, or library), so desktop-file and translation requirements do not apply. (The package produces binaries in the 'utils', 'libs', and 'libdevel' sections, with no GUI toolkit dependencies. The 'upki' binary depends on systemd and includes systemd service and timer units, indicating it functions as a system daemon or CLI utility rather than a user-facing graphical application.) - Not an end-user application (server, CLI-only tool, or library) - no Desktop file is needed. - Application is not end-user facing (does not need translation). [Dependencies] - No in-scope runtime dependencies outside main require a separate MIR. [Standards compliance] - This package correctly follows FHS and Debian Policy. - No license expiry, time-bound terms, entity/contract coupling, withdrawable branches, patents, or other encumbrances were identified; the license is expected to remain compatible with Ubuntu main throughout the full support lifetime. [Maintenance/Owner] - The team foundations-bugs is subscribed to the package - Shipped vendored directories: ./rust-vendor/ring/third_party. - This Rust package tracks its vendored dependencies via a committed Cargo.lock file. - Launchpad records contain 7 build(s) from the last three months. Builds: https://launchpad.net/ubuntu/+source/upki/1.0.0~beta.3-0ubuntu1/+build/33515335, https://launchpad.net/ubuntu/+source/upki/1.0.0~beta.3-0ubuntu1/+build/33515336, https://launchpad.net/ubuntu/+source/upki/1.0.0~beta.3-0ubuntu1/+build/33515337, https://launchpad.net/ubuntu/+source/upki/1.0.0~beta.3-0ubuntu1/+build/33515338, https://launchpad.net/ubuntu/+source/upki/1.0.0~beta.3-0ubuntu1/+build/33515339, https://launchpad.net/ubuntu/+source/upki/1.0.0~beta.3-0ubuntu1/+build/33515340, https://launchpad.net/ubuntu/+source/upki/1.0.0~beta.3-0ubuntu1/+build/33515341. - This change affects other Ubuntu teams and the required coordination is still in progress. - The team foundations-bugs is aware of the implications of a static build and of vendored code, and commits to test no-change-rebuilds, to refresh and track the vendored code, to keep debian/copyright covering it, and to provide updates and backports to the security team for any affected vendored code for the lifetime of the release (including ESM). New vendored components will be agreed with the security team. - Built binaries declare no Built-Using or Static-Built-Using entries. [Background information] - The upstream project name is upki, which is the same as the source package name. (The upstream-tracker lists the project name as 'upki' and provides the URL 'https://github.com/rustls/upki'. The debian control Source field is 'upki', confirming the match.) - Upstream project: https://github.com/rustls/upki - The package description explains the package well, additionally this is to say it will be part of the default install + + - This report is generated with the help of `auto-mir` -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166514 Title: [MIR] upki To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upki/+bug/2166514/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
