| 2024-01-09 14:35:23 |
Jean-Baptiste Lallement |
bug |
|
|
added bug |
| 2024-01-09 15:01:57 |
Jean-Baptiste Lallement |
description |
[MIR] authd |
[MIR] authd
[Availability]
TODO: The package TBDSRC is already in Ubuntu universe.
TODO: The package TBDSRC build for the architectures it is designed to work on.
TODO: It currently builds and works for architectures: TBD
TODO: Link to package https://launchpad.net/ubuntu/+source/TBDSRC
[Rationale]
RULE: There must be a certain level of demand for the package
TODO: - The package TBDSRC is required in Ubuntu main for TBD
TODO-A: - The package TBDSRC will generally be useful for a large part of
TODO-A: our user base
TODO-B: - The package TBDSRC will not generally be useful for a large part of
TODO-B: our user base, but is important/helpful still because TBD
TODO: - Additional reasons TBD
TODO: - Additionally new use-cases enabled by this are TBD
TODO: - Package TBDSRC covers the same use case as TBD, but is better
TODO: because TBD, thereby we want to replace it.
TODO: - The package TBDSRC is a new runtime dependency of package TBD that
TODO: we already support
RULE: Sometimes there are other/better ways, often are achieved by using a
RULE: library with similar functionality that is more commonly used and
RULE: thereby already in main or a better candidate to promote.
RULE: Reducing the set of supported software in Ubuntu helps to focus on the
RULE: right things, otherwise Ubuntu developers will be consumed by updating
RULE: many variations of the same - wasting valuable time that could be better
RULE: spent elsewhere.
RULE: If there are other packages in the archive that are close, but unable to
RULE: address the problem you might spend some time explaining what exists and
RULE: why it isn't a sufficient alternative.
TODO: - There is no other/better way to solve this that is already in main or
TODO: should go universe->main instead of this.
RULE: Reviews will take some time. Also the potential extra work out of review
RULE: feedback from either MIR-team and/or security-team will take time.
RULE: For better prioritization it is quite helpful to clearly state the
RULE: target release and set a milestone to the bug task.
RULE: When doing so do not describe what you "wish" or "would like to have".
RULE: Only milestones that are sufficiently well-founded and related to
RULE: major releases will be considered
TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD
TODO-A: due to TBD
TODO-B: - It would be great and useful to community/processes to have the
TODO-B: package TBD in Ubuntu main, but there is no definitive deadline.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: https://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker
RULE: https://ubuntu.com/security/cve?package=<source-package-name>
RULE: - Debian Security Tracker
RULE: https://security-tracker.debian.org/tracker/source-package/<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries, services and behavior.
RULE: If any are present, this requires a more in-depth security review.
RULE: Demonstrating that common isolation/risk-mitigation patterns are used
RULE: will help to raise confidence. For example a service running as root
RULE: open to the network will need to be considered very carefully. The same
RULE: service dropping the root permissions after initial initialization,
RULE: using various systemd isolation features and having a default active
RULE: apparmor profile is much less concerning and can speed up acceptance.
RULE: This helps Ubuntu, but you are encouraged to consider working with
RULE: Debian and upstream to get those security features used at wide scale.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO: - Security has been kept in mind and common isolation/risk-mitigation
TODO: patterns are in place utilizing the following features:
TODO: TBD (add details and links/examples about things like dropping
TODO: permissions, using temporary environments, restricted users/groups,
TODO: seccomp, systemd isolation features, apparmor, ...)
TODO-A: - Packages does not open privileged ports (ports < 1024).
TODO-B: - Packages open privileged ports (ports < 1024), but they have
TODO-B: a reason to do so (TBD)
TODO-A: - Package does not expose any external endpoints
TODO-B: - Package does not expose an external endpoint, it is
TODO-B: TBD endpoint + TBD purpose
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu/Upstream and does
TODO: not have too many, long-term & critical, open bugs
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - Upstream's bug tracker, e.g., GitHub Issues
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial).
RULE: If possible such things should stay in universe. Sometimes that is
RULE: impossible due to the way how features/plugins/dependencies work
RULE: but if you are going to ask for promotion of something untestable
RULE: please outline why it couldn't provide its value (e.g. by splitting
RULE: binaries) to users from universe.
RULE: This is a balance that is hard to strike well, the request is that all
RULE: options have been exploited before giving up. Look for more details
RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30
RULE: Just like in the SRU process it is worth to understand what the
RULE: consequences a regression (due to a test miss) would be. Therefore
RULE: if being untestable we ask to outline what consequences this would
RULE: have for the given package. And let us be honest, even if you can
RULE: test you are never sure you will be able to catch all potential
RULE: regressions. So this is mostly to force self-awareness of the owning
RULE: team than to make a decision on.
TODO: - The package can not be well tested at build or autopkgtest time
TODO: because TBD. To make up for that:
TODO-A: - We have access to such hardware in the team
TODO-B: - We have allocated budget to get this hardware, but it is not here
TODO-B: yet
TODO-C: - We have checked with solutions-qa and will use their hardware
TODO-C: through testflinger
TODO-D: - We have checked with other team TBD and will use their hardware
TODO-D: through TBD (eg. MAAS)
TODO-E: - We have checked and found a simulator which covers this case
TODO-E: sufficiently for testing, our plan to use it is TBD
TODO-F: - We have engaged with the upstream community and due to that
TODO-F: can tests new package builds via TBD
TODO-G: - We have engaged with our user community and due to that
TODO-G: can tests new package builds via TBD
TODO-H: - We have engaged with the hardware manufacturer and made an
TODO-H: agreement to test new builds via TBD
TODO-A-H: - Based on that access outlined above, here are the details of the
TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already
TODO-A-H: possible) example output of a test run: TBD (logs).
TODO-A-H: We will execute that test plan
TODO-A-H1: on-uploads
TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url)
TODO-X: - We have exhausted all options, there really is no feasible way
TODO-X: to test or recreate this. We are aware of the extra implications
TODO-X: and duties this has for our team (= help SEG and security on
TODO-X: servicing this package, but also more effort on any of your own
TODO-X: bug triage and fixes).
TODO-X: Due to TBD there also is no way to provide this to users from
TODO-X: universe.
TODO-X: Due to the nature, integration and use cases of the package the
TODO-X: consequences of a regression that might slip through most likely
TODO-X: would include
TODO-X: - TBD
TODO-X: - TBD
TODO-X: - TBD
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
RULE: - The package uses a debian/watch file whenever possible. In cases where
RULE: this is not possible (e.g. native packages), the package should either
RULE: provide a debian/README.source file or a debian/watch file (with
RULE: comments only) providing clear instructions on how to generate the
RULE: source tar file.
TODO-A: - debian/watch is present and works
TODO-B: - debian/watch is not present, instead it has TBD
TODO-C: - debian/watch is not present because it is a native package
RULE: - The package should define the correct "Maintainer:" field in
RULE: debian/control. This needs to be updated, using `update-maintainer`
RULE: whenever any Ubuntu delta is applied to the package, as suggested by
RULE: dpkg (LP: #1951988)
TODO: - 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
RULE: - The package should not rely on obsolete or about to be demoted packages.
RULE: That currently includes package dependencies on Python2 (without
RULE: providing Python3 packages), and packages depending on GTK2.
TODO: - This package does not rely on obsolete or about to be demoted packages.
TODO: - 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
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
[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
[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.
[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
[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: - 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
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: - 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: debian/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: debian/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: debian/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-source"
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)
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).
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
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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[Background information]
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 |
|
| 2024-01-09 15:46:45 |
Jean-Baptiste Lallement |
description |
[MIR] authd
[Availability]
TODO: The package TBDSRC is already in Ubuntu universe.
TODO: The package TBDSRC build for the architectures it is designed to work on.
TODO: It currently builds and works for architectures: TBD
TODO: Link to package https://launchpad.net/ubuntu/+source/TBDSRC
[Rationale]
RULE: There must be a certain level of demand for the package
TODO: - The package TBDSRC is required in Ubuntu main for TBD
TODO-A: - The package TBDSRC will generally be useful for a large part of
TODO-A: our user base
TODO-B: - The package TBDSRC will not generally be useful for a large part of
TODO-B: our user base, but is important/helpful still because TBD
TODO: - Additional reasons TBD
TODO: - Additionally new use-cases enabled by this are TBD
TODO: - Package TBDSRC covers the same use case as TBD, but is better
TODO: because TBD, thereby we want to replace it.
TODO: - The package TBDSRC is a new runtime dependency of package TBD that
TODO: we already support
RULE: Sometimes there are other/better ways, often are achieved by using a
RULE: library with similar functionality that is more commonly used and
RULE: thereby already in main or a better candidate to promote.
RULE: Reducing the set of supported software in Ubuntu helps to focus on the
RULE: right things, otherwise Ubuntu developers will be consumed by updating
RULE: many variations of the same - wasting valuable time that could be better
RULE: spent elsewhere.
RULE: If there are other packages in the archive that are close, but unable to
RULE: address the problem you might spend some time explaining what exists and
RULE: why it isn't a sufficient alternative.
TODO: - There is no other/better way to solve this that is already in main or
TODO: should go universe->main instead of this.
RULE: Reviews will take some time. Also the potential extra work out of review
RULE: feedback from either MIR-team and/or security-team will take time.
RULE: For better prioritization it is quite helpful to clearly state the
RULE: target release and set a milestone to the bug task.
RULE: When doing so do not describe what you "wish" or "would like to have".
RULE: Only milestones that are sufficiently well-founded and related to
RULE: major releases will be considered
TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD
TODO-A: due to TBD
TODO-B: - It would be great and useful to community/processes to have the
TODO-B: package TBD in Ubuntu main, but there is no definitive deadline.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: https://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker
RULE: https://ubuntu.com/security/cve?package=<source-package-name>
RULE: - Debian Security Tracker
RULE: https://security-tracker.debian.org/tracker/source-package/<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries, services and behavior.
RULE: If any are present, this requires a more in-depth security review.
RULE: Demonstrating that common isolation/risk-mitigation patterns are used
RULE: will help to raise confidence. For example a service running as root
RULE: open to the network will need to be considered very carefully. The same
RULE: service dropping the root permissions after initial initialization,
RULE: using various systemd isolation features and having a default active
RULE: apparmor profile is much less concerning and can speed up acceptance.
RULE: This helps Ubuntu, but you are encouraged to consider working with
RULE: Debian and upstream to get those security features used at wide scale.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO: - Security has been kept in mind and common isolation/risk-mitigation
TODO: patterns are in place utilizing the following features:
TODO: TBD (add details and links/examples about things like dropping
TODO: permissions, using temporary environments, restricted users/groups,
TODO: seccomp, systemd isolation features, apparmor, ...)
TODO-A: - Packages does not open privileged ports (ports < 1024).
TODO-B: - Packages open privileged ports (ports < 1024), but they have
TODO-B: a reason to do so (TBD)
TODO-A: - Package does not expose any external endpoints
TODO-B: - Package does not expose an external endpoint, it is
TODO-B: TBD endpoint + TBD purpose
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu/Upstream and does
TODO: not have too many, long-term & critical, open bugs
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - Upstream's bug tracker, e.g., GitHub Issues
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial).
RULE: If possible such things should stay in universe. Sometimes that is
RULE: impossible due to the way how features/plugins/dependencies work
RULE: but if you are going to ask for promotion of something untestable
RULE: please outline why it couldn't provide its value (e.g. by splitting
RULE: binaries) to users from universe.
RULE: This is a balance that is hard to strike well, the request is that all
RULE: options have been exploited before giving up. Look for more details
RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30
RULE: Just like in the SRU process it is worth to understand what the
RULE: consequences a regression (due to a test miss) would be. Therefore
RULE: if being untestable we ask to outline what consequences this would
RULE: have for the given package. And let us be honest, even if you can
RULE: test you are never sure you will be able to catch all potential
RULE: regressions. So this is mostly to force self-awareness of the owning
RULE: team than to make a decision on.
TODO: - The package can not be well tested at build or autopkgtest time
TODO: because TBD. To make up for that:
TODO-A: - We have access to such hardware in the team
TODO-B: - We have allocated budget to get this hardware, but it is not here
TODO-B: yet
TODO-C: - We have checked with solutions-qa and will use their hardware
TODO-C: through testflinger
TODO-D: - We have checked with other team TBD and will use their hardware
TODO-D: through TBD (eg. MAAS)
TODO-E: - We have checked and found a simulator which covers this case
TODO-E: sufficiently for testing, our plan to use it is TBD
TODO-F: - We have engaged with the upstream community and due to that
TODO-F: can tests new package builds via TBD
TODO-G: - We have engaged with our user community and due to that
TODO-G: can tests new package builds via TBD
TODO-H: - We have engaged with the hardware manufacturer and made an
TODO-H: agreement to test new builds via TBD
TODO-A-H: - Based on that access outlined above, here are the details of the
TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already
TODO-A-H: possible) example output of a test run: TBD (logs).
TODO-A-H: We will execute that test plan
TODO-A-H1: on-uploads
TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url)
TODO-X: - We have exhausted all options, there really is no feasible way
TODO-X: to test or recreate this. We are aware of the extra implications
TODO-X: and duties this has for our team (= help SEG and security on
TODO-X: servicing this package, but also more effort on any of your own
TODO-X: bug triage and fixes).
TODO-X: Due to TBD there also is no way to provide this to users from
TODO-X: universe.
TODO-X: Due to the nature, integration and use cases of the package the
TODO-X: consequences of a regression that might slip through most likely
TODO-X: would include
TODO-X: - TBD
TODO-X: - TBD
TODO-X: - TBD
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
RULE: - The package uses a debian/watch file whenever possible. In cases where
RULE: this is not possible (e.g. native packages), the package should either
RULE: provide a debian/README.source file or a debian/watch file (with
RULE: comments only) providing clear instructions on how to generate the
RULE: source tar file.
TODO-A: - debian/watch is present and works
TODO-B: - debian/watch is not present, instead it has TBD
TODO-C: - debian/watch is not present because it is a native package
RULE: - The package should define the correct "Maintainer:" field in
RULE: debian/control. This needs to be updated, using `update-maintainer`
RULE: whenever any Ubuntu delta is applied to the package, as suggested by
RULE: dpkg (LP: #1951988)
TODO: - 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
RULE: - The package should not rely on obsolete or about to be demoted packages.
RULE: That currently includes package dependencies on Python2 (without
RULE: providing Python3 packages), and packages depending on GTK2.
TODO: - This package does not rely on obsolete or about to be demoted packages.
TODO: - 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
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
[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
[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.
[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
[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: - 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
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: - 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: debian/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: debian/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: debian/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-source"
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)
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).
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
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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[Background information]
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 |
/!\ IN PROGRESS /!\
[MIR] authd
[Availability]
TODO: The package TBDSRC is already in Ubuntu universe.
TODO: The package TBDSRC build for the architectures it is designed to work on.
TODO: It currently builds and works for architectures: TBD
TODO: Link to package https://launchpad.net/ubuntu/+source/TBDSRC
[Rationale]
RULE: There must be a certain level of demand for the package
TODO: - The package TBDSRC is required in Ubuntu main for TBD
TODO-A: - The package TBDSRC will generally be useful for a large part of
TODO-A: our user base
TODO-B: - The package TBDSRC will not generally be useful for a large part of
TODO-B: our user base, but is important/helpful still because TBD
TODO: - Additional reasons TBD
TODO: - Additionally new use-cases enabled by this are TBD
TODO: - Package TBDSRC covers the same use case as TBD, but is better
TODO: because TBD, thereby we want to replace it.
TODO: - The package TBDSRC is a new runtime dependency of package TBD that
TODO: we already support
RULE: Sometimes there are other/better ways, often are achieved by using a
RULE: library with similar functionality that is more commonly used and
RULE: thereby already in main or a better candidate to promote.
RULE: Reducing the set of supported software in Ubuntu helps to focus on the
RULE: right things, otherwise Ubuntu developers will be consumed by updating
RULE: many variations of the same - wasting valuable time that could be better
RULE: spent elsewhere.
RULE: If there are other packages in the archive that are close, but unable to
RULE: address the problem you might spend some time explaining what exists and
RULE: why it isn't a sufficient alternative.
TODO: - There is no other/better way to solve this that is already in main or
TODO: should go universe->main instead of this.
RULE: Reviews will take some time. Also the potential extra work out of review
RULE: feedback from either MIR-team and/or security-team will take time.
RULE: For better prioritization it is quite helpful to clearly state the
RULE: target release and set a milestone to the bug task.
RULE: When doing so do not describe what you "wish" or "would like to have".
RULE: Only milestones that are sufficiently well-founded and related to
RULE: major releases will be considered
TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD
TODO-A: due to TBD
TODO-B: - It would be great and useful to community/processes to have the
TODO-B: package TBD in Ubuntu main, but there is no definitive deadline.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: https://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker
RULE: https://ubuntu.com/security/cve?package=<source-package-name>
RULE: - Debian Security Tracker
RULE: https://security-tracker.debian.org/tracker/source-package/<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries, services and behavior.
RULE: If any are present, this requires a more in-depth security review.
RULE: Demonstrating that common isolation/risk-mitigation patterns are used
RULE: will help to raise confidence. For example a service running as root
RULE: open to the network will need to be considered very carefully. The same
RULE: service dropping the root permissions after initial initialization,
RULE: using various systemd isolation features and having a default active
RULE: apparmor profile is much less concerning and can speed up acceptance.
RULE: This helps Ubuntu, but you are encouraged to consider working with
RULE: Debian and upstream to get those security features used at wide scale.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO: - Security has been kept in mind and common isolation/risk-mitigation
TODO: patterns are in place utilizing the following features:
TODO: TBD (add details and links/examples about things like dropping
TODO: permissions, using temporary environments, restricted users/groups,
TODO: seccomp, systemd isolation features, apparmor, ...)
TODO-A: - Packages does not open privileged ports (ports < 1024).
TODO-B: - Packages open privileged ports (ports < 1024), but they have
TODO-B: a reason to do so (TBD)
TODO-A: - Package does not expose any external endpoints
TODO-B: - Package does not expose an external endpoint, it is
TODO-B: TBD endpoint + TBD purpose
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu/Upstream and does
TODO: not have too many, long-term & critical, open bugs
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - Upstream's bug tracker, e.g., GitHub Issues
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial).
RULE: If possible such things should stay in universe. Sometimes that is
RULE: impossible due to the way how features/plugins/dependencies work
RULE: but if you are going to ask for promotion of something untestable
RULE: please outline why it couldn't provide its value (e.g. by splitting
RULE: binaries) to users from universe.
RULE: This is a balance that is hard to strike well, the request is that all
RULE: options have been exploited before giving up. Look for more details
RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30
RULE: Just like in the SRU process it is worth to understand what the
RULE: consequences a regression (due to a test miss) would be. Therefore
RULE: if being untestable we ask to outline what consequences this would
RULE: have for the given package. And let us be honest, even if you can
RULE: test you are never sure you will be able to catch all potential
RULE: regressions. So this is mostly to force self-awareness of the owning
RULE: team than to make a decision on.
TODO: - The package can not be well tested at build or autopkgtest time
TODO: because TBD. To make up for that:
TODO-A: - We have access to such hardware in the team
TODO-B: - We have allocated budget to get this hardware, but it is not here
TODO-B: yet
TODO-C: - We have checked with solutions-qa and will use their hardware
TODO-C: through testflinger
TODO-D: - We have checked with other team TBD and will use their hardware
TODO-D: through TBD (eg. MAAS)
TODO-E: - We have checked and found a simulator which covers this case
TODO-E: sufficiently for testing, our plan to use it is TBD
TODO-F: - We have engaged with the upstream community and due to that
TODO-F: can tests new package builds via TBD
TODO-G: - We have engaged with our user community and due to that
TODO-G: can tests new package builds via TBD
TODO-H: - We have engaged with the hardware manufacturer and made an
TODO-H: agreement to test new builds via TBD
TODO-A-H: - Based on that access outlined above, here are the details of the
TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already
TODO-A-H: possible) example output of a test run: TBD (logs).
TODO-A-H: We will execute that test plan
TODO-A-H1: on-uploads
TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url)
TODO-X: - We have exhausted all options, there really is no feasible way
TODO-X: to test or recreate this. We are aware of the extra implications
TODO-X: and duties this has for our team (= help SEG and security on
TODO-X: servicing this package, but also more effort on any of your own
TODO-X: bug triage and fixes).
TODO-X: Due to TBD there also is no way to provide this to users from
TODO-X: universe.
TODO-X: Due to the nature, integration and use cases of the package the
TODO-X: consequences of a regression that might slip through most likely
TODO-X: would include
TODO-X: - TBD
TODO-X: - TBD
TODO-X: - TBD
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
RULE: - The package uses a debian/watch file whenever possible. In cases where
RULE: this is not possible (e.g. native packages), the package should either
RULE: provide a debian/README.source file or a debian/watch file (with
RULE: comments only) providing clear instructions on how to generate the
RULE: source tar file.
TODO-A: - debian/watch is present and works
TODO-B: - debian/watch is not present, instead it has TBD
TODO-C: - debian/watch is not present because it is a native package
RULE: - The package should define the correct "Maintainer:" field in
RULE: debian/control. This needs to be updated, using `update-maintainer`
RULE: whenever any Ubuntu delta is applied to the package, as suggested by
RULE: dpkg (LP: #1951988)
TODO: - 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
RULE: - The package should not rely on obsolete or about to be demoted packages.
RULE: That currently includes package dependencies on Python2 (without
RULE: providing Python3 packages), and packages depending on GTK2.
TODO: - This package does not rely on obsolete or about to be demoted packages.
TODO: - 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
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
[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
[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.
[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
[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: - 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
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: - 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: debian/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: debian/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: debian/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-source"
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)
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).
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
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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[Background information]
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 |
|
| 2024-01-10 09:00:42 |
Jean-Baptiste Lallement |
description |
/!\ IN PROGRESS /!\
[MIR] authd
[Availability]
TODO: The package TBDSRC is already in Ubuntu universe.
TODO: The package TBDSRC build for the architectures it is designed to work on.
TODO: It currently builds and works for architectures: TBD
TODO: Link to package https://launchpad.net/ubuntu/+source/TBDSRC
[Rationale]
RULE: There must be a certain level of demand for the package
TODO: - The package TBDSRC is required in Ubuntu main for TBD
TODO-A: - The package TBDSRC will generally be useful for a large part of
TODO-A: our user base
TODO-B: - The package TBDSRC will not generally be useful for a large part of
TODO-B: our user base, but is important/helpful still because TBD
TODO: - Additional reasons TBD
TODO: - Additionally new use-cases enabled by this are TBD
TODO: - Package TBDSRC covers the same use case as TBD, but is better
TODO: because TBD, thereby we want to replace it.
TODO: - The package TBDSRC is a new runtime dependency of package TBD that
TODO: we already support
RULE: Sometimes there are other/better ways, often are achieved by using a
RULE: library with similar functionality that is more commonly used and
RULE: thereby already in main or a better candidate to promote.
RULE: Reducing the set of supported software in Ubuntu helps to focus on the
RULE: right things, otherwise Ubuntu developers will be consumed by updating
RULE: many variations of the same - wasting valuable time that could be better
RULE: spent elsewhere.
RULE: If there are other packages in the archive that are close, but unable to
RULE: address the problem you might spend some time explaining what exists and
RULE: why it isn't a sufficient alternative.
TODO: - There is no other/better way to solve this that is already in main or
TODO: should go universe->main instead of this.
RULE: Reviews will take some time. Also the potential extra work out of review
RULE: feedback from either MIR-team and/or security-team will take time.
RULE: For better prioritization it is quite helpful to clearly state the
RULE: target release and set a milestone to the bug task.
RULE: When doing so do not describe what you "wish" or "would like to have".
RULE: Only milestones that are sufficiently well-founded and related to
RULE: major releases will be considered
TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD
TODO-A: due to TBD
TODO-B: - It would be great and useful to community/processes to have the
TODO-B: package TBD in Ubuntu main, but there is no definitive deadline.
[Security]
RULE: The security history and the current state of security issues in the
RULE: package must allow us to support the package for at least 9 months (120
RULE: for LTS+ESM support) without exposing its users to an inappropriate level
RULE: of security risks. This requires checking of several things:
RULE: - Search in the National Vulnerability Database using the PKG as keyword
RULE: https://cve.mitre.org/cve/search_cve_list.html
RULE: - check OSS security mailing list (feed into search engine
RULE: 'site:www.openwall.com/lists/oss-security <pkgname>')
RULE: - Ubuntu CVE Tracker
RULE: https://ubuntu.com/security/cve?package=<source-package-name>
RULE: - Debian Security Tracker
RULE: https://security-tracker.debian.org/tracker/source-package/<source-package-name>
TODO-A: - Had #TBD security issues in the past
TODO-A: - TBD links to such security issues in trackers
TODO-A: - TBD to any context that shows how these issues got handled in
TODO-A: the past
TODO-B: - No CVEs/security issues in this software in the past
RULE: - Check for security relevant binaries, services and behavior.
RULE: If any are present, this requires a more in-depth security review.
RULE: Demonstrating that common isolation/risk-mitigation patterns are used
RULE: will help to raise confidence. For example a service running as root
RULE: open to the network will need to be considered very carefully. The same
RULE: service dropping the root permissions after initial initialization,
RULE: using various systemd isolation features and having a default active
RULE: apparmor profile is much less concerning and can speed up acceptance.
RULE: This helps Ubuntu, but you are encouraged to consider working with
RULE: Debian and upstream to get those security features used at wide scale.
TODO: - no `suid` or `sgid` binaries
TODO-A: - no executables in `/sbin` and `/usr/sbin`
TODO-B: - Binary TBD in sbin is no problem because TBD
TODO-A: - Package does not install services, timers or recurring jobs
TODO-B: - Package does install services, timers or recurring jobs
TODO-B: TBD (list services, timers, jobs)
TODO: - Security has been kept in mind and common isolation/risk-mitigation
TODO: patterns are in place utilizing the following features:
TODO: TBD (add details and links/examples about things like dropping
TODO: permissions, using temporary environments, restricted users/groups,
TODO: seccomp, systemd isolation features, apparmor, ...)
TODO-A: - Packages does not open privileged ports (ports < 1024).
TODO-B: - Packages open privileged ports (ports < 1024), but they have
TODO-B: a reason to do so (TBD)
TODO-A: - Package does not expose any external endpoints
TODO-B: - Package does not expose an external endpoint, it is
TODO-B: TBD endpoint + TBD purpose
TODO: - Packages does not contain extensions to security-sensitive software
TODO: (filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu/Upstream and does
TODO: not have too many, long-term & critical, open bugs
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - Upstream's bug tracker, e.g., GitHub Issues
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial).
RULE: If possible such things should stay in universe. Sometimes that is
RULE: impossible due to the way how features/plugins/dependencies work
RULE: but if you are going to ask for promotion of something untestable
RULE: please outline why it couldn't provide its value (e.g. by splitting
RULE: binaries) to users from universe.
RULE: This is a balance that is hard to strike well, the request is that all
RULE: options have been exploited before giving up. Look for more details
RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30
RULE: Just like in the SRU process it is worth to understand what the
RULE: consequences a regression (due to a test miss) would be. Therefore
RULE: if being untestable we ask to outline what consequences this would
RULE: have for the given package. And let us be honest, even if you can
RULE: test you are never sure you will be able to catch all potential
RULE: regressions. So this is mostly to force self-awareness of the owning
RULE: team than to make a decision on.
TODO: - The package can not be well tested at build or autopkgtest time
TODO: because TBD. To make up for that:
TODO-A: - We have access to such hardware in the team
TODO-B: - We have allocated budget to get this hardware, but it is not here
TODO-B: yet
TODO-C: - We have checked with solutions-qa and will use their hardware
TODO-C: through testflinger
TODO-D: - We have checked with other team TBD and will use their hardware
TODO-D: through TBD (eg. MAAS)
TODO-E: - We have checked and found a simulator which covers this case
TODO-E: sufficiently for testing, our plan to use it is TBD
TODO-F: - We have engaged with the upstream community and due to that
TODO-F: can tests new package builds via TBD
TODO-G: - We have engaged with our user community and due to that
TODO-G: can tests new package builds via TBD
TODO-H: - We have engaged with the hardware manufacturer and made an
TODO-H: agreement to test new builds via TBD
TODO-A-H: - Based on that access outlined above, here are the details of the
TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already
TODO-A-H: possible) example output of a test run: TBD (logs).
TODO-A-H: We will execute that test plan
TODO-A-H1: on-uploads
TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url)
TODO-X: - We have exhausted all options, there really is no feasible way
TODO-X: to test or recreate this. We are aware of the extra implications
TODO-X: and duties this has for our team (= help SEG and security on
TODO-X: servicing this package, but also more effort on any of your own
TODO-X: bug triage and fixes).
TODO-X: Due to TBD there also is no way to provide this to users from
TODO-X: universe.
TODO-X: Due to the nature, integration and use cases of the package the
TODO-X: consequences of a regression that might slip through most likely
TODO-X: would include
TODO-X: - TBD
TODO-X: - TBD
TODO-X: - TBD
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
RULE: - The package uses a debian/watch file whenever possible. In cases where
RULE: this is not possible (e.g. native packages), the package should either
RULE: provide a debian/README.source file or a debian/watch file (with
RULE: comments only) providing clear instructions on how to generate the
RULE: source tar file.
TODO-A: - debian/watch is present and works
TODO-B: - debian/watch is not present, instead it has TBD
TODO-C: - debian/watch is not present because it is a native package
RULE: - The package should define the correct "Maintainer:" field in
RULE: debian/control. This needs to be updated, using `update-maintainer`
RULE: whenever any Ubuntu delta is applied to the package, as suggested by
RULE: dpkg (LP: #1951988)
TODO: - 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
RULE: - The package should not rely on obsolete or about to be demoted packages.
RULE: That currently includes package dependencies on Python2 (without
RULE: providing Python3 packages), and packages depending on GTK2.
TODO: - This package does not rely on obsolete or about to be demoted packages.
TODO: - 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
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
[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
[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.
[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
[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: - 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
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: - 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: debian/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: debian/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: debian/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-source"
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)
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).
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
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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[Background information]
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 |
/!\ IN PROGRESS /!\
[MIR] authd
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS Noble Numbat 24.04.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd.
It also installs a PAM module and an NSS module.
**TODO**: Document open ports and systemd confinement
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: (add details and links/examples about things like dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu/Upstream and does
TODO: not have too many, long-term & critical, open bugs
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - Upstream's bug tracker, e.g., GitHub Issues
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial).
RULE: If possible such things should stay in universe. Sometimes that is
RULE: impossible due to the way how features/plugins/dependencies work
RULE: but if you are going to ask for promotion of something untestable
RULE: please outline why it couldn't provide its value (e.g. by splitting
RULE: binaries) to users from universe.
RULE: This is a balance that is hard to strike well, the request is that all
RULE: options have been exploited before giving up. Look for more details
RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30
RULE: Just like in the SRU process it is worth to understand what the
RULE: consequences a regression (due to a test miss) would be. Therefore
RULE: if being untestable we ask to outline what consequences this would
RULE: have for the given package. And let us be honest, even if you can
RULE: test you are never sure you will be able to catch all potential
RULE: regressions. So this is mostly to force self-awareness of the owning
RULE: team than to make a decision on.
TODO: - The package can not be well tested at build or autopkgtest time
TODO: because TBD. To make up for that:
TODO-A: - We have access to such hardware in the team
TODO-B: - We have allocated budget to get this hardware, but it is not here
TODO-B: yet
TODO-C: - We have checked with solutions-qa and will use their hardware
TODO-C: through testflinger
TODO-D: - We have checked with other team TBD and will use their hardware
TODO-D: through TBD (eg. MAAS)
TODO-E: - We have checked and found a simulator which covers this case
TODO-E: sufficiently for testing, our plan to use it is TBD
TODO-F: - We have engaged with the upstream community and due to that
TODO-F: can tests new package builds via TBD
TODO-G: - We have engaged with our user community and due to that
TODO-G: can tests new package builds via TBD
TODO-H: - We have engaged with the hardware manufacturer and made an
TODO-H: agreement to test new builds via TBD
TODO-A-H: - Based on that access outlined above, here are the details of the
TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already
TODO-A-H: possible) example output of a test run: TBD (logs).
TODO-A-H: We will execute that test plan
TODO-A-H1: on-uploads
TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url)
TODO-X: - We have exhausted all options, there really is no feasible way
TODO-X: to test or recreate this. We are aware of the extra implications
TODO-X: and duties this has for our team (= help SEG and security on
TODO-X: servicing this package, but also more effort on any of your own
TODO-X: bug triage and fixes).
TODO-X: Due to TBD there also is no way to provide this to users from
TODO-X: universe.
TODO-X: Due to the nature, integration and use cases of the package the
TODO-X: consequences of a regression that might slip through most likely
TODO-X: would include
TODO-X: - TBD
TODO-X: - TBD
TODO-X: - TBD
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
RULE: - The package uses a debian/watch file whenever possible. In cases where
RULE: this is not possible (e.g. native packages), the package should either
RULE: provide a debian/README.source file or a debian/watch file (with
RULE: comments only) providing clear instructions on how to generate the
RULE: source tar file.
TODO-A: - debian/watch is present and works
TODO-B: - debian/watch is not present, instead it has TBD
TODO-C: - debian/watch is not present because it is a native package
RULE: - The package should define the correct "Maintainer:" field in
RULE: debian/control. This needs to be updated, using `update-maintainer`
RULE: whenever any Ubuntu delta is applied to the package, as suggested by
RULE: dpkg (LP: #1951988)
TODO: - 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
RULE: - The package should not rely on obsolete or about to be demoted packages.
RULE: That currently includes package dependencies on Python2 (without
RULE: providing Python3 packages), and packages depending on GTK2.
TODO: - This package does not rely on obsolete or about to be demoted packages.
TODO: - 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
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
[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
[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.
[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
[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: - 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
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: - 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: debian/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: debian/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: debian/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-source"
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)
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).
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
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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[Background information]
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 |
|
| 2024-01-11 16:00:47 |
Jean-Baptiste Lallement |
description |
/!\ IN PROGRESS /!\
[MIR] authd
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS Noble Numbat 24.04.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd.
It also installs a PAM module and an NSS module.
**TODO**: Document open ports and systemd confinement
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: (add details and links/examples about things like dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
[Quality assurance - function/usage]
RULE: - After installing the package it must be possible to make it working with
RULE: a reasonable effort of configuration and documentation reading.
TODO-A: - The package works well right after install
TODO-B: - The package needs post install configuration or reading of
TODO-B: documentation, there isn't a safe default because TBD
[Quality assurance - maintenance]
RULE: - To support a package, we must be reasonably convinced that upstream
RULE: supports and cares for the package.
RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
RULE: tracking systems must be evaluated. Important bugs must be pointed out
RULE: and discussed in the MIR report.
TODO: - The package is maintained well in Debian/Ubuntu/Upstream and does
TODO: not have too many, long-term & critical, open bugs
TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/TBDSRC/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=TBDSRC
TODO: - Upstream's bug tracker, e.g., GitHub Issues
TODO: - The package has important open bugs, listing them: TBD
TODO-A: - The package does not deal with exotic hardware we cannot support
TODO-B: - The package does deal with exotic hardware, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
RULE: - The package must include a non-trivial test suite
RULE: - it should run at package build and fail the build if broken
TODO-A: - The package runs a test suite on build time, if it fails
TODO-A: it makes the build fail, link to build log TBD
TODO-B: - The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial).
RULE: If possible such things should stay in universe. Sometimes that is
RULE: impossible due to the way how features/plugins/dependencies work
RULE: but if you are going to ask for promotion of something untestable
RULE: please outline why it couldn't provide its value (e.g. by splitting
RULE: binaries) to users from universe.
RULE: This is a balance that is hard to strike well, the request is that all
RULE: options have been exploited before giving up. Look for more details
RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30
RULE: Just like in the SRU process it is worth to understand what the
RULE: consequences a regression (due to a test miss) would be. Therefore
RULE: if being untestable we ask to outline what consequences this would
RULE: have for the given package. And let us be honest, even if you can
RULE: test you are never sure you will be able to catch all potential
RULE: regressions. So this is mostly to force self-awareness of the owning
RULE: team than to make a decision on.
TODO: - The package can not be well tested at build or autopkgtest time
TODO: because TBD. To make up for that:
TODO-A: - We have access to such hardware in the team
TODO-B: - We have allocated budget to get this hardware, but it is not here
TODO-B: yet
TODO-C: - We have checked with solutions-qa and will use their hardware
TODO-C: through testflinger
TODO-D: - We have checked with other team TBD and will use their hardware
TODO-D: through TBD (eg. MAAS)
TODO-E: - We have checked and found a simulator which covers this case
TODO-E: sufficiently for testing, our plan to use it is TBD
TODO-F: - We have engaged with the upstream community and due to that
TODO-F: can tests new package builds via TBD
TODO-G: - We have engaged with our user community and due to that
TODO-G: can tests new package builds via TBD
TODO-H: - We have engaged with the hardware manufacturer and made an
TODO-H: agreement to test new builds via TBD
TODO-A-H: - Based on that access outlined above, here are the details of the
TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already
TODO-A-H: possible) example output of a test run: TBD (logs).
TODO-A-H: We will execute that test plan
TODO-A-H1: on-uploads
TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url)
TODO-X: - We have exhausted all options, there really is no feasible way
TODO-X: to test or recreate this. We are aware of the extra implications
TODO-X: and duties this has for our team (= help SEG and security on
TODO-X: servicing this package, but also more effort on any of your own
TODO-X: bug triage and fixes).
TODO-X: Due to TBD there also is no way to provide this to users from
TODO-X: universe.
TODO-X: Due to the nature, integration and use cases of the package the
TODO-X: consequences of a regression that might slip through most likely
TODO-X: would include
TODO-X: - TBD
TODO-X: - TBD
TODO-X: - TBD
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
RULE: - The package uses a debian/watch file whenever possible. In cases where
RULE: this is not possible (e.g. native packages), the package should either
RULE: provide a debian/README.source file or a debian/watch file (with
RULE: comments only) providing clear instructions on how to generate the
RULE: source tar file.
TODO-A: - debian/watch is present and works
TODO-B: - debian/watch is not present, instead it has TBD
TODO-C: - debian/watch is not present because it is a native package
RULE: - The package should define the correct "Maintainer:" field in
RULE: debian/control. This needs to be updated, using `update-maintainer`
RULE: whenever any Ubuntu delta is applied to the package, as suggested by
RULE: dpkg (LP: #1951988)
TODO: - 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
RULE: - The package should not rely on obsolete or about to be demoted packages.
RULE: That currently includes package dependencies on Python2 (without
RULE: providing Python3 packages), and packages depending on GTK2.
TODO: - This package does not rely on obsolete or about to be demoted packages.
TODO: - 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
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
[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
[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.
[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
[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: - 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
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: - 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: - Right now that tooling to get a Cargo.lock that will include internal
RULE: vendored dependencies isn't in place yet (expect a dh-cargo change
RULE: later). Until it is available, as a fallback one can scan the
RULE: directory at build time and let it be generated in debian/rules.
RULE: An example might look like:
RULE: debian/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: debian/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: debian/config.toml
RULE: # Use the vendorized sources to produce the Cargo.lock file. This
RULE: # can be performed by pointing $CARGO_HOME to the path containing
RULE: # this file.
RULE: [source]
RULE: [source.my-vendor-source]
RULE: directory = "vendor"
RULE: [source.crates-io]
RULE: replace-with = "my-vendor-source"
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)
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).
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
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: - if there has been an archive test rebuild that has occurred more recently
RULE: than the last upload, the package must have rebuilt successfully
TODO-A: - The package has been built in the archive more recently than the last
TODO-A: test rebuild
TODO-B: - The package successfully built during the most recent test rebuild
TODO-C: - The package was test rebuilt in PPA or sbuild recently (provide link/logs)
[Background information]
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 |
/!\ IN PROGRESS /!\
https://bugs.launchpad.net/ubuntu/+source/authd/+bug/2048781
[MIR] authd
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS Noble Numbat 24.04.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd.
It also installs a PAM module and an NSS module.
Communication between authd and its brokers is done over DBus
This requires a security review.
TODO: Document open ports and systemd confinement
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: (add details and links/examples about things like dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
[Quality assurance - function/usage]
The package needs post install configuration and reading of documentation. There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
[Quality assurance - maintenance]
The Ubuntu Desktop team maintains this package. It doesn’t have any long-term and critical, open bugs.
https://github.com/ubuntu/authd/issues
https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
The testsuite runs at build time. The branch coverage is 89%.
https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
https://app.codecov.io/gh/ubuntu/authd
The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
Upstream CI also includes code sanity checks.
[Quality assurance - packaging]
There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
This package does not yield massive lintian Warnings, Errors
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
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
The package will not be installed by default
Packaging and build is easy: https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
[Dependencies]
No further depends or recommends dependencies that are not yet in main
[Standards compliance]
This package correctly follows FHS
This package violates Debian Policy. It vendorizes various Go and Rust libraries.
[Maintenance/Owner]
- The owning team will be ubuntu-desktop and I have their acknowledgement for
- The future owning team is not yet subscribed, but will subscribe to the package before promotion
- The team ubuntu-desktop 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).
- The team ubuntu-desktop is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies
[Background information]
The Package description explains the package well
Upstream Name is authd
Link to upstream project https://github.com/ubuntu/authd
Example
[Rationale]
The package libgetopt-long-descriptive-perl is required in Ubuntu main for libmail-dkim-perl
The package libgetopt-long-descriptive-perl will not generally be useful for a large part of
our user base, but is important/helpful still because is required as runtime dependency by libmail-dkim-perl
that is already in main.
libmail-dkim-perl it's a perl module to cryptographically identify the sender of email (implementing the new Domain Keys Identified Mail (DKIM)), used by spamassassin
and amavisd-new. The following change added to libmail-dkim-perl makes it necessary to use libgetopt-long-descriptive-perl:
1.20220520 2022-05-20 UTC
+ Change default algorithm in dkimsign.pl to sha-256
+ Use Getopt::Long::Descriptive in scripts for better command help
That change have been there since Lunar, apparently.
The package libgetopt-long-descriptive-perl is required in Ubuntu main as soon as possible, since libmail-dkim-perl depends on it and libmail-dkim-perl is already in main.
[Security]
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libgetopt-long-descriptive-perl
- (0) https://ubuntu.com/security/cves?q=&package=libgetopt-long-descriptive-perl
- (0) https://security-tracker.debian.org/tracker/source-package/libgetopt-long-descriptive-perl
No `suid` or `sgid` binaries.
No executables in `/sbin` and `/usr/sbin`.
Package does not install services, timers or recurring jobs.
Package does not open privileged ports (ports < 1024).
Package does not expose any external endpoints.
Package does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...);
It's a Perl module that handles command-line arguments with usage text
Getopt::Long::Descriptive is a convenience wrapper for Getopt::Long, which
allows one to easily define options in the same familiar way, while also
supporting custom descriptions for program usage output.
[Quality assurance - function/usage]
The package works well right after install
[Quality assurance - maintenance]
The package is maintained well in Debian/Ubuntu and does
not have too many, long-term & critical, open bugs:
- Ubuntu (1) https://bugs.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/+bug
- Debian (0) https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libgetopt-long-descriptive-perl
- Upstream's bug tracker (16) https://github.com/rjbs/Getopt-Long-Descriptive/issues
+ Upstream's repo last activity: https://github.com/rjbs/Getopt-Long-Descriptive
- last commit: in main, Nov 21, 2023
- Issues without answer: 6
- Updated issue/PR: Nov 21, 2023
- last fixed/closed/merged issue: Nov 21, 2023
- last merged PR: Mar 13, 2021
The package hasn't important/old open bugs on upstream.
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: https://launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/0.111-1/+build/25462675/+files/buildlog_ubuntu-lunar-amd64.libgetopt-long-descriptive-perl_0.111-1_BUILDING.txt.gz
dh_auto_test
make -j4 test TEST_VERBOSE=1
make[1]: Entering directory '/<<PKGBUILDDIR>>'
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.test_harness(1, 'blib/lib', 'blib/arch')" t/*.t
The package runs an autopkgtest (via autodep8 using 'Testsuite: autopkgtest-pkg-perl' in d/control file - https://git.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/tree/debian/control#n6 -),
that runs essentialy the above build-time test suite. It is currently passing on
this list of architectures (amd64, arm64, armhf, ppc64el, s390x) except i386: https://autopkgtest.ubuntu.com/packages/l/libgetopt-long-descriptive-perl
The package does have failing autopkgtests tests right now, but since
they always failed they are handled as "ignored failure", this is
because the test depends on pkg-perl-autopkgtest package that is not
build for i386 since focal.
[Quality assurance - packaging]
debian/watch is present and works for latest version, but it failed for --download-current-version.
debian/control defines a correct Maintainer field : Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org> ( https://git.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/tree/debian/control#n2)
This package does not yield massive lintian Warnings, Errors
- recent build log of the package https://launchpadlibrarian.net/644863847/buildlog_ubuntu-lunar-amd64.libgetopt-long-descriptive-perl_0.111-1_BUILDING.txt.gz
- full output from `lintian --pedantic` :
#source
❯ lintian -EvIL +pedantic --show-overrides
W: libgetopt-long-descriptive-perl: changelog-distribution-does-not-match-changes-file unstable != noble [usr/share/doc/libgetopt-long-descriptive-perl/changelog.Debian.gz:1]
W: libgetopt-long-descriptive-perl changes: distribution-and-changes-mismatch noble unstable
#binary
❯ lintian -EvIL +pedantic --show-overrides ../libgetopt-long-descriptive-perl_0.111-1.dsc
X: libgetopt-long-descriptive-perl source: debian-watch-does-not-check-openpgp-signature [debian/watch]
This package does not rely on obsolete or about to be demoted packages.
This package has no python2 or GTK2 dependencies.
The package will not be installed by default.
Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/tree/debian/rules
[UI standards]
Application is not end-user facing (does not need translation).
[Dependencies]
There are further dependencies not yet in main. Listing then:
libgetopt-long-descriptive-perl depends on:
- libparams-validate-perl (depends, universe)
MIR bug: https://bugs.launchpad.net/ubuntu/+source/libparams-validate-perl/+bug/2046181
+ libscalar-list-utils-perl (depends, universe)
However, the modules provided by libscalar-list-utils-perl are provided by the libperl5.36 package too,
although there is no Break/Replace/Provides in the d/control of perl about this.
[Standards compliance]
This package correctly follows FHS and Debian Policy (4.6.2)
[Maintenance/Owner]
Owning Team will be Ubuntu Server Team.
Team is not yet, but will subscribe to the package before promotion.
This does not use static builds.
This does not use vendored code.
This package is not rust based.
A previous version of the package was successfully built during the most recent test rebuild : https://launchpad.net/ubuntu/+archive/test-rebuild-20230830-mantic/+build/26597663/+files/buildlog_ubuntu-mantic-amd64.libgetopt-long-descriptive-perl_0.111-1_BUILDING.txt.gz
[Background information]
The Package description explains the package well.
Upstream Name is CryptX .
Link to upstream project https://metacpan.org/dist/CryptX
This has been in the archive since at least 2013 (Karmic, 0.074-1).
It was on main before (https://bugs.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/+bug/1492055), but was demoted to universe in Jammy. |
|
| 2024-01-11 16:01:23 |
Jean-Baptiste Lallement |
description |
/!\ IN PROGRESS /!\
https://bugs.launchpad.net/ubuntu/+source/authd/+bug/2048781
[MIR] authd
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS Noble Numbat 24.04.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd.
It also installs a PAM module and an NSS module.
Communication between authd and its brokers is done over DBus
This requires a security review.
TODO: Document open ports and systemd confinement
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: (add details and links/examples about things like dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
[Quality assurance - function/usage]
The package needs post install configuration and reading of documentation. There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
[Quality assurance - maintenance]
The Ubuntu Desktop team maintains this package. It doesn’t have any long-term and critical, open bugs.
https://github.com/ubuntu/authd/issues
https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
The testsuite runs at build time. The branch coverage is 89%.
https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
https://app.codecov.io/gh/ubuntu/authd
The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
Upstream CI also includes code sanity checks.
[Quality assurance - packaging]
There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
This package does not yield massive lintian Warnings, Errors
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
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
The package will not be installed by default
Packaging and build is easy: https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
[Dependencies]
No further depends or recommends dependencies that are not yet in main
[Standards compliance]
This package correctly follows FHS
This package violates Debian Policy. It vendorizes various Go and Rust libraries.
[Maintenance/Owner]
- The owning team will be ubuntu-desktop and I have their acknowledgement for
- The future owning team is not yet subscribed, but will subscribe to the package before promotion
- The team ubuntu-desktop 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).
- The team ubuntu-desktop is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies
[Background information]
The Package description explains the package well
Upstream Name is authd
Link to upstream project https://github.com/ubuntu/authd
Example
[Rationale]
The package libgetopt-long-descriptive-perl is required in Ubuntu main for libmail-dkim-perl
The package libgetopt-long-descriptive-perl will not generally be useful for a large part of
our user base, but is important/helpful still because is required as runtime dependency by libmail-dkim-perl
that is already in main.
libmail-dkim-perl it's a perl module to cryptographically identify the sender of email (implementing the new Domain Keys Identified Mail (DKIM)), used by spamassassin
and amavisd-new. The following change added to libmail-dkim-perl makes it necessary to use libgetopt-long-descriptive-perl:
1.20220520 2022-05-20 UTC
+ Change default algorithm in dkimsign.pl to sha-256
+ Use Getopt::Long::Descriptive in scripts for better command help
That change have been there since Lunar, apparently.
The package libgetopt-long-descriptive-perl is required in Ubuntu main as soon as possible, since libmail-dkim-perl depends on it and libmail-dkim-perl is already in main.
[Security]
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libgetopt-long-descriptive-perl
- (0) https://ubuntu.com/security/cves?q=&package=libgetopt-long-descriptive-perl
- (0) https://security-tracker.debian.org/tracker/source-package/libgetopt-long-descriptive-perl
No `suid` or `sgid` binaries.
No executables in `/sbin` and `/usr/sbin`.
Package does not install services, timers or recurring jobs.
Package does not open privileged ports (ports < 1024).
Package does not expose any external endpoints.
Package does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...);
It's a Perl module that handles command-line arguments with usage text
Getopt::Long::Descriptive is a convenience wrapper for Getopt::Long, which
allows one to easily define options in the same familiar way, while also
supporting custom descriptions for program usage output.
[Quality assurance - function/usage]
The package works well right after install
[Quality assurance - maintenance]
The package is maintained well in Debian/Ubuntu and does
not have too many, long-term & critical, open bugs:
- Ubuntu (1) https://bugs.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/+bug
- Debian (0) https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libgetopt-long-descriptive-perl
- Upstream's bug tracker (16) https://github.com/rjbs/Getopt-Long-Descriptive/issues
+ Upstream's repo last activity: https://github.com/rjbs/Getopt-Long-Descriptive
- last commit: in main, Nov 21, 2023
- Issues without answer: 6
- Updated issue/PR: Nov 21, 2023
- last fixed/closed/merged issue: Nov 21, 2023
- last merged PR: Mar 13, 2021
The package hasn't important/old open bugs on upstream.
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: https://launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/0.111-1/+build/25462675/+files/buildlog_ubuntu-lunar-amd64.libgetopt-long-descriptive-perl_0.111-1_BUILDING.txt.gz
dh_auto_test
make -j4 test TEST_VERBOSE=1
make[1]: Entering directory '/<<PKGBUILDDIR>>'
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.test_harness(1, 'blib/lib', 'blib/arch')" t/*.t
The package runs an autopkgtest (via autodep8 using 'Testsuite: autopkgtest-pkg-perl' in d/control file - https://git.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/tree/debian/control#n6 -),
that runs essentialy the above build-time test suite. It is currently passing on
this list of architectures (amd64, arm64, armhf, ppc64el, s390x) except i386: https://autopkgtest.ubuntu.com/packages/l/libgetopt-long-descriptive-perl
The package does have failing autopkgtests tests right now, but since
they always failed they are handled as "ignored failure", this is
because the test depends on pkg-perl-autopkgtest package that is not
build for i386 since focal.
[Quality assurance - packaging]
debian/watch is present and works for latest version, but it failed for --download-current-version.
debian/control defines a correct Maintainer field : Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org> ( https://git.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/tree/debian/control#n2)
This package does not yield massive lintian Warnings, Errors
- recent build log of the package https://launchpadlibrarian.net/644863847/buildlog_ubuntu-lunar-amd64.libgetopt-long-descriptive-perl_0.111-1_BUILDING.txt.gz
- full output from `lintian --pedantic` :
#source
❯ lintian -EvIL +pedantic --show-overrides
W: libgetopt-long-descriptive-perl: changelog-distribution-does-not-match-changes-file unstable != noble [usr/share/doc/libgetopt-long-descriptive-perl/changelog.Debian.gz:1]
W: libgetopt-long-descriptive-perl changes: distribution-and-changes-mismatch noble unstable
#binary
❯ lintian -EvIL +pedantic --show-overrides ../libgetopt-long-descriptive-perl_0.111-1.dsc
X: libgetopt-long-descriptive-perl source: debian-watch-does-not-check-openpgp-signature [debian/watch]
This package does not rely on obsolete or about to be demoted packages.
This package has no python2 or GTK2 dependencies.
The package will not be installed by default.
Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/tree/debian/rules
[UI standards]
Application is not end-user facing (does not need translation).
[Dependencies]
There are further dependencies not yet in main. Listing then:
libgetopt-long-descriptive-perl depends on:
- libparams-validate-perl (depends, universe)
MIR bug: https://bugs.launchpad.net/ubuntu/+source/libparams-validate-perl/+bug/2046181
+ libscalar-list-utils-perl (depends, universe)
However, the modules provided by libscalar-list-utils-perl are provided by the libperl5.36 package too,
although there is no Break/Replace/Provides in the d/control of perl about this.
[Standards compliance]
This package correctly follows FHS and Debian Policy (4.6.2)
[Maintenance/Owner]
Owning Team will be Ubuntu Server Team.
Team is not yet, but will subscribe to the package before promotion.
This does not use static builds.
This does not use vendored code.
This package is not rust based.
A previous version of the package was successfully built during the most recent test rebuild : https://launchpad.net/ubuntu/+archive/test-rebuild-20230830-mantic/+build/26597663/+files/buildlog_ubuntu-mantic-amd64.libgetopt-long-descriptive-perl_0.111-1_BUILDING.txt.gz
[Background information]
The Package description explains the package well.
Upstream Name is CryptX .
Link to upstream project https://metacpan.org/dist/CryptX
This has been in the archive since at least 2013 (Karmic, 0.074-1).
It was on main before (https://bugs.launchpad.net/ubuntu/+source/libgetopt-long-descriptive-perl/+bug/1492055), but was demoted to universe in Jammy. |
/!\ IN PROGRESS /!\
https://bugs.launchpad.net/ubuntu/+source/authd/+bug/2048781
[MIR] authd
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS Noble Numbat 24.04.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd.
It also installs a PAM module and an NSS module.
Communication between authd and its brokers is done over DBus
This requires a security review.
TODO: Document open ports and systemd confinement
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: (add details and links/examples about things like dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
[Quality assurance - function/usage]
The package needs post install configuration and reading of documentation. There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
[Quality assurance - maintenance]
The Ubuntu Desktop team maintains this package. It doesn’t have any long-term and critical, open bugs.
https://github.com/ubuntu/authd/issues
https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
The testsuite runs at build time. The branch coverage is 89%.
https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
https://app.codecov.io/gh/ubuntu/authd
The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
Upstream CI also includes code sanity checks.
[Quality assurance - packaging]
There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
This package does not yield massive lintian Warnings, Errors
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
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
The package will not be installed by default
Packaging and build is easy: https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
[Dependencies]
No further depends or recommends dependencies that are not yet in main
[Standards compliance]
This package correctly follows FHS
This package violates Debian Policy. It vendorizes various Go and Rust libraries.
[Maintenance/Owner]
- The owning team will be ubuntu-desktop and I have their acknowledgement for
- The future owning team is not yet subscribed, but will subscribe to the package before promotion
- The team ubuntu-desktop 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).
- The team ubuntu-desktop is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies
[Background information]
The Package description explains the package well
Upstream Name is authd
Link to upstream project https://github.com/ubuntu/authd |
|
| 2024-01-11 16:01:35 |
Jean-Baptiste Lallement |
description |
/!\ IN PROGRESS /!\
https://bugs.launchpad.net/ubuntu/+source/authd/+bug/2048781
[MIR] authd
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS Noble Numbat 24.04.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd.
It also installs a PAM module and an NSS module.
Communication between authd and its brokers is done over DBus
This requires a security review.
TODO: Document open ports and systemd confinement
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: (add details and links/examples about things like dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
[Quality assurance - function/usage]
The package needs post install configuration and reading of documentation. There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
[Quality assurance - maintenance]
The Ubuntu Desktop team maintains this package. It doesn’t have any long-term and critical, open bugs.
https://github.com/ubuntu/authd/issues
https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
The testsuite runs at build time. The branch coverage is 89%.
https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
https://app.codecov.io/gh/ubuntu/authd
The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
Upstream CI also includes code sanity checks.
[Quality assurance - packaging]
There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
This package does not yield massive lintian Warnings, Errors
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
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
The package will not be installed by default
Packaging and build is easy: https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
[Dependencies]
No further depends or recommends dependencies that are not yet in main
[Standards compliance]
This package correctly follows FHS
This package violates Debian Policy. It vendorizes various Go and Rust libraries.
[Maintenance/Owner]
- The owning team will be ubuntu-desktop and I have their acknowledgement for
- The future owning team is not yet subscribed, but will subscribe to the package before promotion
- The team ubuntu-desktop 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).
- The team ubuntu-desktop is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies
[Background information]
The Package description explains the package well
Upstream Name is authd
Link to upstream project https://github.com/ubuntu/authd |
/!\ IN PROGRESS /!\
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS Noble Numbat 24.04.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd.
It also installs a PAM module and an NSS module.
Communication between authd and its brokers is done over DBus
This requires a security review.
TODO: Document open ports and systemd confinement
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: (add details and links/examples about things like dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
[Quality assurance - function/usage]
The package needs post install configuration and reading of documentation. There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
[Quality assurance - maintenance]
The Ubuntu Desktop team maintains this package. It doesn’t have any long-term and critical, open bugs.
https://github.com/ubuntu/authd/issues
https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
The testsuite runs at build time. The branch coverage is 89%.
https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
https://app.codecov.io/gh/ubuntu/authd
The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
Upstream CI also includes code sanity checks.
[Quality assurance - packaging]
There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
This package does not yield massive lintian Warnings, Errors
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
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
The package will not be installed by default
Packaging and build is easy: https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
[Dependencies]
No further depends or recommends dependencies that are not yet in main
[Standards compliance]
This package correctly follows FHS
This package violates Debian Policy. It vendorizes various Go and Rust libraries.
[Maintenance/Owner]
- The owning team will be ubuntu-desktop and I have their acknowledgement for
- The future owning team is not yet subscribed, but will subscribe to the package before promotion
- The team ubuntu-desktop 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).
- The team ubuntu-desktop is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies
[Background information]
The Package description explains the package well
Upstream Name is authd
Link to upstream project https://github.com/ubuntu/authd |
|
| 2024-01-12 11:28:40 |
Jean-Baptiste Lallement |
description |
/!\ IN PROGRESS /!\
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS Noble Numbat 24.04.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd.
It also installs a PAM module and an NSS module.
Communication between authd and its brokers is done over DBus
This requires a security review.
TODO: Document open ports and systemd confinement
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing the following features: (add details and links/examples about things like dropping permissions, using temporary environments, restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
[Quality assurance - function/usage]
The package needs post install configuration and reading of documentation. There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
[Quality assurance - maintenance]
The Ubuntu Desktop team maintains this package. It doesn’t have any long-term and critical, open bugs.
https://github.com/ubuntu/authd/issues
https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
The testsuite runs at build time. The branch coverage is 89%.
https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
https://app.codecov.io/gh/ubuntu/authd
The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
Upstream CI also includes code sanity checks.
[Quality assurance - packaging]
There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
This package does not yield massive lintian Warnings, Errors
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
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
The package will not be installed by default
Packaging and build is easy: https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
[Dependencies]
No further depends or recommends dependencies that are not yet in main
[Standards compliance]
This package correctly follows FHS
This package violates Debian Policy. It vendorizes various Go and Rust libraries.
[Maintenance/Owner]
- The owning team will be ubuntu-desktop and I have their acknowledgement for
- The future owning team is not yet subscribed, but will subscribe to the package before promotion
- The team ubuntu-desktop 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).
- The team ubuntu-desktop is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies
[Background information]
The Package description explains the package well
Upstream Name is authd
Link to upstream project https://github.com/ubuntu/authd |
[MIR] authd
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS 24.04 LTS.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
no `suid` or `sgid` binaries
Package does install a dpkg trigger on /usr/lib/linux/efi
Packages does not open privileged ports (ports < 1024)
Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
It installs a PAM module
It installs an NSS module.
Communication between authd and its brokers is done over DBus
Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
This requires a security review.
[Quality assurance - function/usage]
The package needs post install configuration and reading of documentation. There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs.
https://github.com/ubuntu/authd/issues
https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
The testsuite runs at build time. The branch coverage is 89%.
https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
https://app.codecov.io/gh/ubuntu/authd
The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
This package does not yield massive lintian Warnings, Errors
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
Lintian overrides package-does-not-install-examples in vendored Rust modules.
This package does not rely on obsolete or about to be demoted packages.
This package has no python2 or GTK2 dependencies
The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
Packaging and build is easy: https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
Most of the translated strings will come from the different brokers (separate projects)
The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
This package correctly follows FHS
This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
The owning team will be desktop-packages and I have their acknowledgement for that commitment
The team desktop-packages is subscribed.
The team desktop-packages 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).
The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
The Package description explains the package well.
Upstream Name is authd.
Link to upstream project https://github.com/ubuntu/authd |
|
| 2024-01-12 11:47:04 |
Jean-Baptiste Lallement |
description |
[MIR] authd
[Availability]
The package authd is already in Ubuntu universe.
The package authd build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
The package authd is required to be in main for enabling cloud authentication at provisioning time.
The package authd will generally be useful for corporate users.
No package in main or universe currently offers cloud authentication capabilities.
The target release is the next LTS 24.04 LTS.
[Security]
This is a new software developed and maintained by Canonical. It has no security history.
No CVEs/security issues in this software in the past:
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
(There are false positives. authd is an authentication daemon for Junos and VMWare)
no `suid` or `sgid` binaries
Package does install a dpkg trigger on /usr/lib/linux/efi
Packages does not open privileged ports (ports < 1024)
Packages does not contain extensions to security-sensitive software
It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
It installs a PAM module
It installs an NSS module.
Communication between authd and its brokers is done over DBus
Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
This requires a security review.
[Quality assurance - function/usage]
The package needs post install configuration and reading of documentation. There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs.
https://github.com/ubuntu/authd/issues
https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
The testsuite runs at build time. The branch coverage is 89%.
https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
https://app.codecov.io/gh/ubuntu/authd
The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
This package does not yield massive lintian Warnings, Errors
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
Lintian overrides package-does-not-install-examples in vendored Rust modules.
This package does not rely on obsolete or about to be demoted packages.
This package has no python2 or GTK2 dependencies
The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
Packaging and build is easy: https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
Most of the translated strings will come from the different brokers (separate projects)
The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
This package correctly follows FHS
This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
The owning team will be desktop-packages and I have their acknowledgement for that commitment
The team desktop-packages is subscribed.
The team desktop-packages 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).
The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
The Package description explains the package well.
Upstream Name is authd.
Link to upstream project https://github.com/ubuntu/authd |
[Availability]
- The package authd is already in Ubuntu universe.
- The package authd build for the architectures it is designed to work on.
- It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
- Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
- Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
- The package authd is required to be in main for enabling cloud authentication at provisioning time.
- The package authd will generally be useful for corporate users.
- No package in main or universe currently offers cloud authentication capabilities.
- The target release is the next LTS 24.04 LTS.
[Security]
- This is a new software developed and maintained by Canonical. It has no security history.
- No CVEs/security issues in this software in the past (There are false positives. authd is an authentication daemon for Junos and VMWare):
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
- It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
- It installs a PAM module
- It installs an NSS module.
- Communication between authd and its brokers is done over DBus
- Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
- /!\ This requires a security review.
[Quality assurance - function/usage]
- The package needs post install configuration and reading of documentation. - There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
- Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
- The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs:
- https://github.com/ubuntu/authd/issues
- https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
- There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
- The testsuite runs at build time. The branch coverage is 89%:
- https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
- https://app.codecov.io/gh/ubuntu/authd
- The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
- https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
- Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
- Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
- There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
- This package does not yield massive lintian Warnings, Errors
```
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
```
- Lintian overrides package-does-not-install-examples in vendored Rust modules.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
- Packaging and build is easy:
- https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
- Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
- Most of the translated strings will come from the different brokers (separate projects)
- The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
- This package correctly follows FHS
- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The team desktop-packages is subscribed.
- The team desktop-packages 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).
- The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
- The Package description explains the package well.
- Upstream Name is authd.
- Link to upstream project https://github.com/ubuntu/authd |
|
| 2024-01-12 16:36:00 |
Jean-Baptiste Lallement |
description |
[Availability]
- The package authd is already in Ubuntu universe.
- The package authd build for the architectures it is designed to work on.
- It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
- Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
- Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
- The package authd is required to be in main for enabling cloud authentication at provisioning time.
- The package authd will generally be useful for corporate users.
- No package in main or universe currently offers cloud authentication capabilities.
- The target release is the next LTS 24.04 LTS.
[Security]
- This is a new software developed and maintained by Canonical. It has no security history.
- No CVEs/security issues in this software in the past (There are false positives. authd is an authentication daemon for Junos and VMWare):
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
- It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
- It installs a PAM module
- It installs an NSS module.
- Communication between authd and its brokers is done over DBus
- Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
- /!\ This requires a security review.
[Quality assurance - function/usage]
- The package needs post install configuration and reading of documentation. - There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
- Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
- The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs:
- https://github.com/ubuntu/authd/issues
- https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
- There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
- The testsuite runs at build time. The branch coverage is 89%:
- https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
- https://app.codecov.io/gh/ubuntu/authd
- The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
- https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
- Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
- Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
- There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
- This package does not yield massive lintian Warnings, Errors
```
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
Full output from `lintian --pedantic`:
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd source: package-does-not-install-examples [vendor_rust/addr2line/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/async-stream/examples/]
P: authd source: package-does-not-install-examples [vendor_rust/autocfg/examples/]
P: authd source: package-does-not-install-examples ... use "--tag-display-limit 0" to see all (or pipe to a file/program)
P: authd source: redundant-control-relation (in source paragraph) Build-Depends libpam0g-dev, libpam0g-dev [debian/control:5]
P: authd source: silent-on-rules-requiring-root [debian/control]
P: authd: spelling-error-in-copyright Unknwon Unknown
```
- Lintian overrides package-does-not-install-examples in vendored Rust modules.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
- Packaging and build is easy:
- https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
- Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
- Most of the translated strings will come from the different brokers (separate projects)
- The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
- This package correctly follows FHS
- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The team desktop-packages is subscribed.
- The team desktop-packages 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).
- The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
- The Package description explains the package well.
- Upstream Name is authd.
- Link to upstream project https://github.com/ubuntu/authd |
[Availability]
- The package authd is already in Ubuntu universe.
- The package authd build for the architectures it is designed to work on.
- It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
- Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
- Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
- The package authd is required to be in main for enabling cloud authentication at provisioning time.
- The package authd will generally be useful for corporate users.
- No package in main or universe currently offers cloud authentication capabilities.
- The target release is the next LTS 24.04 LTS.
[Security]
- This is a new software developed and maintained by Canonical. It has no security history.
- No CVEs/security issues in this software in the past (There are false positives. authd is an authentication daemon for Junos and VMWare):
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
- It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
- It installs a PAM module
- It installs an NSS module.
- Communication between authd and its brokers is done over DBus
- Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
- /!\ This requires a security review.
[Quality assurance - function/usage]
- The package needs post install configuration and reading of documentation. - There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
- Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
- The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs:
- https://github.com/ubuntu/authd/issues
- https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
- There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
- The testsuite runs at build time. The branch coverage is 89%:
- https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
- https://app.codecov.io/gh/ubuntu/authd
- The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
- https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
- Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
- Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
- There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
- This package does not yield massive lintian Warnings, Errors
```
$ lintian --pedantic --tag-display-limit 0
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
```
- Lintian overrides package-does-not-install-examples in vendored Rust modules.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
- Packaging and build is easy:
- https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
- Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
- Most of the translated strings will come from the different brokers (separate projects)
- The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
- This package correctly follows FHS
- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The team desktop-packages is subscribed.
- The team desktop-packages 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).
- The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
- The Package description explains the package well.
- Upstream Name is authd.
- Link to upstream project https://github.com/ubuntu/authd |
|
| 2024-01-15 08:42:22 |
Jean-Baptiste Lallement |
description |
[Availability]
- The package authd is already in Ubuntu universe.
- The package authd build for the architectures it is designed to work on.
- It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
- Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
- Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
- The package authd is required to be in main for enabling cloud authentication at provisioning time.
- The package authd will generally be useful for corporate users.
- No package in main or universe currently offers cloud authentication capabilities.
- The target release is the next LTS 24.04 LTS.
[Security]
- This is a new software developed and maintained by Canonical. It has no security history.
- No CVEs/security issues in this software in the past (There are false positives. authd is an authentication daemon for Junos and VMWare):
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
- It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
- It installs a PAM module
- It installs an NSS module.
- Communication between authd and its brokers is done over DBus
- Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
- /!\ This requires a security review.
[Quality assurance - function/usage]
- The package needs post install configuration and reading of documentation. - There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
- Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
- The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs:
- https://github.com/ubuntu/authd/issues
- https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
- There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
- The testsuite runs at build time. The branch coverage is 89%:
- https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
- https://app.codecov.io/gh/ubuntu/authd
- The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
- https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
- Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
- Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
- There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
- This package does not yield massive lintian Warnings, Errors
```
$ lintian --pedantic --tag-display-limit 0
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
```
- Lintian overrides package-does-not-install-examples in vendored Rust modules.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
- Packaging and build is easy:
- https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
- Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
- Most of the translated strings will come from the different brokers (separate projects)
- The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
- This package correctly follows FHS
- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The team desktop-packages is subscribed.
- The team desktop-packages 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).
- The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
- The Package description explains the package well.
- Upstream Name is authd.
- Link to upstream project https://github.com/ubuntu/authd |
[Availability]
- The package authd is already in Ubuntu universe.
- The package authd build for the architectures it is designed to work on.
- It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
- Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
- Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
- The package authd is required to be in main for enabling cloud authentication at provisioning time.
- The package authd will generally be useful for corporate users.
- No package in main or universe currently offers cloud authentication capabilities.
- The target release is the next LTS 24.04 LTS.
[Security]
- This is a new software developed and maintained by Canonical. It has no security history.
- No CVEs/security issues in this software in the past (There are false positives. authd is an authentication daemon for Junos and VMWare):
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
- It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
- It installs a PAM module
- It installs an NSS module.
- Communication between authd and its brokers is done over DBus
- Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
- /!\ This requires a security review.
[Quality assurance - function/usage]
- The package needs post install configuration and reading of documentation. - There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
- Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
- The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs:
- https://github.com/ubuntu/authd/issues
- https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
- There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
- The testsuite runs at build time. The branch coverage is 89%:
- https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
- https://app.codecov.io/gh/ubuntu/authd
- The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
- https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
- Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
- Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
- There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
- This package does not yield massive lintian Warnings, Errors
```
$ lintian --pedantic --tag-display-limit 0
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd: spelling-error-in-copyright Unknwon Unknown
```
- spelling-error-in-copyright is a false positive. Unknwon is the actual name of the author.
- Lintian overrides package-does-not-install-examples in vendored Rust modules.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
- Packaging and build is easy:
- https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
- Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
- Most of the translated strings will come from the different brokers (separate projects)
- The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
- This package correctly follows FHS
- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The team desktop-packages is subscribed.
- The team desktop-packages 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).
- The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
- The Package description explains the package well.
- Upstream Name is authd.
- Link to upstream project https://github.com/ubuntu/authd |
|
| 2024-01-29 19:44:06 |
Jean-Baptiste Lallement |
bug |
|
|
added subscriber MIR approval team |
| 2024-01-30 09:41:01 |
Jean-Baptiste Lallement |
description |
[Availability]
- The package authd is already in Ubuntu universe.
- The package authd build for the architectures it is designed to work on.
- It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
- Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
- Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
- The package authd is required to be in main for enabling cloud authentication at provisioning time.
- The package authd will generally be useful for corporate users.
- No package in main or universe currently offers cloud authentication capabilities.
- The target release is the next LTS 24.04 LTS.
[Security]
- This is a new software developed and maintained by Canonical. It has no security history.
- No CVEs/security issues in this software in the past (There are false positives. authd is an authentication daemon for Junos and VMWare):
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
- It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
- It installs a PAM module
- It installs an NSS module.
- Communication between authd and its brokers is done over DBus
- Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
- /!\ This requires a security review.
[Quality assurance - function/usage]
- The package needs post install configuration and reading of documentation. - There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
- Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
- The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs:
- https://github.com/ubuntu/authd/issues
- https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
- There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
- The testsuite runs at build time. The branch coverage is 89%:
- https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
- https://app.codecov.io/gh/ubuntu/authd
- The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
- https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
- Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
- Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
- There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
- This package does not yield massive lintian Warnings, Errors
```
$ lintian --pedantic --tag-display-limit 0
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd: spelling-error-in-copyright Unknwon Unknown
```
- spelling-error-in-copyright is a false positive. Unknwon is the actual name of the author.
- Lintian overrides package-does-not-install-examples in vendored Rust modules.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
- Packaging and build is easy:
- https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
- Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
- Most of the translated strings will come from the different brokers (separate projects)
- The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
- This package correctly follows FHS
- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The team desktop-packages is subscribed.
- The team desktop-packages 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).
- The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
- The Package description explains the package well.
- Upstream Name is authd.
- Link to upstream project https://github.com/ubuntu/authd |
[Availability]
- The package authd is already in Ubuntu universe.
- The package authd build for the architectures it is designed to work on.
- It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
- Link to package https://launchpad.net/ubuntu/+source/authd
[Rationale]
- Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
- The package authd is required to be in main for enabling cloud authentication at provisioning time.
- The package authd will generally be useful for corporate users.
- No package in main or universe currently offers cloud authentication capabilities.
- The target release is the next LTS 24.04 LTS.
[Security]
- This is a new software developed and maintained by Canonical. It has no security history.
- No CVEs/security issues in this software in the past (There are false positives. authd is an authentication daemon for Junos and VMWare):
- (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
- (0) https://ubuntu.com/security/cves?q=&package=authd
- (0) https://security-tracker.debian.org/tracker/source-package/authd
- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
- It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
- It installs a PAM module
- It installs an NSS module.
- Communication between authd and its brokers is done over DBus
- Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.
- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.
- /!\ This requires a security review.
[Quality assurance - function/usage]
- The package needs post install configuration and reading of documentation. - There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
- Once installed without additional configuration, PAM requests are ignored by authd.
[Quality assurance - maintenance]
- The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs:
- https://github.com/ubuntu/authd/issues
- https://bugs.launchpad.net/ubuntu/+source/authd
[Quality assurance - testing]
- There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
- The testsuite runs at build time. The branch coverage is 89%:
- https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
- https://app.codecov.io/gh/ubuntu/authd
- The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
- https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
- arm64 tests are flaky due to a Rust regression that makes the build very slow and timing out.
- Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
- Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).
[Quality assurance - packaging]
- There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
- This package does not yield massive lintian Warnings, Errors
```
$ lintian --pedantic --tag-display-limit 0
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd: spelling-error-in-copyright Unknwon Unknown
```
- spelling-error-in-copyright is a false positive. Unknwon is the actual name of the author.
- Lintian overrides package-does-not-install-examples in vendored Rust modules.
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.
- Packaging and build is easy:
- https://github.com/ubuntu/authd/blob/main/debian/rules
[UI standards]
- Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:
pam/userselection.go: u.Prompt = "Username: " // TODO: i18n
- Most of the translated strings will come from the different brokers (separate projects)
- The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main.
[Standards compliance]
- This package correctly follows FHS
- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.
[Maintenance/Owner]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The team desktop-packages is subscribed.
- The team desktop-packages 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).
- The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies.
[Background information]
- The Package description explains the package well.
- Upstream Name is authd.
- Link to upstream project https://github.com/ubuntu/authd |
|
| 2024-01-30 15:36:29 |
Christian Ehrhardt |
authd (Ubuntu): assignee |
|
Ioanna Alifieraki (joalif) |
|
| 2024-01-30 19:26:51 |
Mark Esler |
bug watch added |
|
https://github.com/canonical/ubuntu-mir/issues/35 |
|
| 2024-02-22 00:35:07 |
Mark Esler |
tags |
|
sec-3874 |
|
| 2024-02-22 02:49:47 |
Mark Esler |
bug watch added |
|
https://github.com/rust-lang/cargo/issues/11929 |
|
| 2024-02-22 16:32:18 |
Ioanna Alifieraki |
authd (Ubuntu): assignee |
Ioanna Alifieraki (joalif) |
|
|
| 2024-02-22 16:32:22 |
Ioanna Alifieraki |
authd (Ubuntu): status |
New |
Incomplete |
|
| 2024-02-22 16:33:02 |
Ioanna Alifieraki |
authd (Ubuntu): assignee |
|
Ubuntu Security Team (ubuntu-security) |
|
| 2024-02-22 17:07:50 |
Marco Trevisan (Treviño) |
bug |
|
|
added subscriber Marco Trevisan (Treviño) |
| 2024-02-27 15:59:16 |
Lukas Märdian |
authd (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2024-02-27 16:01:51 |
Lukas Märdian |
authd (Ubuntu): status |
Confirmed |
Incomplete |
|
| 2024-03-27 21:06:13 |
Mark Esler |
authd (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2024-03-27 21:06:42 |
Mark Esler |
bug |
|
|
added subscriber Sudhakar Verma |
| 2024-04-02 10:01:06 |
Lukas Märdian |
authd (Ubuntu): status |
Incomplete |
In Progress |
|
| 2024-04-22 07:08:10 |
Didier Roche-Tolomelli |
authd (Ubuntu): status |
In Progress |
Won't Fix |
|
