| 2020-01-28 12:38:41 |
Andreas Hasenack |
bug |
|
|
added bug |
| 2020-03-10 19:02:00 |
Joshua Powers |
bug |
|
|
added subscriber Joshua Powers |
| 2020-03-10 20:00:30 |
Andreas Hasenack |
description |
MIR placeholder bug. To Be Filled out. |
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.
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 |
|
| 2020-03-10 20:10:59 |
Andreas Hasenack |
description |
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.
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 |
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.
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
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 |
|
| 2020-03-10 20:11:26 |
Andreas Hasenack |
bug |
|
|
added subscriber MIR approval team |
| 2020-03-10 20:11:29 |
Andreas Hasenack |
libmaxminddb (Ubuntu): importance |
Medium |
Undecided |
|
| 2020-03-10 20:11:33 |
Andreas Hasenack |
libmaxminddb (Ubuntu): status |
Triaged |
New |
|
| 2020-03-10 20:13:04 |
Andreas Hasenack |
description |
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.
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
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 |
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.
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 |
|
| 2020-03-10 20:30:23 |
Andreas Hasenack |
description |
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.
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 |
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 |
|
| 2020-03-10 21:09:37 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+merge/380519 |
|
| 2020-03-11 12:08:49 |
Andreas Hasenack |
libmaxminddb (Ubuntu): assignee |
Andreas Hasenack (ahasenack) |
|
|
| 2020-03-11 12:16:56 |
Andreas Hasenack |
libmaxminddb (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-03-11 13:08:05 |
Andreas Hasenack |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/380547 |
|
| 2020-03-11 13:36:45 |
Andreas Hasenack |
bug task added |
|
nginx (Ubuntu) |
|
| 2020-03-11 13:36:51 |
Andreas Hasenack |
nginx (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-03-11 13:36:56 |
Andreas Hasenack |
nginx (Ubuntu): status |
New |
In Progress |
|
| 2020-03-11 16:12:39 |
Thomas Ward |
bug |
|
|
added subscriber Thomas Ward |
| 2020-03-11 18:47:10 |
Thomas Ward |
attachment added |
|
nginx-nogeoip.debdiff https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/+attachment/5335815/+files/nginx-nogeoip.debdiff |
|
| 2020-03-11 18:48:42 |
Thomas Ward |
attachment removed |
nginx-nogeoip.debdiff https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/+attachment/5335815/+files/nginx-nogeoip.debdiff |
|
|
| 2020-03-11 18:49:40 |
Thomas Ward |
attachment added |
|
nginx debdiff to drop libnginx-mod-http-geoip from the nginx-core package deps https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/+attachment/5335816/+files/nginx-nogeoip.debdiff |
|
| 2020-03-11 19:39:09 |
Andreas Hasenack |
bug task added |
|
ubuntu-release-notes |
|
| 2020-03-11 20:49:48 |
Steve Langasek |
bug task added |
|
python-geoip2 (Ubuntu) |
|
| 2020-03-11 23:50:13 |
Andreas Hasenack |
description |
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 |
== MIR for libmaxminddb bug task ==
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 |
|
| 2020-03-11 23:50:37 |
Andreas Hasenack |
cve linked |
|
2007-0159 |
|
| 2020-03-11 23:51:01 |
Andreas Hasenack |
description |
== MIR for libmaxminddb bug task ==
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 |
== MIR for libmaxminddb bug task ==
(for the python-geoip2 bug task, please see https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/17)
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 |
|
| 2020-03-12 08:51:10 |
Christian Ehrhardt |
python-geoip2 (Ubuntu): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2020-03-12 10:33:58 |
Christian Ehrhardt |
python-geoip2 (Ubuntu): status |
New |
In Progress |
|
| 2020-03-12 10:34:00 |
Christian Ehrhardt |
python-geoip2 (Ubuntu): assignee |
Christian Ehrhardt (paelzer) |
|
|
| 2020-03-16 09:56:00 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/380713 |
|
| 2020-03-16 09:56:43 |
Robie Basak |
merge proposal unlinked |
https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/380713 |
|
|
| 2020-03-16 19:18:13 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+merge/380519 |
|
|
| 2020-03-16 21:08:13 |
Andreas Hasenack |
bug task added |
|
python-maxminddb (Ubuntu) |
|
| 2020-03-17 01:04:36 |
Launchpad Janitor |
nginx (Ubuntu): status |
In Progress |
Fix Released |
|
| 2020-03-17 14:13:09 |
Andreas Hasenack |
libmaxminddb (Ubuntu): status |
New |
Fix Released |
|
| 2020-03-17 14:14:11 |
Andreas Hasenack |
libmaxminddb (Ubuntu): status |
Fix Released |
Fix Committed |
|
| 2020-03-17 18:41:39 |
Andreas Hasenack |
description |
== MIR for libmaxminddb bug task ==
(for the python-geoip2 bug task, please see https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/17)
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 |
== 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 |
|
| 2020-03-18 09:14:53 |
Christian Ehrhardt |
python-maxminddb (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-03-19 15:30:14 |
Matthias Klose |
libmaxminddb (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2020-03-20 16:41:47 |
Matthias Klose |
python-maxminddb (Ubuntu): status |
New |
Fix Released |
|
| 2020-03-23 19:37:22 |
Christian Ehrhardt |
python-geoip2 (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2020-03-24 14:24:20 |
Matthias Klose |
python-geoip2 (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2020-04-02 18:35:49 |
Andreas Hasenack |
ubuntu-release-notes: status |
New |
Fix Released |
|
| 2020-04-02 18:35:55 |
Andreas Hasenack |
ubuntu-release-notes: assignee |
|
Andreas Hasenack (ahasenack) |
|
