[MIR] python3-pyasyncore
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| python-pyasyncore (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
[Availability]
Currently in universe
[Rationale]
python3-taskflow is a common OpenStack dependency and it depends on asyncore support from the Python standard library.
[Security]
No security history
[Quality Assurance]
Package works out of the box with no prompting. There are no major bugs in Ubuntu and there are no major bugs in Debian.
[Dependencies]
All are in main
[Standards Compliance]
FHS and Debian Policy compliant
[Maintenance]
Simple python package that the OpenStack Team will take care of.
[Background]
In Python 3.12, asyncore is removed from the standard library. The asyncore module has been copied to a package named pyasyncore. This will allow projects such as taskflow to work on Python 3.12+ until the upstream project has migrated away from asyncore.
Related taskflow bug: https:/
Related taskflow discussion: https://<email address hidden>
CVE References
| Changed in python-pyasyncore (Ubuntu): | |
| assignee: | nobody → Christian Ehrhardt (paelzer) |
| Christian Ehrhardt (paelzer) wrote | #1 |
| Changed in python-pyasyncore (Ubuntu): | |
| status: | New → Fix Committed |
| Christian Ehrhardt (paelzer) wrote | #2 |
| Christian Ehrhardt (paelzer) wrote | #3 |
| Changed in python-pyasyncore (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| assignee: | Christian Ehrhardt (paelzer) → nobody |
Review for Source Package: python-pyasyncore
[Summary]
MIR team ACK
This does not need a security review.
On one hand it doesn't do much that creates exposure, but on the other hand one
might rightfully say - but in the past code using it was affected e.g. in
CVE-2010-3492. But then this was part of python3 up to 3.12 and as part of that
reviewed and accepted for years - the code is still the very same and therefore
no re-review needed IMHO.
List of specific binary packages to be promoted to main: python3-pyasyncore
Specific binary packages built, but NOT to be promoted to main: n/a
[Rationale, Duplication and Ownership]
- There is no other package in main providing the same functionality.
And I mean "exactly the same" asyncio is similar and recommended, but this
is all about making the change a little bit softer and not as quick.
- A team (openstack) is committed to own long term maintenance of this package.
- The rationale given in the report seems valid and useful for Ubuntu
To be clear, not in a a sense like "yay everone use it please" but as in
"we understand we can't cut ties as fast as upstream does"
It is a bit weird though and I want to know if that means we'll carry it
forever - gladly just when I wanted to write this I found that you already
linked bugs and discussions about python3-taskflow getting rid of it in the
future - in that scope I tihnk it is ok to keep it for a while.
[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 (a few, but very long time no new
ones)
- 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, ...)
- this makes appropriate (for its exposure) use of established risk
mitigation features => being only a lib it can't decide what to do as it does
not know its scenario
Problems: None
[Common blockers]
OK:
- does not FTBFS currently
- This does not need special HW for build or test
- no new python2 dependency
- Python package, but using dh_python
Problems:
- does not have a test suite that runs at build time
- does not have a non-trivial test suite that runs as autopkgtest
AFAICS in t...