Comment 1 for bug 1820223

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

[Duplication]
No duplication of that functionality in the Archive in general or main in particular.

[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
- integrates arbitrary javascript into the desktop
- processes arbitrary web content
- parse data formats
- deals with system authentication
- uses centralized online accounts

[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
- does utilize 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
- 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

Of some concern is, that upstream considers itself discontinued https://github.com/uri-templates/uritemplate-py/
It links to https://github.com/python-hyper/uritemplate now which has newer releases.
Since no alternative is packaged yet that is no show stopper, but it should be evaluated.

[Summary]
Ack from the MIR-Teams POV, as outlined above a security review is not needed in this case.
Note: As outlined above I'd ask the server Team to take a look at how doable (or not) refreshing the package with a shift to the new upstream repo would be.
(A task has been added to the teams list tracking mailman3 activities)