[Bug 2056485] Re: Behaviour of socat in Ubuntu 20.04 unexpected

Wed Apr 10 10:18:24 UTC 2024

Interleaving Frank's and jldolan's comments here:

> I just assumed socat was not a very popular package.

My experience is the opposite! I understand it to be used in all kinds
of corners - particularly in user scripts that don't appear in the
archive.

> I've learned (and I generally agree with that) that it is better to
stick to entire upstream commits/patches (if possible) for the reason of
future maintainability.

This is true for development branch tips, but not for the maintenance of
stable releases. "Future maintainability" is minimal for socat in Focal,
for example: it hasn't had an update since before Focal's release in
2020, and is likely to only need the odd security update in the future.

SRU policy says this:

> ...the requirements for stable updates are not necessarily the same as
those in the development release. When preparing future releases, one of
our goals is to construct the most elegant and maintainable system
possible, and this often involves fundamental improvements to the
system's architecture, rearranging packages to avoid bundled copies of
other software so that we only have to maintain it in one place, and so
on. However, once we have completed a release, the priority is normally
to minimise risk caused by changes not explicitly required to fix
qualifying bugs, and this tends to be well-correlated with minimising
the size of those changes. As such, the same bug may need to be fixed in
different ways in stable and development releases.

Therefore, I do not expect to see a change to Makefile.am in this case
where changing the build system isn't necessary to fix the bug. If we
decide to go ahead with the SRU (see below), then I'd like the upload
replaced with a minimal one, please.

Improvements to test suites are generally fine though, as they pose
little risk to production users and we can benefit from such
improvements during SRU verification. As long as we aren't making the
tests less useful :)

> I think it's close to a philosophical question what is best to do in case "users of 20.04 relying on the current behaviour".
> I personally believe that since the behavior is wrong, that it needs to be corrected.

I agree that it's a difficult question. Like you, I generally lean
towards fixing bugs over changing behaviour: if the bug is obviously the
wrong behaviour, then I figure that it's perhaps a regression for
existing users that would be acceptable. So I would agree were this an
issue in Jammy. But Focal is four years old now. At this point I think
there are far more users relying on existing behaviour than new
deployments relying on correct behaviour. This is what gives me concern.

>  Please notice that the behavior is correct in all releases newer than
focal - means if not fixing this now with an upgrade, things will break
at least after a dist-upgrade.

This is fine - users expect behaviour changes over a release upgrade far
more than they expect behaviour changes during the lifetime of a
release. Considering just this point, the former is actually preferable.

> Let me check with the Novalink team to see if this is an acceptable
workaround for them.

Thanks - I think this should at least be considered first given the
above concern. If you conclude that it's not possible then I can consult
with the SRU team to make a final decision.

One possibility for example is to set an environment variable like
LP2056485_SOCAT_BEHAVIOUR and have this socat SRU only activate if that
is set. mkvterm could either set that, or you could arrange a wrapper.
Then we wouldn't have to worry about changed behaviour for other users.
I don't know if this is overkill though - I'd want to consult with other
SRU team members before going ahead with it.

** Changed in: socat (Ubuntu Focal)
       Status: In Progress => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2056485

Title:
  Behaviour of socat in Ubuntu 20.04 unexpected

Status in The Ubuntu-power-systems project:
  In Progress
Status in socat package in Ubuntu:
  Fix Released
Status in socat source package in Focal:
  Incomplete

Bug description:
  SRU Justification:

  [ Impact ]

   * IBM Novalink provides a tool called mkvterm.
     Mkvterm takes an lpar id argument and creates a vty-server device on
     device nodes /dev/hvcs*.
     HVCS is a device driver for the IBM Hypervisor Virtual Console Server
     (hvcs). Mkvterm then uses socat to connect.

   * But socat is not behaving as expected.
     When escape=0x1d is passed, you have to hit enter for socat to close
     (expected behavior is Ctrl-] closing the connection).

   * In addition, Ctrl-C closes the connection.
     When using the up and down arrows, junk is printed.
     Password is also visible!

   * This is caused by the fact that under certain circumstances,
     options of the first address are applied to the second address.

  [ Fix ]

   * 5ebf36038f39 5ebf36038f3960798e769bff5646e755a91a1119
     "Under certain circumstances, options of the first address were applied to the second address"

   * 9de26f1d0528 9de26f1d05284257cd9bbb6eb6662089ab7a0680
     "minor corrections, not affecting binaries"

  [ Test Plan ]

   * There was a special test case introduced for this change
     it's test #385.
     If this succeeds, the reported issue is solved.

   * Initially this test case failed, because it required another commit
     on top: 9de26f1d0528

   * To verify the overall end-2-end case, the fixes from LP#056373 are required
     as well, but can be taken from the PPA test build that was done there.

   * Then configure a vty-server and try to connect with socat:
     /usr/bin/socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs[minor num]

   * With an unpatched version one will see that the password is
  visible.

   * In addition, the up and down arrows do not work and junk is outputted.
     In addition, Ctrl-] does not close the vterm.

   * Ctrl-C closes the vterm, and it should not.

   * With a patched version the password will not be visible,
     Ctrl+] and Ctrl+C behave as expected.

  [ Where problems could occur ]

   * The code modification is limited to a single line in if
     and is pretty traceable, and it's on top limited to terminos.

   * If the changed condition of IF was done wrong, the expected
     behavior can change (again) and unforeseen things may happen.

   * The rest of the code changes are text in CHANGES and
     a new test case, introduced especially for this bug.

   * Nevertheless, issues can also occur in the (additional)
     test code (which happened and got fixed by adding 9de26f1d0528).

  [ Other Info ]

   * Even the code states that this bug is limited to v1.7.3.3.

   * Nevertheless, the code of the socat versions of jammy, mantic
     and noble were checked, and they all have the fix included.
     (However the code in noble's version changed a bit).

   * So only focal is affected.
  __________

  ---Problem Description---
  Novalink provides a tool called mkvterm. Mkvterm takes an lpar id argument and creates a vty-server device on device nodes /dev/hvcs*. HVCS is a device driver for the IBM Hypervisor Virtual Console Server (hvcs). Mkvterm then uses socat to connect.

  Socat is not behaving as expected. When escape=0x1d is passed, you
  have to hit enter for socat to close (expected behavior is Ctrl-]
  closing the connection). In addition, Ctrl-C closes the connection.
  When using the up and down arrows, junk is printed. Password is also
  visible.

  The follow commit fixes the above issues, please add:
  https://repo.or.cz/socat.git/commit/5ebf36038f39

  ---uname output---
  Linux neop91.pok.stglabs.ibm.com 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:54:35 UTC 2024 ppc64le ppc64le ppc64le GNU/Linux

  ---Steps to Reproduce---
   Fixes to other issues required to reproduce. Mentioned in other bugs.

  Configure a vty-server and try to connect with socat:

  /usr/bin/socat STDIO,raw,echo=0,escape=0x1d /dev/hvcs[minor num]

  Add You will see that the password is visible. In addition, the up and
  down arrows do not work, junk is outputted. In addition, Ctrl-] does
  not close the vterm. Ctrl-C closes the vterm, and it should not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2056485/+subscriptions