[MIR] inetutils-telnet

[Lukas Märdian]

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

[Seth Arnold (seth-arnold)]

Please, lets drop telnet from main rather than bring in rexecd, rcp, rsh, rshd, rlogin, tftp, tftpd, inetd, whois, talkd, talk, etc. A single telnet client is one thing; a dozen tools, many servers ,is entirely something else.

nc -t claims to support some portion of the telnet protocol:

     -t Send RFC 854 DON'T and WON'T responses to RFC 854 DO
             and WILL requests. This makes it possible to use nc to
             script telnet sessions.

Would this be sufficient?

Thanks

[Lukas Märdian (slyon)]

We might want to only promote the inetutils-telnet[d] binary packages in this case.. But not anything else built from the inetutils source package.

[Seth Arnold (seth-arnold)]

This is indeed far more approachable:

$ apt-file show inetutils-telnet
inetutils-telnet: /usr/bin/inetutils-telnet
inetutils-telnet: /usr/share/doc/inetutils-telnet/AUTHORS
inetutils-telnet: /usr/share/doc/inetutils-telnet/NEWS.gz
inetutils-telnet: /usr/share/doc/inetutils-telnet/THANKS
inetutils-telnet: /usr/share/doc/inetutils-telnet/changelog.Debian.gz
inetutils-telnet: /usr/share/doc/inetutils-telnet/copyright
inetutils-telnet: /usr/share/lintian/overrides/inetutils-telnet
inetutils-telnet: /usr/share/man/man1/inetutils-telnet.1.gz

I'm still concerned that other binary packages from this source might be brought in to main accidentally, or even intentionally but with limited oversight, in the future. (Not to mention that mixed main/universe is a foreign concept to users.)

But this is indeed far better.

Thanks

[Lukas Märdian (slyon)]

Steve suggested we should add some lines to the seed, which explicitly exclude all the other non-"inetutils-telnet" binary packages. This way we would not accidentally pull them into main.

[Dominik Viererbe (dviererbe)]

Here is the output of lintian --pedantic:
W: inetutils source: mismatched-override very-long-line-length-in-source-file * > * [aclocal.m4:*]
W: inetutils source: newer-standards-version 4.6.2 (current is 4.6.0.1)
P: inetutils source: very-long-line-length-in-source-file aclocal.m4 line 429 is 603 characters long (>512)
N: 0 hints overridden; 1 unused override

------------------------------------------

I also attached the output of a local build. Please note that the lintian output does not match.

[Lukas Märdian (slyon)]

Moving this to NEW (ready for review). We still have failing autopkgtests, but those are passing in DebCI: https://ci.debian.net/packages/inetutils/inetutils/ and we're aware of the issue in Ubuntu (LP: #2009814). Foundations is actively working on resolving those, as part of our regular proposed-migration work, this shouldn't block the MIR review.

[Ioanna Alifieraki (joalif)]

@dviererbe

I'm going through the review and I want some confirmation on what packages need to be promoted.
IIUC, from the discussion above, out of the 13 binary packages inetutils source package provides, you just want the 'inetutils-telnet' binary package ? What about the inetutils-telnetd, telnet and telnetd. Do you want them to be promoted ?

[Lukas Märdian (slyon)]

Just inetutils-telnet (and its telnet alias) should be enough.

[Ioanna Alifieraki (joalif)]

Review for Package: inetutils

[Summary]
MIR team ACK
This does need a security review, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: inetutils-telnet, telnet
Specific binary packages built, but NOT to be promoted to main: inetutils-ftp, inetutils-ftpd, inetutils-inetd,
inetutils-ping, inetutils-syslogd, inetutils-talk, inetutils-talkd, inetutils-telnetd, inetutils-tools,
inetutils-traceroute, telnetd

Notes:
No required or recommended TODOs, only sec-review is needed.

[Duplication]
There is no other package in main providing the same functionality.
inetutils-telnet is to replace netkit-telener which had been dropped form Debian.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - inetutils checked with `check-mir`
  - all dependencies can be found in `seeded-in-ubuntu` (already in main)
  - none of the (potentially auto-generated) dependencies (Depends
    and Recommends) that are present after build are not in main
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard
- Does not include vendored code

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- does deal with cryptography (en-/decryption, certificates, signing, ...)
- does not open a port/socket

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- does have a non-trivial test suite that runs as autopkgtest
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- debian/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- debian/rules is rather clean
- It is not on the lto-disabled list

Problems: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
  tests)
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-...

[Mark Esler (eslerm)]

It appears that Debian dropped netkit-telnet for netkit-telnet-ssl.

https://packages.debian.org/sid/telnet-ssl

> SSL telnet replaces normal telnet using SSL authentication and encryption. It interoperates with normal telnetd in both directions. It checks if the other side is also talking SSL, if not it falls back to normal telnet protocol.

[Lukas Märdian (slyon)]

telnet-ssl doesn't seem to be a drop-in replacement, as it provides /usr/bin/telnet-ssl only, so we'd break any scripts making use of /usr/bin/telnet. So that package would need more work on our end to make it compatible.

Edit: Actually, telnet-ssl is using update-alternatives to provide /usr/bin/telnet, too.

[Dominik Viererbe (dviererbe)]

* netkit-ssl also looks like a good alternative, but as far as I can tell; Debian uses inetutils-telnet as the telnet replacement:
  - See bullseye resolves telnet to netkit-telnet:
    - https://packages.debian.org/bullseye/telnet
  - See bookworm and sid rolsoves telnet to inetutils-telnet
    - https://packages.debian.org/bookworm/telnet
    - https://packages.debian.org/sid/telnet

* check-mir looks good

* netkit-telnet-ssl installs itself as telnet via update-alternatives

* it seems to strictly extend the netkit-telnet functionality; without depending on netkit-telnet (I could not find something that netkit-telnet does but netkit-telnet-ssl doesn't)

* netkit-telnet-ssl has no tests; to be fair inetutils-telnet tests are not great and netkit-telnet has also no tests

[Mark Esler (eslerm)]

Seth pointed out to me that Debian is using inetutils for telent https://packages.debian.org/sid/telnet

[Mark Esler (eslerm)]

Apologize Dominik, that was redundant.

I have mostly completed auditing inetutils-telnet and have lightly audited netkit-telnet-ssl. They seem roughly equivalent for code quality. inetutils-telnet provides kerberos and shishi, but not ssl. Also, inetutils' telnet-localhost.sh build test is skipped on lunar.

[Mark Esler (eslerm)]

I reviewed inetutils-telnet 2:2.4-2ubuntu1 as checked into lunar. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

Only telnet related code was audited.

- CVE History:
  - 14 CVEs assigned to inetutils
    - CVE-2011-4862 CVE-2021-40491 CVE-2021-45774 CVE-2021-45775 CVE-2021-45778 CVE-2021-45779 CVE-2021-45780 CVE-2021-45781 CVE-2021-45782 CVE-2021-46058 CVE-2021-46060 CVE-2019-0053 CVE-2020-10188 CVE-2022-39028
  - many of the 2021 CVEs were later revoked, but seem to describe real vulnerabilities
    - why the CNA (MITRE) revoked them is unknown
      - often done at upstream's request
    - e.g., CVE-2021-45778
      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45778
      - https://lists.gnu.org/archive/html/bug-inetutils/2021-12/msg00004.html
      - https://savannah.gnu.org/bugs/?61723
      - https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=ef17ae467e8893f1e3dade95212e91fc411d2714
  - NEWS contains many security issues not assigned CVEs
    - https://git.savannah.gnu.org/cgit/inetutils.git/tree/NEWS
    - security issues that upstream tracks *as bugs* are unlikely to be patched
  - in NEWS, the CVE ID number "CVE-2019-0053" is being reused for multiple vulnerabilities
    - it is being used to describe all unsanitized input vulnerabilities ?
  - vulnerabilities are not being tracked with CVEs by upstream
    - difficult for downstream maintenance to track
- Build-Depends?
  - debhelper-compat
  - debhelper
  - netbase
  - net-tools
  - autoconf
  - automake
  - bison
  - libreadline-dev
  - libncurses-dev
  - libpam0g-dev
  - libwrap0-dev
  - libkrb5-dev
- pre/post inst/rm scripts?
  - used by telnet to manage dh_installalter natives of telnet between inetutils and netkit
- init scripts?
  - not for telnet
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - not for telnet
- binaries in PATH?
  - ./usr/bin/inetutils-telnet
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - telnet build test is skipped !
    - `SKIP: telnet-localhost.sh`
  - contains autopkgtests
- cron jobs?
  - none
- Build logs:
  - there are lintian errors for non-telnet packages
    - debian/inetutils-telnet.lintian-overrides is trivial
  - MANY build warnings
    - most for other packages in source package
  - trivial lintian overrides

- Processes spawned?
  - command.c's shell() vfork's to execute a local shell command
  - of course, commands are sent to telenetd
- Memory management?
  - heavy use, mostly in ./libtelnet/
  - use of setjmp/longjmp
    - jump is being used with async calls, which can be an issue if signal mask are changed before longjmp
    - netkit's telnet is derived from same base code, netkit uses sigsetjump/siglongjmp to control signal mask
    - nb, how setjmp affects signal mask has changed since original unix code
      - conditional use of unix/linux ioctl calls suggests that jumps should be portable as well
    - Security is fine with this client side
  - some buffer size checks
  - uses snprintf instead of sprintf where appropriate
  - static analyzers found memory leaks
- File IO?
  - used to ...

[Mark Esler (eslerm)]

attached is inetutils' coverity.txt

[Steve Langasek (vorlon)]

> Security team ACK for promoting inetutils-telnet to main.

This hasn't been moved to fix-committed yet by the MIR team, but this really needs to be fixed by lunar release so I am going to pre-promote inetutils to main now to fix the regression in ubuntu-standard recommends. If there are any further issues, they should be addressed here before marking the bug closed.

[Dominik Viererbe (dviererbe)]

inetutils-telnet pulls in all the other inetutils-* binary packages

This can be seen here: https://ubuntu-archive-team.ubuntu.com/germinate-output/ubuntu.lunar/all+extra

with these entries

Package | Source | Why
------------------+-----------+-----------------------
inetutils-ftp | inetutils | Generated by inetutils
inetutils-ftpd | inetutils | Generated by inetutils
inetutils-inetd | inetutils | Generated by inetutils
inetutils-ping | inetutils | Generated by inetutils
inetutils-syslogd | inetutils | Generated by inetutils
inetutils-talk | inetutils | Generated by inetutils
inetutils-talkd | inetutils | Generated by inetutils
inetutils-telnetd | inetutils | Generated by inetutils
inetutils-tools | inetutils | Generated by inetutils

Lukas Märdian (slyon) wants to investigate how to solve this problem.

[Lukas Märdian (slyon)]

So inetutils-telnet got promoted. This leads to all the inetutils-* binaries (like inetutils-ftpd) to be listed in the "extra" seed, i.e. not seeded anywhere, but still generated by the src:inetutils source package, which we have in main.

In comment #4 we considered explicitly exluding the other binary packages, besides inetutils-telnet & telnet. I tried a few things but didn't get the desired result:

* blacklisting via ubuntu.lunar/blacklist seed
* blacklisting via platform.lunar/{standard,minimal} seeds, using !%inetutils and/or !inetutils-*
* excluding via ubuntu.lunar/supported seed, using Extra-Exclude: %inetutils and/or inetituls-*

I wonder if/how it would be possible to blacklist all the binary packages from src:inetutils, except the telnet client?

[Lukas Märdian (slyon)]

We didn't come up with a better solution during the MIR meeting today. Let's call this "fix released", as every binary is in the place it's supposed to be.

We need to be careful not to accidentally pull some of the other inetutils-* binaries into main in the future. But apparently there are other cases like this (only a single binary in main, while other from the same source package are in universe) and this has worked OK so far.