| 2023-02-28 14:46:50 |
Lukas Märdian |
bug |
|
|
added bug |
| 2023-02-28 14:47:03 |
Lukas Märdian |
bug |
|
|
added subscriber MIR approval team |
| 2023-02-28 16:20:20 |
Lukas Märdian |
tags |
lunar rls-ll-incoming |
fr-2983 lunar rls-ll-incoming |
|
| 2023-03-02 16:13:08 |
Julian Andres Klode |
tags |
fr-2983 lunar rls-ll-incoming |
fr-2983 lunar |
|
| 2023-03-02 16:20:29 |
Lukas Märdian |
inetutils (Ubuntu): assignee |
|
Dominik Viererbe (dviererbe) |
|
| 2023-03-09 10:14:33 |
Dominik Viererbe |
description |
TBD by foundations
Seeded in lunar.standard as a replacement for netkit-telnet:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?h=lunar&id=349619dc49fdd0695c0bd7f9ae72f535809c2657 |
WORK IN PROGRESS by foundations
due to https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2009814
Dear reviewers, this is my first MIR. I answered all questions very
carefully, but if something feels wrong, please look extra closely or
ask me (~dviererbe) to reinvestigate a given answer.
[Availability]
The package inetutils-telnet is already in Ubuntu universe.
The package inetutils-telnet build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
Link to package [[https://launchpad.net/ubuntu/+source/inetutils|inetutils]]
[Rationale]
RULE: There must be a certain level of demand for the package
The package inetutils-telnet is required in Ubuntu main:
- The package inetutils-telnet will not generally be useful for a large part of
our user base, but is important/helpful still because it is commonly used for
network diagnostics, like protocol testing of SMTP services.
- Additionally telnet is still used for legacy industrial and scientific
equipment.
- Package inetutils-telnet covers similar use cases as netkit-telnet, but
is better because netkit-telnet has been dropped altogether from Debian,
thereby we want to replace it.
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 priorization 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
- The package inetutils-telnet is required in Ubuntu main no later than
April 13th 2023 due to the Ubuntu 23.04 Lunar Lobster release date.
[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>
- Had security issues in the past:
- CVE-2019-0053 (needs triage)
- https://ubuntu.com/security/CVE-2019-0053
- most likely not relevant:
- CVE-2022-39028 (only related to telnetd)
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-39028
- https://ubuntu.com/security/CVE-2022-39028
- CVE-2020-10188 (related to netcat):
- https://www.openwall.com/lists/oss-security/2018/12/13/2
- https://www.openwall.com/lists/oss-security/2018/12/14/8
- CVE-2011-4862 (related to telnetd; not sure if relevant anymore)
- https://ubuntu.com/security/CVE-2011-4862
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862
- security issues were patched or reached end of life
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...)
- See list of files for:
- amd64: https://packages.ubuntu.com/lunar/amd64/inetutils-telnet/filelist
- arm64: https://packages.ubuntu.com/lunar/arm64/inetutils-telnet/filelist
- armhf: https://packages.ubuntu.com/lunar/armhf/inetutils-telnet/filelist
- i386: https://packages.ubuntu.com/lunar/i386/inetutils-telnet/filelist
- ppc64el: https://packages.ubuntu.com/lunar/ppc64el/inetutils-telnet/filelist
- s390x: https://packages.ubuntu.com/lunar/s390x/inetutils-telnet/filelist
[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.
- The package works well right after install
[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.
- The package is maintained well in Debian/Ubuntu/Upstream and does
not have too many, long-term & critical, open bugs
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=inetutils
- Upstream-Homepage: https://www.gnu.org/software/inetutils/
- Upstream-Bugtracker: https://lists.gnu.org/archive/html/bug-inetutils/
- The package does not deal with exotic hardware we cannot support
[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
- The package runs a test suite on build time, if it fails
it makes the build fail
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
- The package runs an autopkgtest, and is currently passing on
amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
- link to builds (logs can be accessed through the web UI)
https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=built&arch_tag=all
- Link to autopkgtests https://autopkgtest.ubuntu.com/packages/i/inetutils
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 they
allways fail, this is ok because the failure occures at the
inetutils-ping package.
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.
- Not relevant for this package.
[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.
- debian/watch is present and works
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)
- 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
- This package does not yield massive lintian Warnings, Errors
- Recent build log of inetutils: https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=all&arch_tag=all
- Full output of `lintian --pedantic` is attached as an extra post to this bug.
- A lintian overrides is present, but ok because it is unused
- The lintian Error 'inetutils changes: bad-distribution-in-changes-file lunar-amd64'
emitted in the build log, this is because the debian/changelog file
specifies 'unstable' as distribution.
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.
- This package does not rely on obsolete or about to be demoted packages.
(The dependencies had recent updates and I could not find any open bug
ticket that indicates a upcoming demotion)
- This package has no python2 or GTK2 dependencies
RULE: - Debconf questions should not bother the default user too much
- The package will be installed by default, but does not ask debconf
questions
RULE: - The source packaging (in debian/) should be reasonably easy to
RULE: understand and maintain.
- Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/inetutils/tree/debian/control
- There is still the complication that building/testing inetutils-telnet
can fail because of other inetutils-* packages.
[UI standards]
- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because it is a
command line tool for sysadmins
[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)
- No further depends or recommends dependencies that are not yet in main
[Standards compliance]
RULE: - Major violations should be documented and justified.
RULE: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[https://www.debian.org/doc/debian-policy/|Debian Policy]]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
RULE: The package must have an acceptable level of maintenance corresponding
RULE: to its complexity:
RULE: - All packages must have a designated "owning" team, regardless of
RULE: complexity, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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.
- Owning Team will be Ubuntu Foundations
- Ubuntu Foundations Bugs is already subscribed to the package
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 ecosytem 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: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/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
- This does not use static builds
- This does not use vendored code
- This package is not rust based
[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.
- The Package description explains the package well
- Debian transitioned its default ‘telnet’ client from netkit-telnet to
inetutils-telnet. This transition was postponed in Ubuntu for kinetic by
having ubuntu-standard Recommend `netkit-telnet` instead of `telnet`.
But now, netkit-telnet has been dropped altogether from Debian and
process-removals is prompting us to also delete it from lunar.
(See: https://packages.debian.org/bookworm/telnet)
- other binary packages from this inetutils might be brought into main
accidentally, or even intentionally but with limited oversight, in the future.
- mixed main/universe is a foreign concept to users
Seeded in lunar.standard as a replacement for netkit-telnet:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?h=lunar&id=349619dc49fdd0695c0bd7f9ae72f535809c2657 |
|
| 2023-03-09 10:17:57 |
Dominik Viererbe |
attachment added |
|
build.log https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2008789/+attachment/5653144/+files/build.log |
|
| 2023-03-14 10:15:08 |
Dominik Viererbe |
description |
WORK IN PROGRESS by foundations
due to https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2009814
Dear reviewers, this is my first MIR. I answered all questions very
carefully, but if something feels wrong, please look extra closely or
ask me (~dviererbe) to reinvestigate a given answer.
[Availability]
The package inetutils-telnet is already in Ubuntu universe.
The package inetutils-telnet build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
Link to package [[https://launchpad.net/ubuntu/+source/inetutils|inetutils]]
[Rationale]
RULE: There must be a certain level of demand for the package
The package inetutils-telnet is required in Ubuntu main:
- The package inetutils-telnet will not generally be useful for a large part of
our user base, but is important/helpful still because it is commonly used for
network diagnostics, like protocol testing of SMTP services.
- Additionally telnet is still used for legacy industrial and scientific
equipment.
- Package inetutils-telnet covers similar use cases as netkit-telnet, but
is better because netkit-telnet has been dropped altogether from Debian,
thereby we want to replace it.
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 priorization 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
- The package inetutils-telnet is required in Ubuntu main no later than
April 13th 2023 due to the Ubuntu 23.04 Lunar Lobster release date.
[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>
- Had security issues in the past:
- CVE-2019-0053 (needs triage)
- https://ubuntu.com/security/CVE-2019-0053
- most likely not relevant:
- CVE-2022-39028 (only related to telnetd)
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-39028
- https://ubuntu.com/security/CVE-2022-39028
- CVE-2020-10188 (related to netcat):
- https://www.openwall.com/lists/oss-security/2018/12/13/2
- https://www.openwall.com/lists/oss-security/2018/12/14/8
- CVE-2011-4862 (related to telnetd; not sure if relevant anymore)
- https://ubuntu.com/security/CVE-2011-4862
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862
- security issues were patched or reached end of life
RULE: - Check for security relevant binaries and behavior.
RULE: If any are present, this requires a more in-depth security review.
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...)
- See list of files for:
- amd64: https://packages.ubuntu.com/lunar/amd64/inetutils-telnet/filelist
- arm64: https://packages.ubuntu.com/lunar/arm64/inetutils-telnet/filelist
- armhf: https://packages.ubuntu.com/lunar/armhf/inetutils-telnet/filelist
- i386: https://packages.ubuntu.com/lunar/i386/inetutils-telnet/filelist
- ppc64el: https://packages.ubuntu.com/lunar/ppc64el/inetutils-telnet/filelist
- s390x: https://packages.ubuntu.com/lunar/s390x/inetutils-telnet/filelist
[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.
- The package works well right after install
[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.
- The package is maintained well in Debian/Ubuntu/Upstream and does
not have too many, long-term & critical, open bugs
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=inetutils
- Upstream-Homepage: https://www.gnu.org/software/inetutils/
- Upstream-Bugtracker: https://lists.gnu.org/archive/html/bug-inetutils/
- The package does not deal with exotic hardware we cannot support
[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
- The package runs a test suite on build time, if it fails
it makes the build fail
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
- The package runs an autopkgtest, and is currently passing on
amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
- link to builds (logs can be accessed through the web UI)
https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=built&arch_tag=all
- Link to autopkgtests https://autopkgtest.ubuntu.com/packages/i/inetutils
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 they
allways fail, this is ok because the failure occures at the
inetutils-ping package.
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.
- Not relevant for this package.
[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.
- debian/watch is present and works
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)
- 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
- This package does not yield massive lintian Warnings, Errors
- Recent build log of inetutils: https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=all&arch_tag=all
- Full output of `lintian --pedantic` is attached as an extra post to this bug.
- A lintian overrides is present, but ok because it is unused
- The lintian Error 'inetutils changes: bad-distribution-in-changes-file lunar-amd64'
emitted in the build log, this is because the debian/changelog file
specifies 'unstable' as distribution.
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.
- This package does not rely on obsolete or about to be demoted packages.
(The dependencies had recent updates and I could not find any open bug
ticket that indicates a upcoming demotion)
- This package has no python2 or GTK2 dependencies
RULE: - Debconf questions should not bother the default user too much
- The package will be installed by default, but does not ask debconf
questions
RULE: - The source packaging (in debian/) should be reasonably easy to
RULE: understand and maintain.
- Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/inetutils/tree/debian/control
- There is still the complication that building/testing inetutils-telnet
can fail because of other inetutils-* packages.
[UI standards]
- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because it is a
command line tool for sysadmins
[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)
- No further depends or recommends dependencies that are not yet in main
[Standards compliance]
RULE: - Major violations should be documented and justified.
RULE: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
RULE: - [[https://www.debian.org/doc/debian-policy/|Debian Policy]]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
RULE: The package must have an acceptable level of maintenance corresponding
RULE: to its complexity:
RULE: - All packages must have a designated "owning" team, regardless of
RULE: complexity, which is set as a package bug contact. This is not a
RULE: requirement for the MIR team ACK, but for the package to be promoted
RULE: by an archive admin. Still, it is strongly suggested to subscribe,
RULE: as the owning team will get a preview of the to-be-expected incoming
RULE: 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.
- Owning Team will be Ubuntu Foundations
- Ubuntu Foundations Bugs is already subscribed to the package
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 ecosytem 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: d/rules:
RULE: override_dh_auto_test:
RULE: CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
RULE: d/<pkg>.install:
RULE: Cargo.lock /usr/share/doc/<pkg>
RULE: d/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
- This does not use static builds
- This does not use vendored code
- This package is not rust based
[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.
- The Package description explains the package well
- Debian transitioned its default ‘telnet’ client from netkit-telnet to
inetutils-telnet. This transition was postponed in Ubuntu for kinetic by
having ubuntu-standard Recommend `netkit-telnet` instead of `telnet`.
But now, netkit-telnet has been dropped altogether from Debian and
process-removals is prompting us to also delete it from lunar.
(See: https://packages.debian.org/bookworm/telnet)
- other binary packages from this inetutils might be brought into main
accidentally, or even intentionally but with limited oversight, in the future.
- mixed main/universe is a foreign concept to users
Seeded in lunar.standard as a replacement for netkit-telnet:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?h=lunar&id=349619dc49fdd0695c0bd7f9ae72f535809c2657 |
Dear reviewers, this is my first MIR. I answered all questions very
carefully, but if something feels wrong, please look extra closely or
ask me (~dviererbe) to reinvestigate a given answer.
[Availability]
The package inetutils-telnet is already in Ubuntu universe.
The package inetutils-telnet build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
Link to package [[https://launchpad.net/ubuntu/+source/inetutils|inetutils]]
[Rationale]
The package inetutils-telnet is required in Ubuntu main:
- The package inetutils-telnet will not generally be useful for a large part of
our user base, but is important/helpful still because it is commonly used for
network diagnostics, like protocol testing of SMTP services.
- Additionally telnet is still used for legacy industrial and scientific
equipment.
- Package inetutils-telnet covers similar use cases as netkit-telnet, but
is better because netkit-telnet has been dropped altogether from Debian,
thereby we want to replace it.
- The package inetutils-telnet is required in Ubuntu main no later than
April 13th 2023 due to the Ubuntu 23.04 Lunar Lobster release date.
[Security]
- Had security issues in the past:
- CVE-2019-0053 (needs triage)
- https://ubuntu.com/security/CVE-2019-0053
- most likely not relevant:
- CVE-2022-39028 (only related to telnetd)
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-39028
- https://ubuntu.com/security/CVE-2022-39028
- CVE-2020-10188 (related to netcat):
- https://www.openwall.com/lists/oss-security/2018/12/13/2
- https://www.openwall.com/lists/oss-security/2018/12/14/8
- CVE-2011-4862 (related to telnetd; not sure if relevant anymore)
- https://ubuntu.com/security/CVE-2011-4862
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862
- security issues were patched or reached end of life
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...)
- See list of files for:
- amd64: https://packages.ubuntu.com/lunar/amd64/inetutils-telnet/filelist
- arm64: https://packages.ubuntu.com/lunar/arm64/inetutils-telnet/filelist
- armhf: https://packages.ubuntu.com/lunar/armhf/inetutils-telnet/filelist
- i386: https://packages.ubuntu.com/lunar/i386/inetutils-telnet/filelist
- ppc64el: https://packages.ubuntu.com/lunar/ppc64el/inetutils-telnet/filelist
- s390x: https://packages.ubuntu.com/lunar/s390x/inetutils-telnet/filelist
[Quality assurance - function/usage]
- The package works well right after install
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu/Upstream and does
not have too many, long-term & critical, open bugs
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=inetutils
- Upstream-Homepage: https://www.gnu.org/software/inetutils/
- Upstream-Bugtracker: https://lists.gnu.org/archive/html/bug-inetutils/
- 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
- The package runs an autopkgtest, and its builds are currently passing on
amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
- link to builds (logs can be accessed through the web UI)
https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=built&arch_tag=all
- Link to autopkgtests https://autopkgtest.ubuntu.com/packages/i/inetutils
- The package does have failing autopkgtests tests right now, but they
allways fail (See: https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2009814)
This is okay because the failure occures at the inetutils-ping package.
The Foundations Team is working on a fix.
[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Recent build log of inetutils: https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=all&arch_tag=all
- Full output of `lintian --pedantic` is attached as an extra post to this bug.
- A lintian overrides is present, but ok because it is unused
- The lintian Error 'inetutils changes: bad-distribution-in-changes-file lunar-amd64'
emitted in the build log, this is because the debian/changelog file
specifies 'unstable' as distribution.
- This package does not rely on obsolete or about to be demoted packages.
(The dependencies had recent updates and I could not find any open bug
ticket that indicates a upcoming demotion)
- This package has no python2 or GTK2 dependencies
- The package will be installed by default, but does not ask debconf
questions
- Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/inetutils/tree/debian/control
- There is still the complication that building/testing inetutils-telnet
can fail because of other inetutils-* packages.
[UI standards]
- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because it is a
command line tool for sysadmins
[Dependencies]
- No further depends or recommends dependencies that are not yet in main
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- Owning Team will be Ubuntu Foundations
- Ubuntu Foundations Bugs is already subscribed to the package
- This does not use static builds
- This does not use vendored code
- This package is not rust based
[Background information]
- The Package description explains the package well
- Debian transitioned its default `telnet` client from netkit-telnet to
inetutils-telnet. This transition was postponed in Ubuntu for kinetic by
having ubuntu-standard Recommend `netkit-telnet` instead of `telnet`.
But now, netkit-telnet has been dropped altogether from Debian and
process-removals is prompting us to also delete it from lunar.
(See: https://packages.debian.org/bookworm/telnet)
- other binary packages from this inetutils might be brought into main
accidentally, or even intentionally but with limited oversight, in the future.
- mixed main/universe is a foreign concept to users
Seeded in lunar.standard as a replacement for netkit-telnet:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?h=lunar&id=349619dc49fdd0695c0bd7f9ae72f535809c2657 |
|
| 2023-03-14 10:24:59 |
Lukas Märdian |
inetutils (Ubuntu): status |
Incomplete |
New |
|
| 2023-03-14 10:25:19 |
Lukas Märdian |
inetutils (Ubuntu): assignee |
Dominik Viererbe (dviererbe) |
|
|
| 2023-03-14 15:37:18 |
Christian Ehrhardt |
inetutils (Ubuntu): assignee |
|
Ioanna Alifieraki (joalif) |
|
| 2023-03-21 09:25:36 |
Dominik Viererbe |
bug |
|
|
added subscriber Dominik Viererbe |
| 2023-03-28 11:38:05 |
Ioanna Alifieraki |
inetutils (Ubuntu): assignee |
Ioanna Alifieraki (joalif) |
Ubuntu Security Team (ubuntu-security) |
|
| 2023-03-28 14:59:04 |
Seth Arnold |
tags |
fr-2983 lunar |
fr-2983 lunar sec-1893 |
|
| 2023-03-29 10:42:35 |
Lukas Märdian |
bug task added |
|
netkit-telnet-ssl (Ubuntu) |
|
| 2023-03-29 10:42:54 |
Lukas Märdian |
netkit-telnet-ssl (Ubuntu): assignee |
|
Ubuntu Foundations Bugs (foundations-bugs) |
|
| 2023-03-29 10:43:07 |
Lukas Märdian |
tags |
fr-2983 lunar sec-1893 |
fr-2983 lunar rls-mm-incoming sec-1893 |
|
| 2023-03-29 13:42:10 |
Mark Esler |
summary |
[MIR] inetutils |
[MIR] inetutils-telnet |
|
| 2023-03-29 18:29:10 |
Jay Vosburgh |
bug |
|
|
added subscriber Jay Vosburgh |
| 2023-03-30 00:27:23 |
Mark Esler |
bug watch added |
|
http://savannah.gnu.org/bugs/?61723 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2011-4862 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2019-0053 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2020-10188 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-40491 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-45774 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-45775 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-45778 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-45779 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-45780 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-45781 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-45782 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-46058 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2021-46060 |
|
| 2023-03-30 00:27:23 |
Mark Esler |
cve linked |
|
2022-39028 |
|
| 2023-03-30 00:27:40 |
Mark Esler |
inetutils (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2023-03-30 00:27:49 |
Mark Esler |
inetutils (Ubuntu): status |
New |
In Progress |
|
| 2023-03-30 00:28:04 |
Mark Esler |
bug |
|
|
added subscriber Mark Esler |
| 2023-03-30 00:34:36 |
Mark Esler |
attachment added |
|
coverity.txt https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2008789/+attachment/5658765/+files/coverity.txt |
|
| 2023-04-04 12:53:35 |
Lukas Märdian |
inetutils (Ubuntu): status |
In Progress |
Incomplete |
|
| 2023-04-04 14:45:32 |
Dominik Viererbe |
inetutils (Ubuntu): status |
Incomplete |
Fix Released |
|
| 2023-04-05 07:25:31 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~slyon/ubuntu-seeds/+git/platform/+merge/440372 |
|
| 2023-04-11 15:37:54 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~slyon/ubuntu-seeds/+git/ubuntu/+merge/440761 |
|
| 2023-06-22 15:16:01 |
Dominik Viererbe |
netkit-telnet-ssl (Ubuntu): status |
New |
Won't Fix |
|
| 2023-06-22 15:16:17 |
Dominik Viererbe |
tags |
fr-2983 lunar rls-mm-incoming sec-1893 |
fr-2983 lunar sec-1893 |
|
| 2023-06-22 15:16:57 |
Dominik Viererbe |
netkit-telnet-ssl (Ubuntu): assignee |
Ubuntu Foundations Bugs (foundations-bugs) |
|
|
