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:
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
Packages which open privileged ports (ports < 1024).
- none
Add-ons and plugins to security-sensitive software (filters, scanners, UI skins, etc)
- The only reverse-dependency of python3-geoip2 is an irc bot called "sopel" which is in universe
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 python module and it can be importer straight away
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.
The status of important bugs in Debian's, Ubuntu's, and upstream's bug tracking systems must be evaluated. Important bugs must be pointed out and discussed in the MIR report.
- no bugs in ubuntu other than this MIR (https://bugs.launchpad.net/ubuntu/+source/python-geoip2)
- no bugs in debian (https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=python-geoip2)
The package should not deal with exotic hardware which we cannot support.
- no exotic hardware involved
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.
- 100 tests run at package build time
- dep8 tests are standard python tests, via "Testsuite: autopkgtest-pkg-python" in d/control, and are green: http://autopkgtest.ubuntu.com/packages/python-geoip2
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.
- package ships a working d/watch file, which uscan uses and wants to update to version 3.0.0, and also produces a dfsg tarball
It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance
$ lintian -I --pedantic
E: python-geoip2 changes: bad-distribution-in-changes-file unstable
P: python-geoip2 source: rules-requires-root-missing
- cleanest lintian I've seen in a long time
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.
- package is python3 only
- depends on python3-requests, which is not about to be demoted or obsolete
UI standards:
- n/a
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)
- dependencies are python3-maxminddb (>= 1.4.0), python3-requests, python3:any
- python3-maxminddb is a subject of this same MIR LP: #1861101
- no recommends
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.
- nothing to note here
Maintenance:
The package must have an acceptable level of maintenance corresponding to its complexity:
- uses debhelper, clean d/rules, just one binary package, standard python3 module packaging
All packages must have a designated "owning" team, regardless of complexity, which is set as a package bug contact.
- server team will subscribe to 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
- package is currently a sync with 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.
- descriptions are fine
== 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: /code.launchpad .net/~ahasenack /ubuntu- seeds/+ git/ubuntu/ +merge/ 380547/ comments/ 998609)
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:/
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 /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
- no hits for "maxmind", "maxminddb", "libmaxminddb" other than a javascript implementation of this api
- no hits for "geoip2"
- "geoip" (https:/
check OSS security mailing list (feed 'site:www. openwall. com/lists/ oss-security <pkgname>' into search engine) /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. openwall. com/lists/ oss-security geoip) all pointing to the same issue below: /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
- a search for "maxmind" returned https:/
- a search for "geoip2" returns no results
- a search for "geoip" returns 3 results (site:www.
- https:/
Ubuntu CVE Tracker people. ubuntu. com/~ubuntu- security/ cve/main. html
http://
- 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 code
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)
- The only reverse-dependency of python3-geoip2 is an irc bot called "sopel" which is in universe
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 python module and it can be importer straight away
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. /bugs.launchpad .net/ubuntu/ +source/ python- geoip2) /bugs.debian. org/cgi- bin/pkgreport. cgi?dist= unstable; package= python- geoip2)
The status of important bugs in Debian's, Ubuntu's, and upstream's bug tracking systems must be evaluated. Important bugs must be pointed out and discussed in the MIR report.
- no bugs in ubuntu other than this MIR (https:/
- no bugs in debian (https:/
The package is maintained well in Debian/Ubuntu (check out the Debian PTS) /tracker. debian. org/pkg/ python- geoip2 /github. com/maxmind/ GeoIP2- python/ releases/ tag/v3. 0.0), Dec 2019 (not that far ago) /salsa. debian. org/python- team/modules/ python- geoip2/ -/blob/ master/ debian/ changelog
https:/
- new upstream version available (3.0.0). Release notes: https:/
- unreleased vcs changes (just a standards-version bump: https:/
- which almost fixes the remaining wishlist item in the tracker: standards version 4.4.0 where the latest is 4.5.0. The commit above bumps it to 4.4.1
The package should not deal with exotic hardware which we cannot support.
- no exotic hardware involved
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. pkg-python" in d/control, and are green: http:// autopkgtest. ubuntu. com/packages/ python- geoip2
- 100 tests run at package build time
- dep8 tests are standard python tests, via "Testsuite: autopkgtest-
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.
- package ships a working d/watch file, which uscan uses and wants to update to version 3.0.0, and also produces a dfsg tarball
It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance n-in-changes- file unstable root-missing
$ lintian -I --pedantic
E: python-geoip2 changes: bad-distributio
P: python-geoip2 source: rules-requires-
- cleanest lintian I've seen in a long time
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.
- package is python3 only
- depends on python3-requests, which is not about to be demoted or obsolete
UI standards:
- n/a
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)
- dependencies are python3-maxminddb (>= 1.4.0), python3-requests, python3:any
- python3-maxminddb is a subject of this same MIR LP: #1861101
- no recommends
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.
- nothing to note here
Maintenance:
The package must have an acceptable level of maintenance corresponding to its complexity:
- uses debhelper, clean d/rules, just one binary package, standard python3 module packaging
All packages must have a designated "owning" team, regardless of complexity, which is set as a package bug contact.
- server team will subscribe to 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
- package is currently a sync with debian
Background information: justifications should be done in the MIR report.
The package descriptions should explain the general purpose and context of the package. Additional explanations/
- descriptions are fine