[MIR] jeepney
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| jeepney (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
| python-secretstorage (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
[Availability]
Available in Ubuntu Focal.
[Rationale]
python-
https:/
Also, the Freedesktop wiki lists dbus-python among "Obsolete libraries":
https:/
So the new release of secretstorage is now using jeepney, a lightweight pure Python D-Bus implementation instead of dbus-python (which was written in C).
[Security]
No security history.
[Quality assurance]
Upstream has a test suite, and it is being run during package build:
https:/
There is also an autopkgtest:
http://
[Dependencies]
Depends: python3:any
Build-Depends: debhelper-compat (= 12), dh-python, python3-all, python3-pytest, python3-sphinx, python3-
[Standards compliance]
Standards-Version: 4.4.1
[Maintenance]
Maintained upstream in https:/
Maintained in Debian by me under the umbrella of Debian Python modules team. Maintenance is very simple, debian/rules is just 18 lines.
Looking at the reverse-depends in main for python3-keyring:
$ reverse-depends -c main python3-keyring
Reverse-Depends
* python3-
* python3-
* python3-novaclient
* python3-
keystoneclient has optional support for keyring (so could demote Depends->Suggests), novaclient and openstackclient have dropped support for keyring.
python3-
[Summary]
Alternative D-Bus implementation for Python applications.
MIR team -1 due to duplication of function; if we could switch over all reverse-depends in main this switch would be re-considered.
I've asked the Ubuntu OpenStack team to review use of python3-keyring to see if we can remove 3/4 of the reverse-depends that hold keyring in main - launchpadlib seems to be a potential blocker.
Would require security team review due to integration with D-Bus.
[Duplication]
Pure Python DBus implementation, fulfilling the same function as dbus-python.
python-
$ reverse-depends -c main python3-dbus
Reverse-Depends
* hplip [amd64 arm64 armhf ppc64el s390x]
* language-
* networkd-dispatcher
* python3-aptdaemon
* python3-cupshelpers
* python3-dbus-dbg
* python3-
* software-
* system-
* system-
* system-
* ubiquity-
* ubuntu-
* ubuntu-
* unattended-upgrades
* update-manager
* update-notifier [amd64 arm64 armhf ppc64el s390x]
* update-
* usb-creator-common [amd64]
* usb-creator-gtk [amd64]
I suspect its unlikely that these will all migrate during the Focal timeframe so including this package into main would duplicate functionality.
[Embedded sources and static linking]
- no embedded source present
- no static linking
[Security]
- no history of CVEs
- does not use webkit1,2
- does not use lib*v8 directly
- 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 run a daemon as root
- does not open a port
But it has quite some security sensitive elements:
- does not parse data formats
- integrates with D-Bus
- access to all data passed in between
Will require security team review.
[Common blockers]
- does not currently FTBFS
- no translation present, but none needed
- no python2
- has autopkgtests
- lacks a team bug subscriber
[Packaging red flags]
- In sync with debian
- symbols tracking not applicable for this code.
- d/watch is present and works
- Upstream update history is good
- Limited Debian/Ubuntu history (new for focal)
- the current release is packaged
- no MOTU problem
- no Lintian warnings
- d/rules nice and clean
- not using Built-Using
- no golang package for extra considerations about that
[Upstream red flags]
- no errors during the build
- no incautious use of malloc/sprintf (N/A)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no significant open bug reports upstream
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks
I can temporarily revert to the old version of SecretStorage which used dbus-python, but this is not a long-term solution because dbus-python and libdbus are obsolete.
I can also demote python3-keyring Depends on python3-
python3-keyring isn't used by python-
I've uploaded new versions of python-
This bug was fixed in the package python-novaclient - 2:16.0.0-0ubuntu2
---------------
python-novaclient (2:16.0.0-0ubuntu2) focal; urgency=medium
* d/control: Drop python3-keyring as it is no longer used (LP: #1861268).
-- Corey Bryant <email address hidden> 2020年2月04日 13:26:18 -0500
This bug was fixed in the package python-
---------------
python-
* d/control: Move python3-keyring to Suggests since it is optional
(LP: #1861268).
-- Corey Bryant <email address hidden> 2020年2月04日 13:40:51 -0500
This bug was fixed in the package python-
---------------
python-
* d/control: Drop python3-keyring as it is no longer used (LP: #1861268).
-- Corey Bryant <email address hidden> 2020年2月04日 13:28:26 -0500
Reflecting on this situation I think if we where not developing for an LTS release, having two python DBUS interfaces in main for an interim release period of 9 months might be acceptable; but we're not in that position so I'd suggest that we stick with the older python3-dbus based secretstorage for 20.04.
This means we only have a single DBUS interface to support for an LTS (5/10 years) and we give the other upstream projects a bit more time to make the switch (maybe with some nudging/
We can review again at the start of the 20.10 development cycle to see how things have progressed.
Ok, I will revert python-
Marking Incomplete for now and targetting to later.
Focal is now released, and Groovy has new python-
MIR team ack as discussed last cycle but needs security team review.
Marking this as affecting python-
I reviewed jeepney 0.4.3-1 as checked into groovy. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
jeepney is a pure Python D-Bus interface. D-Bus is an inter-process
communication system.
In its README file, jeepney maintainer mentions:
"This project is experimental, and there are a
number of more mature Python DBus bindings."
The mature options that the maintainer mention don't seem to be as
maintained as jeepney.
- No CVE History
- Build-Depends:
- python3-all
- python3-pytest
- python3-sphinx
- python3-
- python3-testpath
- prerm and postinst scripts automatically created
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- No binaries in PATH
- No sudo fragments
- No polkit files
- No udev rules
- unit tests / autopkgtests
- the source code comes with some tests that can be run with pytest.
- autopkgtests are also available for this package
- No cron jobs
- Build logs:
- No relevant errors or warnings
- Processes spawned
- Only in test code
- No memory management
- File IO
- Open and write a .py output file when using bindgen to auto-generate
DBus bindings. The path argument to bindgen is actually a DBus path and
not a filesystem path.
- There's not much handling on the output file, you can specify a path.
- Bindgen is a tool and not used anywhere else in the code.
- No logging
- No environment variable usage
- No use of privileged functions
- No use of cryptography / random number sources
- Use of temp files only in test code
- Use of networking
- Use sockets to connect to DBus when using tornado, asyncio or blocking I/O.
- Looks safe
- No use of WebKit
- No use of PolicyKit
- Coverity only found issues in javascript code from the generated documentation
- Bandit found the following issues:
- B405: import_xml_etree - LOW
- B314: xml.etree.
- B101: assert_used - LOW
- B105: hardcoded_
- There are plenty of other LOW issues on test code that we are not analysing
- Those issues are low enough to allow this MIR to continue
Although the maintainer still consider it as experimental, it is a good test
to have it on a non-LTS Ubuntu as dbus-python is obsolete.
Keep in mind that jeepney has some limitations:
https:/
Security team ACK for promoting jeepney to main.
This is now done:
$ change-override -S -s groovy jeepney -c main
Override component to main
jeepney 0.4.3-1 in groovy: universe/misc -> main
jeepney-doc 0.4.3-1 in groovy amd64: universe/
jeepney-doc 0.4.3-1 in groovy arm64: universe/
jeepney-doc 0.4.3-1 in groovy armhf: universe/
jeepney-doc 0.4.3-1 in groovy i386: universe/
jeepney-doc 0.4.3-1 in groovy ppc64el: universe/
jeepney-doc 0.4.3-1 in groovy riscv64: universe/
jeepney-doc 0.4.3-1 in groovy s390x: universe/
python3-jeepney 0.4.3-1 in groovy amd64: universe/
python3-jeepney 0.4.3-1 in groovy arm64: universe/
python3-jeepney 0.4.3-1 in groovy armhf: universe/
python3-jeepney 0.4.3-1 in groovy i386: universe/
python3-jeepney 0.4.3-1 in groovy ppc64el: universe/
python3-jeepney 0.4.3-1 in groovy riscv64: universe/
python3-jeepney 0.4.3-1 in groovy s390x: universe/
Override [y|N]? y
15 publications overridden.