[MIR] libmd (dependency of libbsd)

[Matthias Klose]

[Availability]
libmd has been on Universe since Xenial and builds on all supported archs. Hirsute currently has 1.0.3-3.

[Rationale]
libbsb has a new dependency on libmd since 0.11.1-1 (0.10 or earlier didn't)
- libbsd0 depends on libmd0
- libbsd build-depends on libmd-dev

[Security]
- found no CVEs related to libmd on Mitre, Openwall, and Ubuntu CVE tracker (main, universe, and tracker).
- no suid binaries on libmd0
- package provides no service files
- package does not require network (no open ports)

[Quality assurance]
- libmd0 1.0.3-3 depends only on libc6 (ie. no weird deps)
- libmd 1.0.3-3 build depends only on debhelper-compat
- no bug has ever been logged for libmd in both launchpad[1] and debian[2]
- homepage lists no upstream bug tracker [3]
- upstream maintainer is Guillem Jover
- package ships with a testsuite
- testsuite does not need network nor weird hardware
- testsuite is run during build
- has autopkgtests [4]
- autopkgtest fails on i386 (not a blocker)
- autopkgtest succeeded on amd64, ppc64el, s390x
- package has a debian/watch file
- 'lintian --pedantic' indicates no packaging issues

[Dependencies]
- libmd0 1.0.3-3 depends: libc6
- libmd 1.0.3-3 build-depends: debhelper-compat

[Standards compliance]
Package meets Debian Policy 4.5.1 (latest as of 2021-02-09).
Package meets FHS.

[Maintenance]
Package is small and well maintained in Debian by it's upstream main developer (Guillem Jover).

[Background information]
Package description is correct and succint:
'The libmd library provides various
 message digest ("hash") functions,
 as found on various BSDs on a
 library with the same name and with a
 compatible API.'

[References]
[1] https://bugs.launchpad.net/ubuntu/+source/libmd/+bugs?search=Search&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.tags_combinator=ANY&field.status_upstream-empty-marker=1

[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=libmd
[3] https://www.hadrons.org/software/libmd/
[4] https://autopkgtest.ubuntu.com/packages/libmd

[tdaitx 2021-02-09]
I confirm that I checked the above requirements carefully.

[Christian Ehrhardt  (paelzer)]

From MIR Meeting, this isn't ready yet.

[16:42] <cpaelzer> mclemenceau: or doko: would you make this into a proper state and set it back to new then?

[Christian Ehrhardt  (paelzer)]

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 i...

[Christian Ehrhardt  (paelzer)]

Matt agreed to Foundations owning it and subscribed foundations.
Next is Ubuntu security which I assigned this to

[Steve Beattie (sbeattie)]

I reviewed libmd 1.0.3-3build1 as checked into hirsute. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

libmd is a small library of message digest aka hash functions.

- No CVE history.
- No non-essential build-depends.
- No pre/post inst/rm scripts, only a trigger to run ldconfig due to it
  being a shared library.
- No init scripts.
- No systemd units.
- No dbus services?
- No setuid binaries.
- No binaries in PATH.
- No sudo fragments.
- No polkit files.
- No udev rules.
- There are simple unit tests for each of the hashing algorithms that
  are run as part of the build. One limitation of the tests is that all
  the testcases hash trivially small amounts of data, so multiple
  block computations are not exercised, as well as none of the
  file hashing interfaces. Upstream has added gitlab ci integration
  support after the 1.0.3 release.
- No cron jobs.
- Build logs are clean, with the exception that the
  unit test compilations throw a bunch of signedness
  mismatch warnings (const char * versus const unsigned
  char *). These look to have been fixed upstream in
  https://git.hadrons.org/cgit/libmd.git/commit/?id=e50a6db8ec1425e8354ece5ce45ac6cb2d2dcb3b

- No processes spawned.
- Memory management is par for the course for crypto/hashing
  algorithms. Return values for malloc() are checked, but lots of
  memory operations relying on correctness of computed sizes.
- The only File IO is opening file or file chunks in read-only mode to
  compute the message digest of its contents. Paths are assumed to have
  been sanitized by the calling application. No interpretation of the
  contents is performed.
- No logging appears to be performed.
- No environment variable usage present.
- No use of privileged functions.
- No use of outside cryptography / random number sources etc. As a
  hashing library it implements several algorithms itself.
- No use of temp files.
- No use of networking.
- No use of WebKit.
- No use of PolicyKit.

- No cppcheck or Coverity issues found.

There is a bunch of duplicated code in the helper functions around file
handling that only differs in the specific message digest algorithm
used. This means that bugs/flaws in that portion of the code will need
to be applied to all, rather than just once in an abstracted set of
functions.

Security team ACK for promoting libmd to main.

[Christian Ehrhardt  (paelzer)]

Thanks Steve for the quick review, since this shows up in mismatches already I'll set it to Fix Committed for an AA to pick it up and promote it.

[Matthias Klose (doko)]

Override component to main
libmd 1.0.3-3build1 in hirsute: universe/misc -> main
libmd-dev 1.0.3-3build1 in hirsute amd64: universe/libdevel/optional/100% -> main
libmd-dev 1.0.3-3build1 in hirsute arm64: universe/libdevel/optional/100% -> main
libmd-dev 1.0.3-3build1 in hirsute armhf: universe/libdevel/optional/100% -> main
libmd-dev 1.0.3-3build1 in hirsute i386: universe/libdevel/optional/100% -> main
libmd-dev 1.0.3-3build1 in hirsute ppc64el: universe/libdevel/optional/100% -> main
libmd-dev 1.0.3-3build1 in hirsute riscv64: universe/libdevel/optional/100% -> main
libmd-dev 1.0.3-3build1 in hirsute s390x: universe/libdevel/optional/100% -> main
libmd0 1.0.3-3build1 in hirsute amd64: universe/libs/optional/100% -> main
libmd0 1.0.3-3build1 in hirsute arm64: universe/libs/optional/100% -> main
libmd0 1.0.3-3build1 in hirsute armhf: universe/libs/optional/100% -> main
libmd0 1.0.3-3build1 in hirsute i386: universe/libs/optional/100% -> main
libmd0 1.0.3-3build1 in hirsute ppc64el: universe/libs/optional/100% -> main
libmd0 1.0.3-3build1 in hirsute riscv64: universe/libs/optional/100% -> main
libmd0 1.0.3-3build1 in hirsute s390x: universe/libs/optional/100% -> main
15 publications overridden.