Review for Source Package: dbconfig-common

[Summary]

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: dbconfig-common, 
dbconfig-pgsql
Specific binary packages built, but NOT to be promoted to main: dbconfig-mysql, 
dbconfig-pgsql, dbconfig-sqlite3, dbconfig-no-thanks

Required TODOs:
#1 - please look into these open bugs
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000174
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000176
  Are they edge cases, fine - or do they need to be tackled before
  adding to required tasks?
#2 - update the request with pgsql in mind unless if we change our goal again

Recommended TODOs:
- none

[Rationale, Duplication and Ownership]
- There is no other package in main providing the same functionality.
- A team is committed to own long term maintenance of this package
  (= ubuntu-server) and is already subscribed
- The rationale given in the report seems valid and useful for Ubuntu
  especially with the change to include the more helpful pgsql backend

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems: None

[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 parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- does not expose any external endpoint (port/socket/... or similar)
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates,
  signing, ...)
- this makes appropriate (for its exposure) use of established risk
  mitigation features (it has no continuously running component, so none
  is IMHO fine here)

Problems:
- does deal with system authentication, by setting up initial
        database configs. And in doing so right or wrong is the only real
        threat (confirmed by the long past CVEs that it had). To bring it
        back re-checking dbconfig-common and pgsql with a security POV
        might be worth, the last check would be 17 years ago if we did it
        at all back then.

[Common blockers]
OK:
- does not FTBFS currently
- does have a non-trivial test suite that runs as autopkgtest and it did
  not cause trouble all the years as it runs on any or psql/mysql/maria
  and a few other things
- This does not need special HW for build or test
- no new python2 dependency

Problems:
- does not have a test suite that runs at build time, but that is covered
  by the good autopkgtests

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- debian/watch is not present but also not needed (= native)
- Upstream update history is slow but ok (not much churn)
- Debian/Ubuntu update history is the same (=native packge in sync)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings (even the ignored ones are tolerable)
- debian/rules is rather clean
- It is not on the lto-disabled list (no linked code)

Problems: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of user 'nobody' outside of tests
- no use of setuid / setgid
- no dependency on webkit, qtwebkit or libseed
- not part of the UI for extra checks
- no translation present, but none needed for this case (user visible)?

DO-A: Problems:
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (runs as root at
  setup time though). I already queued it for security so that is not
  changing much.
- no important open bugs (crashers, etc) in Debian or Ubuntu
  But there are two i'd ask to look into before accepting it for the
  requested use case
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000174
  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000176
  Are they edge cases, fine - or do they need to be tackled before
  adding to required tasks

** Bug watch added: Debian Bug tracker #1000174
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000174

** Bug watch added: Debian Bug tracker #1000176
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000176

** Changed in: dbconfig-common (Ubuntu)
     Assignee: Christian Ehrhardt (paelzer) => Ubuntu Security Team 
(ubuntu-security)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2115647

Title:
  [MIR] dbconfig-common

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbconfig-common/+bug/2115647/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to