[MIR] python-falcon as dependency of mailman3
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
python-falcon (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
[Availability]
The package is already universe for quite a while and build/works fine so far.
It builds amd64 only (but binary is arch-all)
This package builds python2 and python3 binaries, but we only depend on the python3 package for the mailman3 transition.
[Rationale]
This is part of the MIR activity for all dependencies of mailman3
The "main" MIR of it is at bug 1775427:
Mailman (2) has only python2 support, but we strive for python3,
therefore Mailman3 which has python3 support should be promoted to main.
Dealing with REST requests for APIs this more likely needs a seucrity review - especially considering that we are a bit behind latest upstream.
Outcome might be that updating to 1.4.1 is a must before proceeding (while otherwise I'd have scheduled that later in the 19.10 cycle)
[Security]
No known CVEs found.
[Quality assurance]
As part of the mailman3 stacks as of now (Disco) this installs fine and works fine.
On itself it is useful to (many) other dependencies and does not need a post install configuration on its own.
The package does not ask debconf questions.
Zero known bugs in Ubuntu and Debian for this component.
This is a bigger project with 209 open and 506 issues closed upstream.
No Deal breakers seen when skimming over them.
The package gets updates by Debian packaging, but from upstream there seems to be no new version packaged for quite some time.
There are newer upstream versions thou see https:/
IMHO This doesn't stop the MIRing but I've added a task to check feasability of updating to the latest version to our list.
No exotic HW involved.
The package utilizes build time self tests.
d/watch is set up and ok.
No Lintian warning except newer Standards/Compat versions and no HTTPS links uses or GPG checks - nothing severe.
The package does not rely on demoted or obsolete packages.
py2 packages in this src, but as mentioned we won't pull them into main.
No new gt2k dependencies
[UI standards]
This is a low level library without (a lot) of user visible strings - no translations (needed).
No End-user applications that needs a standard conformant desktop file.
[Dependencies]
Some dependencies are not in main, but we drive MIR for all related packages
that are not in main at the same time.
Please check the list of bugs from the main Mailman3 MIR in bug 1775427 to get an overview.
[Standards compliance]
The package meets the FHS and Debian Policy standards.
The packaging itself is very straight forward and uses dh_* as much as possible - the d/rules fits on one screen.
[Maintenance]
The Server team will subscribe for the package for maintenance, but in
general it seems low on updates and currently is a sync from Debian.
[Background]
The package description explains the general purpose and context of the package well.
Changed in python-falcon (Ubuntu): | |
assignee: | Ubuntu Security Team (ubuntu-security) → nobody |
[Duplication]
No duplication of that functionality in the Archive in general or main in particular.
TBH there are other python REST frameworks, but none that seems integratable for mailman3 the way falcon is.
[Embedded sources and static linking]
This package does not contain embedded library sources.
This package does not statically link to libraries.
No Go package
[Security]
I can confirm that there seems to be no CVE/Security history for this package.
It Does not:
- run a daemon as root
- uses old webkit
- uses lib*v8 directly
- open a port
- uses centralized online accounts
- integrates arbitrary javascript into the desktop
- deals with system authentication
But it does:
- processes arbitrary web (REST) content
- parse data formats
This is a helper (framework) to provide REST APIs in python which by nature are processing external data.
Therefore a security review is recommended.
[Common blockers]
- builds fine at the moment
- server Team committed to subscribe once this gets promoted (enough for now)
- code is not user visible, no translation needed
- dh_python is used
- package produces python2 bits, but they are not pulled into main by mailman3
- utilizes build time self tests
[Packaging red flags]
- no current ubuntu Delta to evaluate
- no library with classic symbol tracking
- watch file is present
- Lintian warnings are present but ok
- debian/rules is rather clean
- no usage of Built-Using
- no golang package that would make things harder
[Upstream red flags]
- no suspicious errors during build (a few warnings, but nothing concerning)
- it is pure python, so no incautious use of malloc/sprintf
- no use of sudo, gksu
- no use of pkexec
- no use of LD_LIBRARY_PATH
- no important open bugs
- no Dependency on webkit, qtwebkit, libgoa-*
- no embedded copies in upstream either
[Summary]
Ack from the MIR-Teams POV, but as outlined above a security review is recommended.
Assigning the security Team.