[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
[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)
[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/ /github. com/python- hyper/uritempla te now which has newer releases.
It links to https:/
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)