I reviewed gpgmepp 2.1.0-2 as checked into stonking. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
gpgmepp is a C++ wrapper (or C++ bindings) for the GnuPG project's GPGME
(GnuPG Made Easy) library. It is used by applications to perform GnuPG
operations like encrypting, decrypting, signing, verifying signatures, and
managing keys. Developers interact with it through a C++ API, while it
talks underneath to GPGME and crypto backends such as GnuPG/OpenPGP or
GpgSM/S/MIME.
- CVE History
- No CVE history
- Build-Depends
- debhelper-compat, dpkg-dev, cmake, gnupg-agent, gnupg2, gnupg,
gpgrt-tools, gpgsm, libgpg-error-dev, libgpgme-dev, pkgconf, scdaemon
- All are in main (or part of a main package) and standard
- pre/post inst/rm scripts
- N/A
- init scripts
- N/A
- systemd units
- N/A
- dbus services
- N/A
- setuid binaries
- N/A
- binaries in PATH
- none present
- sudo fragments
- none present
- polkit files
- N/A
- udev rules
- N/A
- unit tests / autopkgtests
- No autopkgtests; only manual example programs in tests/, not
automated.
- cron jobs
- None present
- Build logs
- A few benign warnings
- warning: skipping ca-certificates.crt - chroot/ca-certificates setup
noise
- dpkg-deb warning: unusual owner or group 1000:127 - sbuild dummy
build-deps package artifact
- dpkg-source warning: extracting unsigned source package - expected
for a local unsigned build
- CMake warning: manually-specified variables not used - harmless
unused cache vars passed by the build helper
- Processes spawned
- None
- Memory management
- gpgmepp is C++ and manages memory carefully using RAII and the
d-pointer pattern, leaning on STL containers (std::vector,
std::string) and smart pointers rather than raw ownership.
- The few raw new/new[] allocations that show up are narrow and
balanced: result classes deep-copy the underlying GPGME C structs,
strdup() the fpr strings (guarded by null checks) and sever the next
pointer so destructors never walk into GPGME-owned memory, freeing
symmetrically (strdup<->free, new<->delete).
- The key-array allocations in context.cpp are sized n+1 for the NULL
terminator, only fill non-null entries so they can't overrun, and are
delete[]'d on every path. iocbs ownership is transferred cleanly to
the Context (no leak/double-free).
- No mismatched alloc/free, leaks, or overflow concerns found.
- File IO
- The library does essentially no file IO of its own; file/data handling
is delegated to GPGME. The only fopen in the library is an opt-in
debug log gated behind the GPGMEPP_INTERACTOR_DEBUG env var
(append-only, never read back). The other fopens are read-only in the
test programs using CLI args.
- Logging
- No obvious secret leakage like passwords, tokens, private keys, or
environment contents
- Environment variable usage
- Only one env var (GPGMEPP_INTERACTOR_DEBUG), a debug-only knob used as
a literal string comparison / log filename, not abusable beyond the
privileges of whoever already set it.
- Use of privileged functions
- None
- Use of cryptography / random number sources etc
- gpgmepp does no crypto itself; it's a thin C++ wrapper that hands Data
objects and key operations down to GPGME, where the actual crypto
(GpgSM/S-MIME, GnuPG/OpenPGP, RNG) happens.
- Return codes from GPGME calls are consistently checked and wrapped in
Error(...)/make_error(...); callback paths null-check providers and
set errno on failure.
- Use of temp files
- None
- Use of networking
- No networking of its own; gpgmepp is a library with no sockets, no
listeners, no HTTP. The read/write hits are just GPGME IPC
(gpgme_io_*/gpgme_data_* over pipes/fds to the GnuPG agent), not
network I/O.
- Data passed through Data::read/write is opaque bytes handed verbatim
to GPGME, which treats it as untrusted crypto input and
parses/validates it.
- The passphrase write loop (callbacks.cpp) handles partial writes
correctly, checks for <0, and wipes+frees the passphrase afterward.
- Use of WebKit
- None
- Use of PolicyKit
- None
- Any significant cppcheck results
- None
- Any significant Coverity results
- 19 findings. Two findings unreported in the GnuPG tracker which are
potential code-quality issues, but non-blocking:
- null-dereference in SwdbResult::Private when constructed with a null
result (swdbresult.cpp:43)
- context leak in Data::toKeys() on the keylist-start error path
(data.cpp:257)
- However, none of these are exploitable.
- Lower-priority NULL_FIELD/UNINIT_CTOR defensive-coding nits in
verificationresult.cpp, key.cpp, tofuinfo.cpp, swdbresult.cpp.
- Any significant shellcheck results
- No significant results. All 11 findings are in cmake/modules/*.sh
which are low-severity style issues only (quoting, legacy backticks,
constant expressions).
- Any significant bandit results
- None
- Any significant govulncheck results
- None
- Any significant Semgrep results
- None
Security team ACK for promoting gpgmepp to main.
** Changed in: gpgmepp (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
** Changed in: gpgmepp (Ubuntu)
Status: New => In Progress
--
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
