On Fri, Oct 29, 2021 at 07:04:51AM -0000, Christian Ehrhardt  wrote:
> Review for Package: libtpms

> Required TODOs:
> - please package the current v0.9

This has been uploaded.

> - Fix the ppc64 FTBFS
>   https://launchpadlibrarian.net/557789130/buildlog_ubuntu-impish-ppc64el.libtpms_0.8.2-1ubuntu1_BUILDING.txt.gz

I would argue that, given that this is a virtual implementation of hardware
that is not present on the ppc64el architecture, portability to ppc64el
should not be a blocker for MIR.  I looked into the failure, but it's
non-trivial; as far as I can tell the current failure is a toolchain bug,
and if I work around it, there is another build failure (Debian bug #997969)
which is also toolchain weirdness.  Neither issue indicates a problem with
the quality of the code, so I don't think this should block support of the
package on architectures where it is currently supportable.

> - Track and resolve https://github.com/stefanberger/libtpms/issues/215
>   to ensure this works well with openssl3.0 in Ubuntu 22.04

A test build of libtpms 0.9.0 against openssl 3 succeeds (0.8.2 fails).

> Recommended TODOs:
> - Right now it has no autopkgtest, maybe - like swtpm this could at least run
>   the build time tests to spot things as early as dependency-update
>   instead of "on the next rebuild"?

I've added an autopkgtest now; it's a simple 'make check' which
unfortunately means it builds and tests against a rebuilt library instead of
against the binaries from the archive, but I think this is better than
nothing as a first pass.

> - The package should get a team bug subscriber before being promoted

Foundations is now subscribed.

> Problems:
> - important open bugs (crashers, etc) in Debian or Ubuntu
>   IMHO there is one worthile to track (but no immediate action needed)
>   FIPS:  https://github.com/stefanberger/libtpms/issues/51

Well, as far as I'm aware Canonical has no product for FIPS certification of
a virtualization stack, so I don't see any reason that FIPS for libtpms
would be "important" for us.

On Thu, Oct 28, 2021 at 12:35:24PM -0000, Christian Ehrhardt  wrote:
> FYI - via discussion we found that swtpm-tools will be needed, that
> either needs to get the dependencies adapted (to not depend on gnutls-
> bin or have them not depend on libopts25) or to promote those as well.

> I'll re-evaluate swtpm with that in mind and update my former post
> (probably tomorrow).

swtpm 0.6.1-0ubuntu4 now uploaded to trade the gnutls-bin dependency for
openssl.

On Thu, Oct 28, 2021 at 10:07:58AM -0000, Christian Ehrhardt  wrote:
> Required TODOs:
> - Please fixup the user/group creation (see bug 1949060)

This is done.

> - libtpms-dev doesn't exist on ppc64el and thereby IMHO blocks too many
>   important use cases from being generally working. Please investigate to
>   add that and/or explain why this shall be considered not a problem.

Discussed above.

> - The autopkgtest suite needs to pass (actually run) on arm64 (stalled
>   by long queue)

This has passed now (several times, in fact).

> Recommended TODOs:
> - While the lib is internal, .symbols tracking usually is cheap and protects
>   even internal libs from some mistakes, consider adding it.

I disagree that this is worthwhile; any changes to the symbols of an
internal library that cause us to have to make changes to a symbols file are
busywork.

> - Version 0.7.0 seems rather close please update it later this cycle
>   https://github.com/stefanberger/swtpm/issues/587

Thanks, will track.

> - The package should get a team bug subscriber before being promoted
>   Right now I do not see it subscribed by "foundations-bugs" yet

Foundations is now subscribed.

> - evaluate the possibility and impact of having "tcsd" in the build environment

The problem is that the trousers package is itself buggy and frequently
fails to install, so build-depending on it for the testsuite is not an
improvement in QA.

I believe that addresses everything except for the security review.