I reviewed libdex 0.7.1-1 as checked into oracular. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
libdex is basically a GNOME library used for asynchronous operations.
from upstream:
Dex provides Future-based programming for GLib-based applications.
Dex also provides Fibers which allow writing synchronous looking code in
C that uses asynchronous and future-based APIs.
- CVE History
- No CVE in history.
- Build-Depends
- gobject-introspection (provides machine readable introspection data of
the API of C libraries, in main)
- gi-docgen (documentation tool, in universe)
- glib2.0 (GLib, in main)
- liburing (Linux kernel io_uring access library, in main)
- meson (build system, in universe)
- valac (C# like language for the GObject system, in universe)
- sysprof (profiler, MIR: LP#2066269)
- pre/post inst/rm scripts
- None
- init scripts
- None
- systemd units
- None
- dbus services
- None
- setuid binaries
- None
- binaries in PATH
- None
- sudo fragments
- None
- polkit files
- None
- udev rules
- None
- unit tests / autopkgtests
- It has an internal testsuite that is executed during build time.
from the build log:
1/8 test-async-result OK 0.06s
2/8 test-channel OK 0.05s
3/8 test-fiber OK 0.04s
4/8 test-future OK 0.04s
5/8 test-stream OK 0.02s
6/8 test-object OK 0.36s
7/8 test-scheduler OK 0.34s
8/8 test-semaphore OK 3.54s
Ok: 8
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 0
Timeout: 0
- Does not run autopkgtest. It is mentioned that libdex will be tested in
a wider range when testing gnome-builder and sysprof.
- cron jobs
- None
- Build logs
- one warning:
../src/dex-async-result.h:35: Warning: Dex: Couldn't find 'new_finish' for
the corresponding async function: 'new'
- Processes spawned
- None
- Memory management
- it uses GLib wrappers, no resource leaks detected by coverity (there is
one for the testsuite/ only)
- mainly, the memory management usage is about initializing memory with
g_new0, initializes structs with 0, all looking safe.
- the only non glib usage is a memmove that is only compiled for FreeBSD.
- File IO
- only found file I/O operations in the examples
- Logging
- the logs are mainly for error tracking, all using GLib methods, didn't
spot anything that shouldn't be there, most of them are error code
translation to string.
- Environment variable usage
- None
- Use of privileged functions
- None
- Use of cryptography / random number sources etc
- None
- Use of temp files
- None
- Use of networking
- not really used for web interaction, mainly socket connections
- Use of WebKit
- None
- Use of PolicyKit
- None
- Any significant cppcheck results
- the results are complains about GLib macros, cppcheck does not get them.
- Any significant Coverity results
- There are a few warning (9, not including the examples/ and testsuite/
ones), but I don't think they are blockers, and as far I could tell, at
least one could be false positives.
I've shared that privately with upstream on:
https://gitlab.gnome.org/GNOME/libdex/-/issues/20
Upstream replied quickly, some are in fact false positives and at least
one commits ended up being created to avoid potential deadlocks.
Into a bit more details, they are of the types:
Type: Value not atomically updated (ATOMICITY)
Type: Ignoring number of bytes read (CHECKED_RETURN)
Type: Data race condition (MISSING_LOCK)
Type: Data race condition (MISSING_LOCK)
Type: Data race condition (MISSING_LOCK)
Type: Thread deadlock (ORDER_REVERSAL)
Type: Thread deadlock (ORDER_REVERSAL)
Type: Thread deadlock (ORDER_REVERSAL)
Type: Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN)
The integer overflow is easier to spot but I don't see it causing much
harm. Anyway, I've proposed the fix in:
https://gitlab.gnome.org/GNOME/libdex/-/merge_requests/12
And as quick as the issue reply, this got accepted and merged.
- Any significant shellcheck results
- None
- Any significant bandit results
- None
- Any significant govulncheck results
- None
- Any significant Semgrep results
- None
In the Bug Description section it is mentioned the concerns of having
liburing as a dependence as it is an access library to the Linux kernel
io_uring that is known for security issues. The concern is valid, the
io_uring subsystem in kernel is a common target for people looking for
vulnerabilities in the Linux kernel.
The good thing here is that the io_uring methods are being used cleanly
and correctly and does not seem to be any pain points in the usage of the
library (an easy way to fetch those is to look for io_uring_*() calls).
Of course, the library itself could be a source of attack but we can
leverage the fact that this is not the only package using it, the list of
packages using it includes qemu which is in main.
What we have done here is to try to spot wrong, or not careful, ways the
library could have been used.
Also, it worth mentioning that the project is very well organized,
documented, and seems to be actively maintained.
Security team ACK for promoting libdex to main.
** Bug watch added: gitlab.gnome.org/GNOME/libdex/-/issues #20
https://gitlab.gnome.org/GNOME/libdex/-/issues/20
** Changed in: libdex (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2066262
Title:
[MIR] libdex
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libdex/+bug/2066262/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
