MIR Team ack under the constraint that Foundations want to own it AND
security also approved it.
This does need a security review, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: libmd0

Required TODOs:
- based on deps subscriber should be foundations, but I'd need foundations
  to say that they are ok with that.
  @Matt - I'm assigning to you so you can make that call. If you agree
  subscribe Foundations-bugs (or at least confirm that you will do so
  eventually) - once done please assign ubuntu-security who is the next
  team that has to look at this.


[Duplication]
This is a tricky topic, as what the lib provides is "md2/md4/md5/RIPE/SHA-1/
SHA-2". That is in main via libcrypto of openssl.
But there are licensing issues with openssl
https://people.gnome.org/~markmc/openssl-and-the-gpl.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937 (and many similar)
Therefore it is no surprise that people are looking for less issues, and this
is oen such case.
Furthermore this isn't "new" instead it is replacing existing code with
something better. Until this change we had these function as as embedded code
in libbsd in main. Having it in a properly separated library is better than
that. So we change libbsd's reimplementation for one that is meant to focus
on just that - that should be better.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
  libmd-dev has no crazy deps and can be auto-included without problems.

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

[Security]
OK:
- history of CVEs does not look concerning (none)
- 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
  And we know there have been CVEs with other hash function implementations in
  the past - so a security review is needed.

[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.
- does have a test suite that runs as autopkgtest (the same as build time)
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider in that regard
- no new python2 dependency

Problems:
- The package has no team bug subscriber yet, given that it comes from libbsd
  that would be foundations. But the subscription doesn't exist yet and needs
  to be done or at least confirmed that it is ok to be done on promotion.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is slow but ok (stable)
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build (a few warnigns are present, but
  they are all only in the unit-test code)
- 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 or Upstream
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks