[Summary]
MIR team ack from a packaging POV
But there are a bunch of TODOs for the Openstack Team that could improve the
package before being promoted while it is in the security review queue.

@Security - this needs a review for sure, assigning you

@Openstack
- you are not yet subscribed to the packages, that has to be done before
  promotion
- as you reported tests are not run at build or autopkgtest time
  - there is src/test and gtest maybe any of them can be made to work
  - could you spend a bit of time trying to enable those and only leave them
    disabled if it is really hard?
  - if above doesn't work since you do that for openstack, could you add it to
    the regular openstack tests that you do?
    That would be outside of the package but at least be some regular re-check.
- could you please check if
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889654
  is fixed on the new version?
- since upstream looks rather bad [1]
  - have you experimentally verified that the usage for ceph not only works
    but also survives e.g. some stress testing?
    Everyone would hate to realize late that this is worse than one thought.
    E.g. these are ceph (but fortunately on too old versions):
    https://github.com/nfs-ganesha/nfs-ganesha/issues/433
    https://github.com/nfs-ganesha/nfs-ganesha/issues/388
    Maybe go through the bugs in this report and verify if any of them is
    a problem for the intended setup in that will be in main
- Even if you only seed the ceph package the source will get into main
  And auto-includes will add -doc , -dbg and -dev packages
  This has a -doc and I'd recommend to add an extra-exclude for the -doc
  package to not pull that and dependencies then.
  You can add that right now already.

[1]: https://github.com/nfs-ganesha/nfs-ganesha/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+crash

[Duplication]
Well, we have NFS kernel server but the intended use case here is to couple
this with different backends - primarily ceph at the moment.
I see no duplication in the archive that would do that.

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

[Security]
- no history of CVEs
- 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)

But it has quite some security sensitive elements:
- does not run a daemon as root
- does not parse data formats
- does not open a port
- access to all data passed in between

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

- It has deficiencies at self-tests on build/autopkgtest time.
- atm lacks a bug subscriber

[Packaging red flags]
- Ubuntu does carry a delta, but that is to get issues fixed
  Thanks for v3.0 and the fixups
  Have you tried to bring that to Debian to reduce the maintenance
  effort long time?
- symbols tracking not applicable for this code.
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is ok, but somewhat slow slow
  Thanks for jumping in and bringing it to 3.0
- the current release is packaged
- no MOTU problem
- no massive Lintian warnings
- d/rules is rather clean except a long list of extra example files
- not using Built-Using
- no golang package for extra considerations about that

[Upstream red flags]
- no Errors during the build
  It has some gcc warnings and sadly doesn't use -Werror,
  but sort of ok I guess
- no incautious use of malloc/sprintf (not that I've seen, but with that
  size I rely on the scan tools security uses
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- use of user nobody, but it is for NFS purpose which is exactly
  what it should be for
- no use of setuid
- not many important open bugs (crashers, etc) in Debian or Ubuntu
  - one might need to check this crash bug
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889654
  - also upstream isn't s clean as one would want it, see [1]
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks