[MIR] inetutils-telnet

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

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.

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

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.

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.

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.

@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 ?

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

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-...

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.

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.

* 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

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

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.

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 ...

attached is inetutils' coverity.txt

> 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.

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.

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?

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.