[Summary]
MIR ack, with 2 notes below.

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


Two notes that do not need to block MIR:
1. As upstream has released v0.7.0 (over 1 month ago), Debian
   should update to that version sometime soon, and try to stay up to
   date with upstream.
2. It would be good to create a simple autopkgtest that just runs the
   build tests.

[Duplication]
OK:
- There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - does have build deps in universe, but all binary deps in main
- no -dev/-debug/-doc packages that need exclusion

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

[Security]
OK:
- history of CVEs does not look concerning
  - only 1 CVE with very quick upstream resolution
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- 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)

Problems:
- does parse data formats
  - the purpose of the package is to provide a python lib to perform
    signing and encryption on Javascript objects

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error (verified by forcing failure in a test)
- The package has a team bug subscriber (Openstack team)
- no translation present, but none needed for this case (not user visible)
- no new python2 dependency
- Python package that is using dh-python
- not Go package

Problems:
- does not have a test suite that runs as autopkgtest
  - running the build tests in an autopkgtest would be ideal, but I do not think is
    required, as there is only 1 binary dep that would cause reverse-depends
    autopkgtest run.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is good
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
  - N/A, since there are no Ubuntu changes
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using
- not Go Package

Problems:
- Debian update history is sporadic
  - Debian updates in the past have skipped upstream releases, e.g.
    changelog shows no Debian update between v0.4.2 and v0.6.0
  - However, current Debian code is relatively recent, though it
    would be good for Debian to move up to v0.7.0 which was released
    upstream last month
  - I do not think this should block MIR (see next item)
- the current release is not packaged
  - as noted above, current upstream release is v0.7.0, which was recently
    released (Feb 19, 2020); Debian is up to date with the previous
    release, v0.6.0.
  - There are only 19 changes between v0.6.0 and v0.7.0 upstream, and
    most of them are trivial fixes.  So, since v0.7.0 was released quite
    recently, and the changes are mostly minor, I don't think upgrading
    to v0.7.0 is a requirement for MIR, but it would be good to see
    Debian upgrade to v0.7.0 soon.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- 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
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks