[Summary]
MIR Team ack under the following constraints/todos:
TODOs:
- yes we need to demote geoip and promote libmaxminddb in exchange for that
- needs work in seeds to change to the new lib
- needs work in nginx to change dependencies
- merge 1.4.2 from upstream to get a memory leak (and others) resolved
Seems we need no rebuilds of all dependencies as they depend on much
lower version.
- get the server team subscribed to libminmadddb
@Andreas I'll assign it to you to work on those, Please ping me to officially set to approved once things are ready.
[Duplication]
Yes this is a duplicate. Contenders are:
- src:geoip (in main atm)
- src:libmaxminddb (in universe atm)
But as outlined on this bug before we could ans should replace one with the
other for 20.04.
This is not a transition to something completely different. The
company/organization behind both projects is https://dev.maxmind.com/
and they clearly go for the newer version.
Duplication isn't a problem as we will switch which of the two libs is in main.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- there is a -dev packages but we don't need to exclude as it doesn't have further dependencies into universe
- no direct dependencies on the CLI mmdb-bin, we will only promote binary libmaxminddb0
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
Problems:
- does parse data formats
It parses an on disk geoip DB (under admin control) and gets strings or
sockaddrs passed for lookup.
Strictly speaking this would need a security review, but I realized it
doesn't parse it on its own anyway, it directly passes e.g. the IP string to
getaddrinfo of glibc.
From there on it only works on a standard struct sockaddr_in* which I think
is fine.
This is as close to not needed that even my usual "better safe than sorry"
doesn't trigger and I think we can ack this without explicit security review.
[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite (not just a fake, 4 digit number of test cases)
that runs at build time
- test suite fails will fail the build upon error.
- translation are present
- not a python package, no extra constraints to consider int hat regard
Problems:
- does not have a test suite that runs as autopkgtest
But also not really depends on other things that would trigger anyway.
- no bug subscriber (yet) but it is clear that it will be the sever Team
added it to TODOs
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is (ok)
- Debian/Ubuntu update history is a bit slow
- the current release is not packaged
1.4.0 and 1.4.1 were odd, but 1.4.2 seems good and should be merged
before promotion - dependencies usually are libmaxminddb0 (>= 1.0.2)
so likely no rebuilds of all deps are needed.
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks
[Summary]
MIR Team ack under the following constraints/todos:
TODOs:
- yes we need to demote geoip and promote libmaxminddb in exchange for that
- needs work in seeds to change to the new lib
- needs work in nginx to change dependencies
- merge 1.4.2 from upstream to get a memory leak (and others) resolved
Seems we need no rebuilds of all dependencies as they depend on much
lower version.
- get the server team subscribed to libminmadddb
@Andreas I'll assign it to you to work on those, Please ping me to officially set to approved once things are ready.
[Duplication]
Yes this is a duplicate. Contenders are:
- src:geoip (in main atm)
- src:libmaxminddb (in universe atm)
But as outlined on this bug before we could ans should replace one with the
other for 20.04.
This is not a transition to something completely different. The organization behind both projects is https:/ /dev.maxmind. com/
company/
and they clearly go for the newer version.
https:/ /github. com/maxmind/ geoip-api- c is called "Legacy" for a reason /github. com/maxmind/ libmaxminddb is newer in all regards.
and https:/
Duplication isn't a problem as we will switch which of the two libs is in main.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- there is a -dev packages but we don't need to exclude as it doesn't have further dependencies into universe
- no direct dependencies on the CLI mmdb-bin, we will only promote binary libmaxminddb0
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
Problems:
- does parse data formats
It parses an on disk geoip DB (under admin control) and gets strings or
sockaddrs passed for lookup.
Strictly speaking this would need a security review, but I realized it
doesn't parse it on its own anyway, it directly passes e.g. the IP string to
getaddrinfo of glibc.
From there on it only works on a standard struct sockaddr_in* which I think
is fine.
This is as close to not needed that even my usual "better safe than sorry"
doesn't trigger and I think we can ack this without explicit security review.
[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite (not just a fake, 4 digit number of test cases)
that runs at build time
- test suite fails will fail the build upon error.
- translation are present
- not a python package, no extra constraints to consider int hat regard
Problems:
- does not have a test suite that runs as autopkgtest
But also not really depends on other things that would trigger anyway.
- no bug subscriber (yet) but it is clear that it will be the sever Team
added it to TODOs
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is (ok)
- Debian/Ubuntu update history is a bit slow
- the current release is not packaged
1.4.0 and 1.4.1 were odd, but 1.4.2 seems good and should be merged
before promotion - dependencies usually are libmaxminddb0 (>= 1.0.2)
so likely no rebuilds of all deps are needed.
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks