[MIR] zeromq3 as dependency of mailman3

[Christian Ehrhardt ]

[Availability]
zeromq3 exists in Universe already. Current version in disco is 4.2.5-2 and it
builds in amd64, arm64, armhf, i386, ppc64el, s390x.

It produces two binary packages: a library runtime, and its corresponding
development package. We need the runtime libzmq5 in main.

Disco proposed has had 4.3.1-3 for 45 days and it hasn't migrated because it's
failing to build due to a failing test. UPDATE: fixed in 4.3.1-3ubuntu2, which migrated.

[Rationale]
This is part of the MIR activity for all dependencies of mailman3
The "main" MIR of it is at bug 1775427:

Mailman (2) has only python2 support, but we strive for python3,
therefore Mailman3 which has python3 support should be promoted to main.

Please do note that there were former MIRs in:
- bug 1597436
- bug 1597439
The latter being accepted.
It seems to have been demoted since then, we need to check why but hopefully this easens the re-promotion.

[Security]
CVE history:
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6250
  A pointer overflow, with code execution, was discovered in ZeroMQ libzmq (aka
  0MQ) 4.2.x and 4.3.x before 4.3.1. A v2_decoder.cpp
  zmq::v2_decoder_t::size_ready integer overflow allows an authenticated attacker
  to overwrite an arbitrary amount of bytes beyond the bounds of a buffer, which
  can be leveraged to run arbitrary code on the target system. The memory layout
  allows the attacker to inject OS commands into a data structure located
  immediately after the problematic buffer (i.e., it is not necessary to use a
  typical buffer-overflow exploitation technique that changes the flow of
  control).
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7938
  The ZeroMQ parser in tcpdump before 4.9.0 has an integer overflow in
  print-zeromq.c:zmtp1_print_frame().
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7203
  libzmq (aka ZeroMQ/C++) 4.0.x before 4.0.5 does not ensure that nonces are
  unique, which allows man-in-the-middle attackers to conduct replay attacks via
  unspecified vectors.
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7202
  stream_engine.cpp in libzmq (aka ZeroMQ/C++)) 4.0.5 before 4.0.5 allows
  man-in-the-middle attackers to conduct downgrade attacks via a crafted
  connection request.

Ubuntu CVE tracker at
http://people.ubuntu.com/~ubuntu-security/cve/universe.html:
- lists https://people.canonical.com/~ubuntu-security/cve/CVE-2019-6250 as
  still open in disco
- debian: https://security-tracker.debian.org/tracker/CVE-2019-6250
- upstream (patch and exploit): https://github.com/zeromq/libzmq/issues/3351

[Quality assurance]

As part of the mailman3 stacks as of now (Disco) this installs fine and works fine.
On itself it is useful to (many) other dependencies and does not need a post install configuration on its own.

No debconf questions asked, it's just a library package.

It's currently stuck in disco-proposed migration due to a build (test,
actually) failure:
http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zeromq3

Ubuntu bugs:
- one open bug from 2016: https://bugs.launchpad.net/ubuntu/+source/zeromq3/+bug/1602900
  libzmq3 crashes when 'getifaddrs()' is unavailable
  Fixed upstream in 4.2.0, which leaves only xenial and older without a fix.
- remaining open CVE in disco (see previous section)

Debian bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=zeromq3
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814346
  libzmq5: Wrong dependency?
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896711
  zeromq3: please package curve_keygen utility
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743508
  libzmq3: upgrading from 3.2.3 to 4.0.4 breaks python-pytango

Upstream issues: https://github.com/zeromq/libzmq/issues
- 138 open, >1k closed
- self-labeled critical bugs (6): https://github.com/zeromq/libzmq/labels/Critical
  - half from 2018, the rest is older

Upstream has CI:
- https://travis-ci.org/zeromq/libzmq (currently failing)
- https://ci.appveyor.com/project/zeromq/libzmq (currently failing)
- https://coveralls.io/github/zeromq/libzmq?branch=master (coverage at 81%)

Debian PTS: https://tracker.debian.org/pkg/zeromq3
- seems to get frequent uploads

Misc observations
- building 4.3.1-3 locally (where the tests pass) shows that new symbols are
  being introduced in this update, but not reflected in the symbols file.
  - http://paste.ubuntu.com/p/HYGDwJfv5g/ search for gensymbols
- active development community
  - dev mailing list: https://lists.zeromq.org/pipermail/zeromq-dev/
  - frequent commits: https://github.com/zeromq/libzmq/commits/master
- mismatched majors between dev and runtime library packages:
  - libzmq3-dev
  - libzmq5

No exotic hardware involved in this package.

Tests
- no DEP8 tests
- test suite run at package build time, with a "nocheck" check in
  DEB_BUILD_OPTIONS
- failure in the test suite actually fails the build, as can be seen in the
  failed migration in disco-proposed

The package includes a working debian/watch file.

Lintian
Full output: https://pastebin.ubuntu.com/p/bFS3FSYPqv/
I'd highlight:
- d/copyright needs updating (wildcard-matches-nothing-in-dep5-copyright)
- testsuite-autopkgtest-missing
- hardening-no-bindnow
- symbols file probably will need updating (if the package migrates away from
  disco-proposed)

No reliance on obsolete or orphaned packages.

[UI standards]
N/A, since this is a library.

[Dependencies]

Some dependencies are not in main, but we drive MIR for all related packages
that are not in main at the same time.
Please check the list of bugs from the main Mailman3 MIR in bug 1775427 to get an overview.

[Standards compliance]
No FHS violations.

d/control declares somewhat current standards version 4.3.0

Just found the mismatch between dev and runtime major versions in the package
name a bit odd.

Source package is trivial to maintain, d/rules uses debheloer and is easy to
understand

[Maintenance]

The Server team will subscribe for the package for maintenance

[Background]
None at this time.

[Christian Ehrhardt  (paelzer)]

Not yet subscribing the MIR Team until the FTBFS is fixed and it was clarified why it was demoted since the former MIR.

[Andreas Hasenack (ahasenack)]

FTBFS is fixed.

[Christian Ehrhardt  (paelzer)]

Thanks Andreas, also I now have taken a look at the demotion.
The only reason to demote is was that the need from unity to pull it in went away.
There was no explicit demotion reason filed.

Therefore we can piggy-back on the old MIR and can close this one as dup.