Review for Source Package: src:gpgmepp

[Summary]
Upstream gpgme1.0 split out gpgmepp and qgpgme packages with C++ and Qt language
bindings respectively, at version 2.0.0 [1]. Because gpgme1.0 was in main 
before the split,
gpgmepp was also promoted to resolve a component mismatch with src:poppler. 
This should
hence be considered as a retrospective review of src:gpgmepp.

MIR team ACK with some recommended TODOs.

This is a security-sensitive package. 
This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: bin:libgpgmepp7, 
bin:libgpgmepp-dev
Specific binary packages built, but NOT to be promoted to main: None

[1] https://gnupg.org/ftp/gcrypt/gpgme/

Notes:
#0 - This review is restricted to src:gpgmepp and does not cover src:gpgme1.0.

Required TODOs:
None.

Recommended TODOs:
#1 - Please consider adding build-time tests to the package.
#2 - Please consider adding autopkgtests to the package.
#3 - With the justified absence of a .symbols file, an empty argument
should be passed to dh_makeshlibs -V. See line #303 of the MIR
reviewer's template [2].

[2] https://documentation.ubuntu.com/project/MIR/mir-reviewers-template/

[Rationale, Duplication and Ownership]
- There is no other package in main providing the same functionality.
  => src:gpgmepp relates to the upstream https://gnupg.org/ftp/gcrypt/gpgmepp/
     split from https://gnupg.org/ftp/gcrypt/gpgme in version 2.0.0.
- A team is committed to own long term maintenance of this package.
  => Debcrafters
- The rationale given in the report seems valid and useful for Ubuntu

[Dependencies]
OK:
- no other runtime Dependencies to MIR due to this
- no other build-time Dependencies with active code in the final binaries 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 system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)
  => the package does deal with encryption/decryption, signatures, signature 
verification,
     key management, keyserver operations
- this makes appropriate (for its exposure) use of established risk
  mitigation features (dropping permissions, using temporary environments,
  restricted users/groups, seccomp, systemd isolation features, apparmor, ...)
  => risk mitigation features are not relevant gpgmepp which is a library

Problems: None

[Common blockers]
OK:
- does not FTBFS currently
- This does not need special HW for build or test
- no new python2 dependency
- not a  Python package
- not a Go package

Problems:
- does NOT have a test suite that runs at build time
- does NOT have a non-trivial test suite that runs as autopkgtest

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- For c++ libraries - symbols tracking isn't in place but the owning
  team tried to set it up and came back with a reasonable rationale
  of why it isn't practical to do for the package.
  => dh_makeshlibs -V with no args needs to be invoked
- debian/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- 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
- debian/rules is rather clean
- It is not on the lto-disabled list

Problems:
- The rationale to not include a .symbols file is documented in 
libgpgmepp7.lintian-overrides.
  However, override_dh_makeshlibs needs to be defined in d/rules passing an 
empty argument to 
  dh_makeshlibs -V. 

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user 'nobody' outside of tests
- no use of setuid / setgid
- use of setuid, but ok because TBD
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit or libseed
- not part of the UI for extra checks
- no translation present, but none needed for this case

Problems: None

** Changed in: gpgmepp (Ubuntu)
     Assignee: Pushkar Kulkarni (pushkarnk) => 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/2142863

Title:
  [MIR] gpgmepp

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gpgmepp/+bug/2142863/+subscriptions


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

Reply via email to