[Summary]
- After some longer checks it seems fine from a MIR/Packaging POV,
  but will need a security review as well.
  => MIR Team ack
- Assigning security

There are a few todos left open thou, nothing that would block the security
review:

@Openstack Team:
- it seems you need to maintain these on your own
  - have you contributed the 3.x versions to Debian?
  - nfs-ganesha is the only rev-dep so it might really be on you alone
  - if no one there steps up are you ok to self-maintain those as needed?
- you are not yet subscribed to the package this is a requirement before
  promoting it
- there seem to be very little self-tests but maybe those could be enabled
  on build (rpcping / citytest)?
- Probably an artifact of the new version, but symbols need to be updated
  - also shlibs fails should be made fatal IMHO

[Duplication]
With no other dependency than nfs-ganesha* it seems that this isn't a full
lib widely used yet.
It seemed more like a sibling or broken out of ganesha itself itself, but then
I found it has a changelog back to 2004 so it seems separate.
A bit of research later I realized this is in fact very old.

Orig: libtirpc => https://sourceforge.net/projects/libtirpc/
Fork: libntirpc => https://github.com/linuxbox2/ntirpc
Ganesha-special: libntirpc => https://github.com/nfs-ganesha/ntirpc

The main committer of the latter two seems to be the same person.
=> https://github.com/dang
So the middle one might be dead?

The problem here is that the "classic" tirpc is in main since forever (at
least precise, maybe even further).
It doesn't have many releases beign at v2.5 for years now.

But in terms of code-duplicity for things in main that is a problem.

The old lib still has plenty of dependencies so we can't just switch one for
the other.

$ reverse-depends -r focal src:libtirpc
Reverse-Depends
===============
* autofs                        (for libtirpc3)
* glusterfs-common              (for libtirpc3)
* glusterfs-server              (for libtirpc3)
* libassa-3.5-5-dev             (for libtirpc-dev)
* libgfapi0                     (for libtirpc3)
* libgfchangelog0               (for libtirpc3)
* libgfrpc0                     (for libtirpc3)
* libgfxdr0                     (for libtirpc3)
* libnis1                       (for libtirpc3)
* nfs-common                    (for libtirpc3)
* nfs-kernel-server             (for libtirpc3)
* quota                         (for libtirpc3)
* rpcbind                       (for libtirpc3)
* yp-tools                      (for libtirpc3)

Usually on such cases security isn't keen on maintaining both nor is Ubuntu
in general. I mean it even seems that nfs* packages use the classic tiprc lib.

I haven't tracked all the history and difference that has accrued between
those projects. But It seems that the differences might make maintaining
both valid. Without having everyone consider moving all the other projects
to the new lib or to find out why that isn't a good move either.

  Changes introduced in the ntirpc library include:
   * Bi-directional operation.
   * Full-duplex operation on the TCP (vc) transport.
   * Thread-safe operating modes:
     * new locking primitives and lock callouts (interface change).
     * stateless send/recv on the TCP transport (interface change).
   * Flexible server integration support.
   * Event channels.

This was also discussed in [1] and already back then it was "libntirpc has
diverged significantly from libtirpc; the changes are incompatible with
upstream libtirpc."

Therefore while it is sort of duplicating the functionality, we will need both
libs in main to get nfs-ganesha which is the driver of this.

[1]: https://pagure.io/packaging-committee/issue/363

[Embedded sources and static linking]
- no embedded source present
- no static linking

[Security]
Seems fine:
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- 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)

Security sensitive:
- does parse data formats
- does open a port (indirectly, but this libs code is used to plug RPC calls)
- history of CVEs
  Yes NTIRPC only has had one.
  But I'd think that any finding on TIRPC potentially affects, but isn't tracked
  against NTIRPC, as well.

This clearly needs a security review ...

[Common blockers]
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- no python considerations needed

There are a few tests, but they are not enabled yet.
You said in comment #6 that tests are functional or performance - but at
least rpcping could maybe be enabled?
It is already built in the buildlog.

openstack isn't yet subscribed to the package

[Packaging red flags]
- Ubuntu delta to be ahead?
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is (good/slow/sporadic)
- the current release is packaged
- no massive Lintian warnings
- d/rules is rather clean
- d/rules is rather clean
- not using Built-Using

@Openstack Team:
- I'm glad you did the uploads of the new version. But given the slow/sporadic
  Debian maintenance I wanted to check if you are willing and ok to sort of
  maintain this on your own?

[Upstream red flags]
- no incautious use of malloc/sprintf
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
  There are a few upstream, but none clear to the point what would need to
  be fixed
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks

But:
- Errors/warnings during the build are present
  This should bre resolved either by getting the symbols back if it is a
configuration issue or by bumping the symbols files.

dpkg-gensymbols: warning: some libraries disappeared in the symbols file: libntirpc_tracepoints.so.3.0
dpkg-gensymbols: warning: debian/libntirpc3.0/DEBIAN/symbols doesn't match completely debian/libntirpc3.0.symbols
--- debian/libntirpc3.0.symbols (libntirpc3.0_3.0-0ubuntu1_amd64)
+++ dpkg-gensymbolsAbfBAJ	2019-12-10 09:44:43.362589355 +0000
@@ -183,6 +183,3 @@
  xdr_void@NTIRPC_3.0 3.0
  xdr_wrapstring@NTIRPC_3.0 3.0
  xdrmem_ncreate@NTIRPC_3.0 3.0
-libntirpc_tracepoints.so.3.0 libntirpc3.0 #MINVER#
- __tracepoint_provider_rpcping@Base 3.0
- __tracepoint_provider_xprt@Base 3.0
   dh_shlibdeps -O--parallel -O--buildsystem=cmake
   dh_installdeb -O--parallel -O--buildsystem=cmake
   dh_gencontrol -O--parallel -O--buildsystem=cmake
   dh_md5sums -O--parallel -O--buildsystem=cmake
   dh_builddeb -O--parallel -O--buildsystem=cmake