Review for Package: python-xmltodict

[Summary]
Other than the initial potential duplication this package is small and easy
and should be not hard to maintain.

MIR team ACK

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

List of specific binary packages to be promoted to main: python3-xmltodict
Specific binary packages built, but NOT to be promoted to main: <none>

[Duplication]
There has been a former Nack and a check, but the conclusion was that none
of the alternatives is really usable for this use-case, therefore:
=> There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- 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 embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- 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)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems:
- does parse data formats from an untrusted source.
  Ceilometer could be attacked throwing crafted data at it if there is a
  weakness in this code. I think this lib is small and a review should be quick,
  but it is worthwhile before adding it to the monitoring of all your instances.

[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.
- This does not need special HW for build or test
- no new python2 dependency
- Python package, but using dh_python
- Go package, but using dh-golang

Problems:
- Does not have a non-trivial test suite that runs as autopkgtest
  Given what the lib does and how the dependencies look like the only realistic
  case of changing dependencies causing issues would be changing python
  itself. That will need a no-change rebuild anyway and this would be covered
  by the build time tests which are present.
  So while it would be nice to have autopkgtests I think it is ok here to not
  have them.

[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
- Debian/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 (usually a sync, no MOTU changes so far)
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (the language has no direct MM)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
  tests)
- 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-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (internal lib)?

Problems: None