I have linked a merge proposal addressing some of the issues relating to MIR:
https://code.launchpad.net/~bamf0/ubuntu/+source/rust-sequoia- sqv/+git/rust-sequoia-sqv/+merge/502068 Output of `lintian --pedantic` for this version is: W: rust-sequoia-sqv source: unknown-field Vendored-Sources-Rust which is expected for Rust packages with vendored sources. ** Changed in: rust-sequoia-sqv (Ubuntu) Assignee: Julian Andres Klode (juliank) => Simon Johnsson (bamf0) ** Description changed: [Availability] The package rust-sequoia-sqv is already in universe; it builds for all architectures. Link to package https://launchpad.net/ubuntu/+source/rust-sequoia-sqv [Rationale] - Sequoia is becoming the standard OpenPGP implementation in competing Linux distributions such as RHEL. + Sequoia is becoming the standard OpenPGP implementation in competing Linux + distributions such as RHEL. - For 25.10 and particularly 26.04 we want to use sqv in APT using APT's - sqv backend which landed in Debian earlier this year, and will be part - of the upcoming Debian stable release. + For 26.04 and particularly 26.10 we want to use sqv in APT using APT's sqv + backend which landed in Debian earlier this year, and will be part of the + upcoming Debian stable release. [Security] - No CVEs/security issues in this software in the past (to my awareness) - no `suid` or `sgid` binaries - no executables in `/sbin` and `/usr/sbin` - Package does not install services, timers or recurring jobs - Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: - The program is written in a memory safe language - Packages does not open privileged ports (ports < 1024). - Package does not expose any external endpoints [Quality assurance - function/usage] The package works well right after install [Quality assurance - maintenance] - The package rust-sequoia-sqv is maintained well in Debian/Ubuntu/Upstream and does - not have too many, long-term & critical, open bugs - - Ubuntu https://bugs.launchpad.net/ubuntu/+source/rust-sequoia-sqv/+bug - - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=rust-sequoia-sqv + not have too many, long-term & critical, open bugs + - Ubuntu https://bugs.launchpad.net/ubuntu/+source/rust-sequoia-sqv/+bug + - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=rust-sequoia-sqv - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] - The package runs a test suite on build time, if it fails - it makes the build fail, link to build log TBD + it makes the build fail, link to build log TBD - The package does not run an autopkgtest because given the vendored dependencies it is not super useful. APT includes a full featured test suite testing the sqv code base across a whole bunch of corner cases, though. - [Quality assurance - packaging] - debian/watch is present and works - debian/control defines a correct Maintainer field - RULE: - It is often useful to run `lintian --pedantic` on the package to spot - RULE: the most common packaging issues in advance - RULE: - Non-obvious or non-properly commented lintian overrides should be - RULE: explained - TODO: - This package does not yield massive lintian Warnings, Errors - TODO: - Please link to a recent build log of the package <TBD> - TODO: - Please attach the full output you have got from - TODO: `lintian --pedantic` as an extra post to this bug. - TODO-A: - Lintian overrides are not present - TODO-B: - Lintian overrides are present, but ok because TBD + - This package does not yield massive lintian Warnings, Errors + - Please link to a recent build log of the package: + https://launchpadlibrarian.net/851854368/buildlog_ubuntu-resolute-amd64.rust-sequoia-sqv_1.3.0-3ubuntu2~resolute1_BUILDING.txt.gz + - Lintian overrides are not present - This package does not rely on obsolete or about to be demoted packages. - This package has no python2 or GTK2 dependencies - RULE: - Debconf questions should not bother the default user too much - TODO-A: - The package will be installed by default, but does not ask debconf - TODO-A: questions higher than medium - TODO-B: - The package will not be installed by default + - The package will be installed by default, but does not ask debconf + questions higher than medium - RULE: - The source packaging (in debian/) should be reasonably easy to - RULE: understand and maintain. - TODO-A: - Packaging and build is easy, link to debian/rules TBD - TODO-B: - Packaging is complex, but that is ok because TBD + - Packaging is complex, but that is ok because it is a rust package with vendored dependencies. + The majority of the rules relate to the maintenance of the vendored dependencies, + which is a common case for rust packages in main. [UI standards] - TODO-A: - Application is not end-user facing (does not need translation) - TODO-B: - Application is end-user facing, Translation is present, via standard - TODO-B: intltool/gettext or similar build and runtime internationalization - TODO-B: system see TBD - - TODO-A: - End-user applications that ships a standard conformant desktop file, - TODO-A: see TBD - TODO-B: - End-user applications without desktop file, not needed because TBD + - Application is not end-user facing (does not need translation). It is only + intended as a CLI OpenPGP verification tool in scripts. [Dependencies] - RULE: - In case of alternative the preferred alternative must be in main. - RULE: - Build(-only) dependencies can be in universe - RULE: - If there are further dependencies they need a separate MIR discussion - RULE: (this can be a separate bug or another task on the main MIR bug) - TODO-A: - No further depends or recommends dependencies that are not yet in main - TODO-B: - There are further dependencies that are not yet in main, MIR for them - TODO-B: is at TBD - TODO-C: - There are further dependencies that are not yet in main, the MIR - TODO-C: process for them is handled as part of this bug here. + - No further depends or recommends dependencies that are not yet in main. [Standards compliance] - RULE: - Major violations should be documented and justified. - RULE: - FHS: https://refspecs.linuxfoundation.org/fhs.shtml - RULE: - Debian Policy: https://www.debian.org/doc/debian-policy/ - TODO-A: - This package correctly follows FHS and Debian Policy - TODO-B: - This package violates FHS or Debian Policy, reasons for that are TBD + - This package correctly follows FHS and Debian Policy. [Maintenance/Owner] - RULE: The package must have an acceptable level of maintenance corresponding - RULE: to its complexity: - RULE: - All packages must have a designated "owning" team, regardless of - RULE: complexity. - RULE: This requirement of an owning-team comes in two aspects: - RULE: - A case needs to have a team essentially saying "yes we will own that" - RULE: to enter the MIR process. Usually that is implied by team members - RULE: filing MIR requests having the backup by their management for the - RULE: long term commitment this implies. - RULE: - A community driven MIR request might be filed to show the use case, - RULE: but then, as a first step, needs to get a team agreeing to own - RULE: it before the case can be processed further. - RULE: If unsure which teams to consider have a look at the current mapping - RULE: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html - RULE: In that case (you are not a representative of the team who will - RULE: gain the long term committment to this) please ask a representative - RULE: of that team to comment on the bug acknowledging that they are ok to - RULE: own it. - RULE: - The package needs a bug subscriber before it can be promoted to main. - RULE: Strictly speaking that subscription can therefore wait until the - RULE: moment of the actual promotion by an archive admin. But it is - RULE: strongly recommended to subscribe early, as the owning team will get - RULE a preview of the to-be-expected incoming bugs later on. - RULE: - Simple packages (e.g. language bindings, simple Perl modules, small - RULE: command-line programs, etc.) might not need very much maintenance - RULE: effort, and if they are maintained well in Debian we can just keep them - RULE: synced. They still need a subscribing team to handle bugs, FTBFS and - RULE: tests - RULE: - More complex packages will usually need a developer or team of - RULE: developers paying attention to their bugs, whether that be in Ubuntu - RULE: or elsewhere (often Debian). Packages that deliver major new headline - RULE: features in Ubuntu need to have commitment from Ubuntu developers - RULE: willing to spend substantial time on them. - TODO-A: - The owning team will be TBD and I have their acknowledgement for - TODO-A: that commitment - TODO-B: - I Suggest the owning team to be TBD - TODO-A: - The future owning team is already subscribed to the package - TODO-B: - The future owning team is not yet subscribed, but will subscribe to - TODO-B: the package before promotion + - The owning team will be Ubuntu Foundations and I have their acknowledgement for + that commitment. + - The future owning team is not yet subscribed, but will subscribe to + the package before promotion. - RULE: - Responsibilities implied by static builds promoted to main, which is - RULE: not a recommended but a common case with golang and rust packages. - RULE: - the security team will track CVEs for all vendored/embedded sources in main - RULE: - the security team will provide updates to main for all `golang-*-dev` - RULE: packages - RULE: - the security team will provide updates to main for non-vendored - RULE: dependencies as per normal procedures (including e.g., - RULE: sponsoring/coordinating uploads from teams/upstream projects, etc) - RULE: - the security team will perform no-change-rebuilds for all packages - RULE: listing an CVE-fixed package as Built-Using and coordinate testing - RULE: with the owning teams responsible for the rebuilt packages - RULE: - for packages that build using any `golang-*-dev` packages: - RULE: - the owning team must state their commitment to test - RULE: no-change-rebuilds triggered by a dependent library/compiler and to - RULE: fix any issues found for the lifetime of the release (including ESM - RULE: when included) - RULE: - the owning team must provide timely testing of no-change-rebuilds - RULE: from the security team, fixing the rebuilt package as necessary - RULE: - for packages that build with approved vendored code: - RULE: - the owning team must state their commitment to provide updates to - RULE: the security team for any affected vendored code for the lifetime of - RULE: the release (including ESM when included) - RULE: - the security team will alert the owning team of issues that may - RULE: affect their vendored code - RULE: - the owning team will provide timely, high quality updates for the - RULE: security team to sponsor to fix issues in the affected vendored code - RULE: - the owning team will use a minimal set of vendored code (e.g., Rust - RULE: packages are unlikely to need `*_win` crates to build) - RULE: - if subsequent uploads add new vendored components or dependencies - RULE: these have to be reviewed and agreed by the security team. - RULE: - Such updates in the project might be trivial, but imply that a - RULE: dependency for e.g. a CVE fix will be moved to a new major version. - RULE: Being vendored that does gladly at least not imply incompatibility - RULE: issues with other packages or the SRU policy. But it might happen - RULE: that this triggers either: - RULE: a) The need to adapt the current version of the main package and/or - RULE: other vendored dependencies to work with the new dependency - RULE: b) The need to backport the fix in the dependency as the main - RULE: package will functionally only work well with the older version - RULE: c) The need to backport the fix in the dependency, as it would imply - RULE: requiring a newer toolchain to be buildable that isn't available - RULE: in the target release. - RULE: - The rust ecosystem currently isn't yet considered stable enough for - RULE: classic lib dependencies and transitions in main; therefore the - RULE: expectation for those packages is to vendor (and own/test) all - RULE: dependencies (except those provided by the rust runtime itself). - RULE: This implies that all the rules for vendored builds always - RULE: apply to them. In addition: - RULE: - The rules and checks for rust based packages are preliminary and might - RULE: change over time as the ecosystem matures and while - RULE: processing the first few rust based packages. - RULE: - It is expected rust builds will use dh-cargo so that a later switch - RULE: to non vendored dependencies isn't too complex (e.g. it is likely - RULE: that over time more common libs shall become stable and then archive - RULE: packages will be used to build). - RULE: - The tooling to get a Cargo.lock that will include internal vendored - RULE: dependencies is described at: - RULE: https://github.com/canonical/ubuntu-mir/blob/main/vendoring/Rust.md - RULE: - An example of how Rust dependency vendoring can be automated is - RULE: "s390-tools", isolating crates in a .orig-vendor.tar.xz tarball: - RULE: * https://git.launchpad.net/ubuntu/+source/s390-tools/tree/debian/rules - RULE: Other examples include "authd" (for a native package, combined with - RULE: Golang vendoring) and "gnome-snapshot" (using debian/missing-sources): - RULE: * authd: - RULE: https://github.com/ubuntu/authd/blob/main/debian/rules - RULE: * gnome-snapshot: - RULE: https://salsa.debian.org/ubuntu-dev-team/snapshot/-/blob/ubuntu/latest/debian/README.source + - The team Ubuntu Foundations is aware of the implications by a static build and + commits to test no-change-rebuilds and to fix any issues found for the + lifetime of the release (including ESM). - RULE: - All vendored dependencies (no matter what language) shall have a - RULE: way to be refreshed - TODO-A: - This does not use static builds - TODO-B: - The team TBD is aware of the implications by a static build and - TODO-B: commits to test no-change-rebuilds and to fix any issues found for the - TODO-B: lifetime of the release (including ESM) + - The team Ubuntu Foundations is aware of the implications of vendored code and (as + alerted by the security team) commits to provide updates and backports + to the security team for any affected vendored code for the lifetime + of the release (including ESM). - TODO-A: - This does not use vendored code - TODO-B: - The team TBD is aware of the implications of vendored code and (as - TODO-B: alerted by the security team) commits to provide updates and backports - TODO-B: to the security team for any affected vendored code for the lifetime - TODO-B: of the release (including ESM). + - This package uses vendored code, refreshing that code is outlined + in debian/README.source (in proposed merge). - TODO-A: - This does not use vendored code - TODO-B: - This package uses vendored go code tracked in go.sum as shipped in the - TODO-B: package, refreshing that code is outlined in debian/README.source - TODO-C: - This package uses vendored rust code tracked in Cargo.lock as shipped, - TODO-C: in the package (at /usr/share/doc/<pkgname>/Cargo.lock - might be - TODO-C: compressed), refreshing that code is outlined in debian/README.source - TODO-D: - This package uses vendored code, refreshing that code is outlined - TODO-D: in debian/README.source + - This package is rust based and vendors all non language-runtime + dependencies - TODO-A: - This package is not rust based - TODO-B: - This package is rust based and vendors all non language-runtime - TODO-B: dependencies - - RULE: - Some packages build and update often, in this case everyone can just - RULE: check the recent build logs to ensure if it builds fine. - RULE: But some other packages are rather stable and have not been rebuilt - RULE: in a long time. There no one can be confident it would build on e.g. - RULE: an urgent security fix. Hence we ask if there has been a recent build. - RULE: That might be a recent build that has been done anyway as seen on - RULE: https://launchpad.net/ubuntu/+source/<source>, a reference to a recent - RULE: archive test rebuild (those are announced on the ubuntu-devel mailing - RULE: list like https://lists.ubuntu.com/archives/ubuntu-devel-announce/2024-January/001342.html), - RULE: or a build set up by the reporter in a PPA with all architectures - RULE: enabled. - TODO-A: - The package has been built within the last 3 months in the archive - TODO-B: - The package has been built within the last 3 months as part - TODO-B: of a test rebuild - TODO-C: - The package has been built within the last 3 months in PPA - TODO-D: - The package has been built within the last 3 months in sbuild as it - TODO-D: can not be uploaded yet - RULE: - To make it easier for everyone, please provide a link to that build so - RULE: everyone can follow up easily e.g. checking the various architectures. - RULE: Example https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1 - TODO: - Build link on launchpad: TBD + - The package has been built within the last 3 months in PPA + - Build link on launchpad: https://launchpad.net/~bamf0/+archive/ubuntu/rust-sequoia-sq-sqv-mir-lp2089690/+packages [Background information] - Sequo + - The Package description explains the package well + - Upstream Name is rust-sequoia-sqv + - Link to upstream project: https://gitlab.com/sequoia-pgp/sequoia-sqv - RULE: - The package descriptions should explain the general purpose and context - RULE: of the package. Additional explanations/justifications should be done in - RULE: the MIR report. - RULE: - If the package was renamed recently, or has a different upstream name, - RULE: this needs to be explained in the MIR report. - TODO: The Package description explains the package well - TODO: Upstream Name is TBD - TODO: Link to upstream project TBD - TODO: TBD (any further background that might be helpful + Foundations should probably make a case for replacing GnuPG with Sequoia in + "main", filing corresponding MIRs for the needed sequoia components. - Foundations should probably make a case for replacing GnuPG with Sequoia - in "main", filing corresponding MIRs for the needed sequoia components. + MIR team usually likes to see some kind of transition plan, how to get rid of + the older alternative (GPG) when a new one is introduced. Or technical + solutions, such as a package split to ship only binary packages in main that + are non-duplicates, even though the source package of two components might have + some overlap. - MIR team usually likes to see some kind of transition plan, how to get - rid of the older alternative (GPG) when a new one is introduced. Or - technical solutions, such as a package split to ship only binary - packages in main that are non-duplicates, even though the source package - of two components might have some overlap. - - See https://github.com/canonical/ubuntu-mir/blob/main/vendoring/Rust.md - for vendoring Rust dependencies. + See https://github.com/canonical/ubuntu-mir/blob/main/vendoring/Rust.md for + vendoring Rust dependencies. ** Changed in: rust-sequoia-sqv (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2089690 Title: [MIR] rust-sequoia-sqv To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/2089690/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
