Review for Source Package: s390-tools

[Summary]

The package and in particular the addition of the rust part has a couple of
problems but both seem to be workedaround.
The first is the lack of any test suite, however the partner and solutions QA 
have been engaged to help with testging and therefore we are good on that front.

Secondly, the package vendors code, but Founfations team are already aware and
have agreed to provide updates and backports of security fixes for any affected
vendored code for the lifetime of the release (including ESM).

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: libekmfweb-dev, libekmfweb1, libkmipclient-dev,
libkmipclient1, s390-tools-chreipl-fcp-mpath, s390-tools-cpuplugd, s390-tools-data, s390-tools-osasnmpd,
s390-tools-statd, s390-tools-zkey, s390-tools
Specific binary packages built, but NOT to be promoted to main: <None>

Notes:

- The package is already in main and have a team subscriber.

Recommended TODOs:
1. Please double check lintian output and confirm nothing is critical.


[Duplication]
The package s390-tools is already in Ubuntu main, and is re-reviewed due to signinficant changes in the package (new Rust code-base, including vendored dependencies).

[Dependencies]
OK:
- no other Dependencies to MIR due to this
 - s390-tools 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 static linking
- does not have unexpected Built-Using entries
- Rust package that has all dependencies vendored. It does neither
  have *Built-Using (after build). Nor does the build log indicate
  built-in sources that are missed to be reported as Built-Using.
- rust package using dh_cargo (dh ... --buildsystem cargo)
- Includes vendored code, the package has documented how to refresh this
  code at https://launchpadlibrarian.net/688249928/s390-tools.debdiff
  This is only a debdiff, but when the uplaod is done the process can be found
  in the package at debian/README.source /

Problems: None

[Security]
OK:
- 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 expose any external endpoint (port/socket/... or similar)
- 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)
- this makes appropriate (for its exposure) use of established risk
   mitigation features (dropping permissions, using temporary environments,
  restricted users/groups, seccomp, systemd isolation features,
  apparmor, ...)

Problems:
- has some history of CVEs 
- does not with cryptography (en-/decryption, certificates,
  signing, ...)
- does deal with security attestation (secure boot, tpm, signatures)

[Common blockers]
OK:
- does not FTBFS currently
- This does seem to need special HW for build or test so it can't be
  automatic at build or autopkgtest time. But as outlined
  by the requester in [Quality assurance - testing] there:
  - are partner engagements and a test plan or code
  - an agreement with solutions-qa to be able to test this for Ubuntu
- no new python2 dependency

Problems:
- does have a test suite that runs at build time
- does have a non-trivial test suite that runs as autopkgtest

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under
  control
- symbols tracking is in place.
- debian/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is good
- 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
- debian/rules is rather clean
- It is not on the lto-disabled list

Problems: None
- quite a few Lintian warnings

[Upstream red flags]
OK:
- 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 / setgid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (user visible)?

Problems:
- many warnings during build when it comes to rust code