This does need a security review, so I'll assign ubuntu-security
Two notes that do not need to block MIR:
1. As upstream has released v0.7.0 (over 1 month ago), Debian
should update to that version sometime soon, and try to stay up to
date with upstream.
2. It would be good to create a simple autopkgtest that just runs the
build tests.
[Duplication]
OK:
- There is no other package in main providing the same functionality.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- does have build deps in universe, but all binary deps in main
- no -dev/-debug/-doc packages that need exclusion
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
[Security]
OK:
- history of CVEs does not look concerning
- only 1 CVE with very quick upstream resolution
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- 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)
Problems:
- does parse data formats
- the purpose of the package is to provide a python lib to perform
signing and encryption on Javascript objects
[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error (verified by forcing failure in a test)
- The package has a team bug subscriber (Openstack team)
- no translation present, but none needed for this case (not user visible)
- no new python2 dependency
- Python package that is using dh-python
- not Go package
Problems:
- does not have a test suite that runs as autopkgtest
- running the build tests in an autopkgtest would be ideal, but I do not think is
required, as there is only 1 binary dep that would cause reverse-depends
autopkgtest run.
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is good
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- N/A, since there are no Ubuntu changes
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using
- not Go Package
Problems:
- Debian update history is sporadic
- Debian updates in the past have skipped upstream releases, e.g.
changelog shows no Debian update between v0.4.2 and v0.6.0
- However, current Debian code is relatively recent, though it
would be good for Debian to move up to v0.7.0 which was released
upstream last month
- I do not think this should block MIR (see next item)
- the current release is not packaged
- as noted above, current upstream release is v0.7.0, which was recently
released (Feb 19, 2020); Debian is up to date with the previous
release, v0.6.0.
- There are only 19 changes between v0.6.0 and v0.7.0 upstream, and
most of them are trivial fixes. So, since v0.7.0 was released quite
recently, and the changes are mostly minor, I don't think upgrading
to v0.7.0 is a requirement for MIR, but it would be good to see
Debian upgrade to v0.7.0 soon.
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks
[Summary]
MIR ack, with 2 notes below.
This does need a security review, so I'll assign ubuntu-security
Two notes that do not need to block MIR:
1. As upstream has released v0.7.0 (over 1 month ago), Debian
should update to that version sometime soon, and try to stay up to
date with upstream.
2. It would be good to create a simple autopkgtest that just runs the
build tests.
[Duplication]
OK:
- There is no other package in main providing the same functionality.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- does have build deps in universe, but all binary deps in main
- no -dev/-debug/-doc packages that need exclusion
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
[Security]
OK:
- history of CVEs does not look concerning
- only 1 CVE with very quick upstream resolution
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- 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)
Problems:
- does parse data formats
- the purpose of the package is to provide a python lib to perform
signing and encryption on Javascript objects
[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error (verified by forcing failure in a test)
- The package has a team bug subscriber (Openstack team)
- no translation present, but none needed for this case (not user visible)
- no new python2 dependency
- Python package that is using dh-python
- not Go package
Problems:
- does not have a test suite that runs as autopkgtest
- running the build tests in an autopkgtest would be ideal, but I do not think is
required, as there is only 1 binary dep that would cause reverse-depends
autopkgtest run.
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is good
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- N/A, since there are no Ubuntu changes
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using
- not Go Package
Problems:
- Debian update history is sporadic
- Debian updates in the past have skipped upstream releases, e.g.
changelog shows no Debian update between v0.4.2 and v0.6.0
- However, current Debian code is relatively recent, though it
would be good for Debian to move up to v0.7.0 which was released
upstream last month
- I do not think this should block MIR (see next item)
- the current release is not packaged
- as noted above, current upstream release is v0.7.0, which was recently
released (Feb 19, 2020); Debian is up to date with the previous
release, v0.6.0.
- There are only 19 changes between v0.6.0 and v0.7.0 upstream, and
most of them are trivial fixes. So, since v0.7.0 was released quite
recently, and the changes are mostly minor, I don't think upgrading
to v0.7.0 is a requirement for MIR, but it would be good to see
Debian upgrade to v0.7.0 soon.
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks