[MIR]: dependency of bind9

[Andreas Hasenack]

== MIR for libmaxminddb bug task ==
(for the python-geoip2 bug task, please see https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/17)
(for the python-maxminddb bug task MIR, see https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/26)

Availability:
The package is in universe and builds for amd64 arm64 armhf i386 ppc64el s390x
https://launchpad.net/ubuntu/+source/libmaxminddb/1.3.2-1

Rationale:
The package is a build dependency of the new bind9 9.16.x codebase.
Upstream (maxminddb) deprecated the old libgeoip1 library which is what bind9 9.11.x used, and was used with bind9 up to 9.15.1
Not building bind9 9.16.x with this support means a regression in bind9 when compared with previous ubuntu releases.
This will also reduce our delta with debian, since they enable geoip2.
See https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1866875
See https://ftp.isc.org/isc/bind9/cur/9.16/CHANGES and look for the "5262" entry
See https://downloads.isc.org/isc/bind9/9.15.2/RELEASE-NOTES-bind-9.15.2.html (which wasn't clear that geoip1 was removed, just that geoip2 was added)

Security:
* http://cve.mitre.org/cve/search_cve_list.html: Search in the National Vulnerability Database using the package as a keyword
- no hits for "maxmind", "maxminddb", "libmaxminddb" other than a javascript implementation of this api

* check OSS security mailing list (feed 'site:www.openwall.com/lists/oss-security <pkgname>' into search engine)
- a search for "maxmind" returned https://www.openwall.com/lists/oss-security/2011/05/20/4 which is a CVE on the legacy version of this library. Other searches returned empty results.

Ubuntu CVE Tracker
* http://people.ubuntu.com/~ubuntu-security/cve/main.html
- no hits

* http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- no hits

* http://people.ubuntu.com/~ubuntu-security/cve/partner.html
- no hits

* Check for security relevant binaries. If any are present, this requires a more in-depth security review.
- The packages provide just two binaries: the library (static and dynamic), and one tool used for queries.

* Executables which have the suid or sgid bit set.
- none

 * Executables in /sbin, /usr/sbin.
- none

* Packages which install services / daemons (/etc/init.d/*, /etc/init/*, /lib/systemd/system/*)
- none

* Packages which open privileged ports (ports < 1024).
- none

* Add-ons and plugins to security-sensitive software (filters, scanners, UI skins, etc)
- this can optionally be used by bind9 in ACLs
Including bind9 in the CVE list, I found this old one which was related to the legacy geoip library:
https://www.cvedetails.com/cve/CVE-2014-8680/. This wasn't a vulnerability in the library itself, though, but in bind.

Quality assurance:
* After installing the package it must be possible to make it working with a reasonable effort of configuration and documentation reading.
- it's a library, used by other packages, so the configuration details will vary in complexity. For bind9, for example, there is https://kb.isc.org/docs/aa-01149

* The package must not ask debconf questions higher than medium if it is going to be installed by default. The debconf questions must have reasonable defaults.
- no debconf questions

* There are no long-term outstanding bugs which affect the usability of the program to a major degree. To support a package, we must be reasonably convinced that upstream supports and cares for the package.
- there are no open bugs in ubuntu besides the MIR (https://bugs.launchpad.net/ubuntu/+source/libmaxminddb)
- there are no open bugs in debian: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=libmaxminddb
- very few bugs open upstream: https://github.com/maxmind/libmaxminddb/issues
  - most tagged with "enhancement"
  - closed bugs list shows more activity: https://github.com/maxmind/libmaxminddb/issues?q=is%3Aissue+is%3Aclosed
- debian tracker: https://tracker.debian.org/pkg/libmaxminddb
  - there doesn't seem to be much activity
  - there is a warning about cflags in the build logs, something we could fix
  - same for multiarch warnings
  - standards version can be updated
  - new upstream version available (1.4.2), not updated in debian. Perhaps because 1.4.0 and 1.4.1 are tagged with "DO NOT USE" by upstream (see https://github.com/maxmind/libmaxminddb/releases)

* The package should not deal with exotic hardware which we cannot support.
- no exotic hardware

* If the package ships a test suite, and there is no obvious reason why it cannot work during build (e. g. it needs root privileges or network access), it should be run during package build, and a failing test suite should fail the build.
- moure than a thousand tests are run at build time

* The package uses a debian/watch file whenever possible. In cases where this is not possible (e. g. native packages), the package should either provide a debian/README.source file or a debian/watch file (with comments only) providing clear instructions on how to generate the source tar file.
- there is a working d/watch file:
 uscan
uscan: Newest version of libmaxminddb on remote site is 1.4.2, local version is 1.3.2
uscan: => Newer package available from
      https://github.com/maxmind/libmaxminddb/releases/download/1.4.2/libmaxminddb-1.4.2.tar.gz
Successfully symlinked ../libmaxminddb-1.4.2.tar.gz to ../libmaxminddb_1.4.2.orig.tar.gz.

* It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance
$ lintian -I --pedantic
E: libmaxminddb changes: bad-distribution-in-changes-file unstable
W: libmaxminddb source: incomplete-creative-commons-license cc-by-sa (paragraph at line 9)
W: libmaxminddb source: tab-in-license-text debian/copyright (paragraph at line 58)
I: libmaxminddb0: hardening-no-bindnow usr/lib/x86_64-linux-gnu/libmaxminddb.so.0.0.7
I: libmaxminddb source: testsuite-autopkgtest-missing
P: libmaxminddb-dev: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
P: libmaxminddb0: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
P: mmdb-bin: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
P: libmaxminddb source: file-contains-trailing-whitespace debian/control (line 67)
P: libmaxminddb source: insecure-copyright-format-uri http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
P: libmaxminddb source: package-uses-old-debhelper-compat-version 10
P: libmaxminddb source: rules-requires-root-missing

Of the above, we can probably easily fix hardening-no-bindnow and debhelper compat version. I'm not sure about DEP8 tests, as they might need network access.

* The package should not rely on obsolete or about to be demoted packages. That currently includes package dependencies on Python2 (without providing Python3 packages), and packages depending on GTK2.
- I didn't spot any such reliance on old or obsolete packages.

Dependencies:
* All binary dependencies (including Recommends:) must be satisfiable in main (i. e. the preferred alternative must be in main). If not, these dependencies need a separate MIR report (this can be a separate bug or another task on the main MIR bug)
- runtime dependencies of libmaxminddb0:
  - Depends: libc6 (>= 2.14), Suggests: mmdb-bin
- runtime dependencies of libmaxmibddb-dev:
  - Depends: libmaxminddb0 (= 1.3.2-1)
- runtime dependencies of mmdb-bin:
  - Depends: libc6 (>= 2.17), libmaxminddb0 (>= 1.0.2)
- build-dependencies include packages from universe, but these are used for running the tests:
  $ check-mir
  Checking support status of build dependencies...
   * libipc-run3-perl binary and source package is in universe
   * libtest-output-perl binary and source package is in universe

Standards compliance: The package should meet the FHS and Debian Policy standards. Major violations should be documented and justified. Also, the source packaging should be reasonably easy to understand and maintain.
- Old Standards-Version: 4.1.4 from april 2018 (current is 4.5.0.0 from 2020-01-20)
- d/rules is small and easy to maintain
- package uses debhelper, could just use an update in the dh level
- I don't see any complications in the source package

Maintenance: The package must have an acceptable level of maintenance corresponding to its complexity:
* All packages must have a designated "owning" team, regardless of complexity, which is set as a package bug contact.
- server team will own this package

* Simple packages (e.g. language bindings, simple Perl modules, small command-line programs, etc.) might not need very much maintenance effort, and if they are maintained well in Debian we can just keep them synced
- single library, with the usual runtime, -dev, and one binary tool packages
- this package is already a sync from debian

Background information:
* The package descriptions should explain the general purpose and context of the package. Additional explanations/justifications should be done in the MIR report.
- the descriptions in d/control are good

[Andreas Hasenack (ahasenack)]

I did a quick check on the libgeoip1 rdeps, and found just two that are in main:
bin: python3-geoip (from src: python-geoip)
bin: libnginx-mod-http-geoip (from nginx)

Maybe we can even demote the legacy library to universe, I'll see what I can find.

[Andreas Hasenack (ahasenack)]

nginx has support for both geoip libraries:
Package: libnginx-mod-http-geoip2
Package: libnginx-mod-http-geoip

libnginx-mod-http-geoip is in main, libnginx-mod-http-geoip2 is in universe. If this MIR is approved, we could switch those and push -geoip to universe and bring -geoip2 into main.

[Andreas Hasenack (ahasenack)]

src:python-geoip (for legacy geoip) has the source in main
src:python-geoip2, for the current version, is in universe.

There are no main reverse-depends for python3-geoip:
$ reverse-depends python3-geoip
Reverse-Recommends
* deluge-common

Reverse-Depends
* python3-txtorcon

I see it in the ubuntu seeds, in the "development" file:
"""
Moved from desktop:

 * python3-apt # MRS, we need to be able to interact with APT
 * python3-crypto # MRS, very useful even though it's very specific
 * python3-examples # MRS,
 * python3-geoip
...
"""

I'm not sure what needs it. Maybe the desktop installer uses it? If not, we could then perhaps replace it with python3-geoip2, for the new library, or even get rid of this entirely. Then we would have only one geoip version/implementation in main: the new one.

[Christian Ehrhardt  (paelzer)]

Thanks Andreas that duplication check is exactly what I'd have done now.
I agree that given the conditions we should try to make a full switch.

For nginx that is a change in d/control for binary package: nginx-core.
Could you prep an MP, link it here and ask Teward to review it?

Yes, for python3-geoip
The history of this goes back to 2005 and it was never re-evaluated.
I think we can switch in the seeds to the newer implementation.
Could you open an MP for that as well please and link it here?
Please add a review slot for desktop-team and ping someone (as it is listed for them).
Also add a review slot for Steve, back in the day it seems cjwatson did the initial addition, but that seems more seed restructuring than anything.
Having those two agree would be great to go forward.

[Christian Ehrhardt  (paelzer)]

[Summary]
MIR Team ack under the following constraints/todos:

TODOs:
- yes we need to demote geoip and promote libmaxminddb in exchange for that
- needs work in seeds to change to the new lib
- needs work in nginx to change dependencies
- merge 1.4.2 from upstream to get a memory leak (and others) resolved
  Seems we need no rebuilds of all dependencies as they depend on much
  lower version.
- get the server team subscribed to libminmadddb

@Andreas I'll assign it to you to work on those, Please ping me to officially set to approved once things are ready.

[Duplication]
Yes this is a duplicate. Contenders are:
- src:geoip (in main atm)
- src:libmaxminddb (in universe atm)
But as outlined on this bug before we could ans should replace one with the
other for 20.04.

This is not a transition to something completely different. The
company/organization behind both projects is https://dev.maxmind.com/
and they clearly go for the newer version.

https://github.com/maxmind/geoip-api-c is called "Legacy" for a reason
and https://github.com/maxmind/libmaxminddb is newer in all regards.

Duplication isn't a problem as we will switch which of the two libs is in main.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- there is a -dev packages but we don't need to exclude as it doesn't have further dependencies into universe
- no direct dependencies on the CLI mmdb-bin, we will only promote binary libmaxminddb0

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

[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
- 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
  It parses an on disk geoip DB (under admin control) and gets strings or
  sockaddrs passed for lookup.
  Strictly speaking this would need a security review, but I realized it
  doesn't parse it on its own anyway, it directly passes e.g. the IP string to
  getaddrinfo of glibc.
  From there on it only works on a standard struct sockaddr_in* which I think
  is fine.

This is as close to not needed that even my usual "better safe than sorry"
doesn't trigger and I think we can ack this without explicit security review.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite (not just a fake, 4 digit number of test cases)
  that runs at build time
  - test suite fails will fail the build upon error.
- translation are present
- not a python package, no extra constraints to consider int hat regard

Problems:
- does not have a test suite that runs as autopkgtest
  But also not really depends on other things that would trigger anyway.
- no bug subscriber (yet) but it is clear that it will be the sever Team
  added it to TODOs

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking is in place
- d/watch is present and looks ok
- ...

[Andreas Hasenack (ahasenack)]

I grepped the ubiquity source code for geoip (case insensitive) and only came up with this;
$ grep -r -i geoip .
./debian/changelog: * If we think we're offline, don't try to contact geoip or run
./debian/changelog: * Support getting the timezone from a geoip server (LP: #229884).
./ubiquity/plugins/ubi-timezone.py: self.preseed('tzsetup/geoip_server', '')

The commit for the offline fix is https://git.launchpad.net/ubiquity/commit/?id=c1fba8cfbe046527f3f654a7810e6c5916e35483

The commit for the actual geoip support is https://git.launchpad.net/ubiquity/commit/?id=8ecf2a8b7db0a656690d3cb8f7f9beda66a149af

Further looking at ./ubiquity/plugins/ubi-timezone.py, it's clear we use a web service for these lookups, and not this geoip library we are talking about:

_geoname_url = 'https://geoname-lookup.ubuntu.com/?query=%s&release=%s'

[Andreas Hasenack (ahasenack)]

Added an nginx task to this bug for the work needed on that package. This is not about MIR nginx.

[Andreas Hasenack (ahasenack)]

For nginx, I'm unable to push to a new repo in lp at the moment[1], but the diff is simple:

commit 34f9c1428d2d4eeab01f04e92e54bf311fa859b8 (HEAD -> focal-nginx-geoip2-in-main)
Author: Andreas Hasenack <email address hidden>
Date: Wed Mar 11 10:35:00 2020 -0300

      * d/control: have nginx-core pull in the geoip2 package instead of
        geoip, which is legacy (LP: #1861101)

diff --git a/debian/control b/debian/control
index 4c107b0f..a125a245 100644
--- a/debian/control
+++ b/debian/control
@@ -68,7 +68,7 @@ Description: small, powerful, scalable web/proxy server - common files

 Package: nginx-core
 Architecture: any
-Depends: libnginx-mod-http-geoip (= ${binary:Version}),
+Depends: libnginx-mod-http-geoip2 (= ${binary:Version}),
          libnginx-mod-http-image-filter (= ${binary:Version}),
          libnginx-mod-http-xslt-filter (= ${binary:Version}),
          libnginx-mod-mail (= ${binary:Version}),

nginx-core is in main, and it's the metapackage that needs changing. The other packages which pull in libnginx-mod-http-geoip are nginx-full and nginx-extras, and both:
a) are in universe
b) pull in both geoip modules already (-geoip and -geoip2).

1. https://answers.launchpad.net/launchpad/+question/689269

[Joshua Powers (powersj)]

Ubuntu Server is now subscribed to the libmaxminddb package.

[Thomas Ward (teward)]

NACK on nginx until Security Team reviews.

Details in IRC, but long story short is libnginx-mod-http-geoip2 is NOT part of the nginx core code that is shipped from upstream (whereas libnginx-mod-http-geoip *is* built from upstream code and they have no intention to update it to geoip2 at the moment), and as such the libnginx-mod-http2-geoip2 code needs a Security Team review for MIR inclusion.

[Andreas Hasenack (ahasenack)]

How about we demote libnginx-mod-http-geoip to universe? Given:
- nginx upstream isn't interested in switching to geoip2 (libbaxminddb). So much that ubuntu went to great lengths to add a module to support it.
- nginx is relying on obsolete geoip1 library (maxmind, the upstream, calls it "legacy", but I have no idea for how long it will be supported)
- bind9 was calling geoip1 deprecated already in the 9.11 releases, and finally removed support for it in the new stable 9.16 release

Bind9 is the main reason for this change, but at the same time it feels like a good opportunity to move forward and demote legacy code.

The only reverse-depends of libnginx-mod-http-geoip are nginx packages themselves.

[Andreas Hasenack (ahasenack)]

I have a debdiff[1] from Teward to drop libnginx-mod-http-geoip from nginx-core, which would allow us to demote libnginx-mod-http-geoip to universe, and thus demote libgeoip(1) too. @cpaelzer, would that satisfy the requirements?

In the meantime I'll go ahead and prepare nginx packages with this diff and test them.

1. https://paste.ubuntu.com/p/4q3Bv9Sy53/

[Thomas Ward (teward)]

I've also uploaded the debdiff here in case paste.u.c erases the paste.

[Andreas Hasenack (ahasenack)]

Adding a task for release notes where we need to document the following upgrade scenario (and maybe others):

a) Since nginx-core dropped the dependency on libnginx-mod-http-geoip, an "apt autoremove" might suggest that libnginx-mod-http-geoip can be removed. If this happens, and there are still geoip configuration directives, nginx will fail to restart. Note that this would also happen had we replaced libnginx-mod-http-geoip with libnginx-mod-http-geoip2, as the configuration directives are different

b) If someone has just main enabled, with nginx-code and libnginx-mod-http-geoip installed, and release upgrades to focal, libnginx-mod-http-geoip won't be updated because it's in focal/universe.

[Steve Langasek (vorlon)]

In order to demote geoip1, we also need to demote python3-geoip, and the proposal is to trade it for python3-geoip2 instead (https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/380547). So that package should be included in this MIR.

[Andreas Hasenack (ahasenack)]

== MIR for python-geoip2 bug task ==

Availability:
The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on.
- the package is in universe and is an arch all package.

Rationale:
There are two main reasons for this MIR:
- python-geoip for the geoip1 format/code is deprecated upstream and considered legacy
- python3-geoip is in the development seed, and we should replace it with the non-legacy python3-geoip2 package
- "we have historically tended to seed python bindings for libraries we support as "development", on the grounds that python was a preferred language for developing on Ubuntu." (https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/380547/comments/998609)

Security
The security history and the current state of security issues in the package must allow us to support the package for at least 9 months (60 for LTS support) without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in the subsection Security checks.

Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package:

https://cve.mitre.org/cve/search_cve_list.html: Search in the National Vulnerability Database using the package as a keyword
- no hits for "maxmind", "maxminddb", "libmaxminddb" other than a javascript implementation of this api
- no hits for "geoip2"
- "geoip" (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=geoip) has several hits on other implementations or just users of the generic "geoip" feature, not tied to this library or python module, with one exception for the legacy version of the geoip library, not subject to this MIR, but from the same upstream publisher: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0159

check OSS security mailing list (feed 'site:www.openwall.com/lists/oss-security <pkgname>' into search engine)
- a search for "maxmind" returned https://www.openwall.com/lists/oss-security/2011/05/20/4 which is a CVE on the legacy version of the library, not on the python module. Other searches returned empty results.
- a search for "geoip2" returns no results
- a search for "geoip" returns 3 results (site:www.openwall.com/lists/oss-security geoip) all pointing to the same issue below:
  - https://www.openwall.com/lists/oss-security/2011/05/20/4 for CVE-2007-0159 and a follow-up CVE because of an incomplete fix in the legacy geoip library, not subject to this MIR, but from the same upstream source

Ubuntu CVE Tracker
http://people.ubuntu.com/~ubuntu-security/cve/main.html
- python-geoip2, geoip2, geoip, python3-geoip, python3-geoip2: no results

http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- python-geoip2, geoip2, geoip, python3-geoip, python3-geoip2: no results

http://people.ubuntu.com/~ubuntu-security/cve/partner.html
- python-geoip2, geoip2, geoip, python3-geoip, python3-geoip2: no results

Check for security relevant binaries. If any are present, this requires a more in-depth security review.

Executables which have the suid or sgid bit set.
- there are no binaries at all, just python module co...

[Christian Ehrhardt  (paelzer)]

> would that satisfy the requirements?
Yes pushing libnginx-mod-http-geoip out to full or extra would be ok as well.

@Andreas - for the release notes also add the "soltion" which is to use -extra or -full or directly install libnginx-mod-http-geoip2 or ibnginx-mod-http-geoip (old compat)

Thanks for adding python-geoip2 already, doing that review this morning ...

[Christian Ehrhardt  (paelzer)]

[Summary]
MIR team Ack, a very small and clean python lib.

Note: thanks @Andreas for the thorough pre-check once filing - I was able to
confirm all that more easily that way.

[Duplication]
There is another package in main providing the same functionality, but the
approach here is to trade one for the other. So that is fine.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- 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
- 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)

- does not parse data formats
  It mostly only passes from/to geoip C binding, not much handling in the
  package itself. OTOH it structures and presents the data it gets as an
  answer, but that as is a very controlled source.
  Due to that IMHO it doesn't require a security review.

[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 package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python package, no extra constraints to consider int hat regard
- no new python2 dependency
- Python package that is using dh_python

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- 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
  There is a 3.0 but it is rather new and has an incompatible change.
  I'd not vote to merge 3.0 now but would that come naturally later in >=20.10
- 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
- no incautious use of malloc/sprintf (python)
- 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

[Andreas Hasenack (ahasenack)]

nginx FFe bug for the demotion of libnginx-mod-http-geoip:

https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1867150

[Andreas Hasenack (ahasenack)]

- nginx was uploaded (https://launchpad.net/ubuntu/+source/nginx/1.17.9-0ubuntu2)
- libmaxminddb uploaded (https://launchpad.net/ubuntu/+source/libmaxminddb/1.4.2-0ubuntu1)
- seed change applied (https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/380547)

[Andreas Hasenack (ahasenack)]

I made a mistake in the python-geoip2 MIR[1]. This second statement is incorrect:
- dependencies are python3-maxminddb (>= 1.4.0), python3-requests, python3:any
- python3-maxminddb is a subject of this same MIR LP: #1861101 <--- FALSE

python3-maxminddb comes from src:python-maxminddb, not libmaxminddb.

1. https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/17

[Launchpad Janitor (janitor)]

This bug was fixed in the package nginx - 1.17.9-0ubuntu2

---------------
nginx (1.17.9-0ubuntu2) focal; urgency=medium

  * Drop GeoIP from nginx-core due to demotion of libgeoip (LP: #1861101,
    LP: #1867150):
    - d/control: Remove libnginx-mod-http-geoip from nginx-core dependency
    - d/rules: Remove the configure line of with-http_geoip_module=dynamic
      from the nginx-core build flags, due to demotion of libgeoip and the
      removal of the dynamic library from install deps for nginx-core.

 -- Thomas Ward <email address hidden> Wed, 11 Mar 2020 13:41:07 -0400

[Andreas Hasenack (ahasenack)]

libmaxminddb was uploaded and migrated, setting task to "fix released".

[Andreas Hasenack (ahasenack)]

But it's still in universe, so setting back to fix committed until promotion happens.

[Andreas Hasenack (ahasenack)]

python-maxminddb MIR request

Availability:
The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on.
- package is in universe: https://launchpad.net/ubuntu/+source/python-maxminddb
- package builds for amd64, arm64, armhf, ppc64el, s390x (i386 was dropped in the last upload, unknown at the moment if it has to be re-enabled for i386)

Rationale:
The package is a dependency of python-geoip2 which is to be promoted to main via MIR bug #1861101. See https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/17 for the application, and https://bugs.launchpad.net/ubuntu/+source/python-geoip2/+bug/1861101/comments/19 for the ACK

In general, we are demoting python-geoip (the legacy GeoIP1 support) and want to replace it with geoip2. The unseeding of python-geoip already happened in https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/380547/

Security
- zero advisories at https://github.com/maxmind/MaxMind-DB-Reader-python/security/advisories

* http://cve.mitre.org/cve/search_cve_list.html
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=maxmind returned a hit for a javascript implementation
- geoip2, maxminddb, python-maxminddb, MaxMind-DB-Reader-python (the upstream name): no hits

* check OSS security mailing list (feed 'site:www.openwall.com/lists/oss-security <pkgname>' into search engine)
- "site:www.openwall.com/lists/oss-security maxminddb": no results
- "site:www.openwall.com/lists/oss-security maxmind": one hit:
  - https://www.openwall.com/lists/oss-security/2011/05/20/4
  - related to CVE-2007-0159 which was about the geoip1 C API
- "site:www.openwall.com/lists/oss-security python-maxminddb": no results
- "site:www.openwall.com/lists/oss-security python-maxmind": just ads as results
- "site:www.openwall.com/lists/oss-security MaxMind-DB-Reader-python": no results
- "site:www.openwall.com/lists/oss-security geoip2": no results

* Ubuntu CVE Tracker
* http://people.ubuntu.com/~ubuntu-security/cve/main.html
- no hits for maxminddb, geoip2, geoip, maxmind

* http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- no hits for maxminddb, maxmind, geoip, geoip2

* http://people.ubuntu.com/~ubuntu-security/cve/partner.html
- has no packages or CVEs at all

* Check for security relevant binaries. If any are present, this requires a more in-depth security review.
- the source package builds two binary packages: python3-maxminddb and python-maxminddb-doc The following is about these two binary packages.
* Executables which have the suid or sgid bit set.
- none

* Executables in /sbin, /usr/sbin.
- none (since it's a python module and its documentation, there are no executables)

* Packages which install services / daemons (/etc/init.d/*, /etc/init/*, /lib/systemd/system/*)
- no services

* Packages which open privileged ports (ports < 1024).
- none

* Add-ons and plugins to security-sensitive software (filters, scanners, UI skins, etc)
- being a python module, it is meant to be used by other software. The current list of reverse-depends contains just one package and that is python3-geoip2 (src:python-geoip2). That package in turn is a dependenc...

[Christian Ehrhardt  (paelzer)]

[Summary]
MIR team Ack, a very small and clean python lib.
But this one has a few todos we need to resolve before/after promotion:

TODO ASAP:
- For 20.04 we really should consider going ahead to the much newer 1.5.2
  => https://github.com/maxmind/MaxMind-DB-Reader-python/releases
  @andreas will you take a look at this, just as you did with the other
  related package that was slightly outdated?
- ask Josh to subscribe server-team to this pkg as well

TODO long-term:
- I'd wonder if we can get a security review (on all of these) in the long
  run but not gating the MIR for now - details below?
- Debian updates a bit slowly, we might need to do the monitoring and
  updating on this one - @Andreas is that ok for you to do that
  along e.g. bind9 merges?

[Duplication]
While python3-geoip2 was for the API this package python-maxminddb is a
python interface for reading the MaxMind DB. I don't see a package in
main doing that already. No duplication issue.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
  - doc depends only on libjs-sphinxdoc which is in main already

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

[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
- 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 parse data formats
  There are two ways it can operate. It can either do the processing in its
  python code or has a C extension - but that extension only is a shim to pass
  to the libmaxminddb0 code.
  That way - as with the other packages in this context it does fairly minimal
  things and has despite its age no CVE history at all.

I have revisited the parsing in all the packages int his MIR, I still think
it is fairly minimal and does not need a "gating security review".
But on the long run - once the 20.04 dust settles - it might be good to have
one eventually. @Andreas could you after resolving this ask security if they
could do an informal security review on the packages in this MIR?

[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.
  seem good enough for this package
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python package, no extra constraints to consider int hat regard
- no new python2 dependency
- Python package that is using dh_python

Problem:
- does not have a test suite that runs as autopkgtest, but the build time
  tests (171) seem enough for this Packages content

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- 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 not ...

[Andreas Hasenack (ahasenack)]

> - For 20.04 we really should consider going ahead to the much newer 1.5.2
> => https://github.com/maxmind/MaxMind-DB-Reader-python/releases
> @andreas will you take a look at this, just as you did with the other
> related package that was slightly outdated?

FFe bug for the update: https://bugs.launchpad.net/ubuntu/+source/python-maxminddb/+bug/1867919

> - I'd wonder if we can get a security review (on all of these) in the long
> run but not gating the MIR for now - details below?

Carded https://trello.com/c/uUivNu65

> - Debian updates a bit slowly, we might need to do the monitoring and
> updating on this one - @Andreas is that ok for you to do that
> along e.g. bind9 merges?

I subscribed to the debian package tracker for these packages: python-maxminddb, libmaxminddb0, python-geoip2

I subscribed to upstream announce mailing lists or equivalent for these projects: python-maxminddb (via github releases), libmaxminddb (via github releases), python-geoip2 (via github releases).

[Matthias Klose (doko)]

Override component to main
libmaxminddb 1.4.2-0ubuntu1 in focal: universe/misc -> main
libmaxminddb-dev 1.4.2-0ubuntu1 in focal amd64: universe/libdevel/optional/100% -> main
libmaxminddb-dev 1.4.2-0ubuntu1 in focal arm64: universe/libdevel/optional/100% -> main
libmaxminddb-dev 1.4.2-0ubuntu1 in focal armhf: universe/libdevel/optional/100% -> main
libmaxminddb-dev 1.4.2-0ubuntu1 in focal i386: universe/libdevel/optional/100% -> main
libmaxminddb-dev 1.4.2-0ubuntu1 in focal ppc64el: universe/libdevel/optional/100% -> main
libmaxminddb-dev 1.4.2-0ubuntu1 in focal s390x: universe/libdevel/optional/100% -> main
libmaxminddb0 1.4.2-0ubuntu1 in focal amd64: universe/libs/optional/100% -> main
libmaxminddb0 1.4.2-0ubuntu1 in focal arm64: universe/libs/optional/100% -> main
libmaxminddb0 1.4.2-0ubuntu1 in focal armhf: universe/libs/optional/100% -> main
libmaxminddb0 1.4.2-0ubuntu1 in focal i386: universe/libs/optional/100% -> main
libmaxminddb0 1.4.2-0ubuntu1 in focal ppc64el: universe/libs/optional/100% -> main
libmaxminddb0 1.4.2-0ubuntu1 in focal s390x: universe/libs/optional/100% -> main
mmdb-bin 1.4.2-0ubuntu1 in focal amd64: universe/net/optional/100% -> main
mmdb-bin 1.4.2-0ubuntu1 in focal arm64: universe/net/optional/100% -> main
mmdb-bin 1.4.2-0ubuntu1 in focal armhf: universe/net/optional/100% -> main
mmdb-bin 1.4.2-0ubuntu1 in focal i386: universe/net/optional/100% -> main
mmdb-bin 1.4.2-0ubuntu1 in focal ppc64el: universe/net/optional/100% -> main
mmdb-bin 1.4.2-0ubuntu1 in focal s390x: universe/net/optional/100% -> main
19 publications overridden.

[Andreas Hasenack (ahasenack)]

>> - For 20.04 we really should consider going ahead to the much newer 1.5.2
>> => https://github.com/maxmind/MaxMind-DB-Reader-python/releases
>> @andreas will you take a look at this, just as you did with the other
>> related package that was slightly outdated?

> FFe bug for the update: https://bugs.launchpad.net/ubuntu/+source/python-maxminddb/+bug/1867919

FFe approved, MP for the update to 1.5.2 at https://code.launchpad.net/~ahasenack/ubuntu/+source/python-maxminddb/+git/python-maxminddb/+merge/380854

[Matthias Klose (doko)]

Override component to main
python-maxminddb 1.5.2-0ubuntu1 in focal: universe/misc -> main
python-maxminddb-doc 1.5.2-0ubuntu1 in focal amd64: universe/doc/optional/100% -> main
python-maxminddb-doc 1.5.2-0ubuntu1 in focal arm64: universe/doc/optional/100% -> main
python-maxminddb-doc 1.5.2-0ubuntu1 in focal armhf: universe/doc/optional/100% -> main
python-maxminddb-doc 1.5.2-0ubuntu1 in focal i386: universe/doc/optional/100% -> main
python-maxminddb-doc 1.5.2-0ubuntu1 in focal ppc64el: universe/doc/optional/100% -> main
python-maxminddb-doc 1.5.2-0ubuntu1 in focal s390x: universe/doc/optional/100% -> main
python3-maxminddb 1.5.2-0ubuntu1 in focal amd64: universe/python/optional/100% -> main
python3-maxminddb 1.5.2-0ubuntu1 in focal arm64: universe/python/optional/100% -> main
python3-maxminddb 1.5.2-0ubuntu1 in focal armhf: universe/python/optional/100% -> main
python3-maxminddb 1.5.2-0ubuntu1 in focal ppc64el: universe/python/optional/100% -> main
python3-maxminddb 1.5.2-0ubuntu1 in focal s390x: universe/python/optional/100% -> main
12 publications overridden.

[Andreas Hasenack (ahasenack)]

python-maxminddb was promoted, so python-geoip2 can also be promoted now. See comment #19 for the MIR approval.

[Christian Ehrhardt  (paelzer)]

Yes Andreas it should be fine, it shows up in [1] and is ready process-wise.
There are also a bunch of related source-and-binary-move-to-universe cases for the geoip(1) which are ok and can be done as well.

[1]: https://people.canonical.com/~ubuntu-archive/component-mismatches.html

[Matthias Klose (doko)]

Override component to main
python-geoip2 2.9.0+dfsg1-2 in focal: universe/misc -> main
python3-geoip2 2.9.0+dfsg1-2 in focal amd64: universe/python/optional/100% -> main
python3-geoip2 2.9.0+dfsg1-2 in focal arm64: universe/python/optional/100% -> main
python3-geoip2 2.9.0+dfsg1-2 in focal armhf: universe/python/optional/100% -> main
python3-geoip2 2.9.0+dfsg1-2 in focal i386: universe/python/optional/100% -> main
python3-geoip2 2.9.0+dfsg1-2 in focal ppc64el: universe/python/optional/100% -> main
python3-geoip2 2.9.0+dfsg1-2 in focal s390x: universe/python/optional/100% -> main
7 publications overridden.

[Andreas Hasenack (ahasenack)]

I updated the release notes: https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Bind_9.16

[Andreas Hasenack (ahasenack)]

Also updated the release notes regarding the nginx changes: https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#nginx