[MIR] marisa
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
marisa (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
* Availability
It's available on the Ubuntu supported architectures
https:/
The package was in sync until it had to be changed to accomodate the MIR requirements (the delta now is cpp symbols delta on some of the architectures since our toolchain seems to be different enough that it is required)
* Rationale
It's a depends of opencc, MIR bug #1909665
libmarisa0 is the only binary that needs to be promoted
* Security
There is no known security issues
https:/
https:/
https:/
* Quality assurance
The desktop team is going to subscribe to the package
https:/
https:/
No open reports out of the MIR and a request for the .symbols to be added in Debian
The package enables upstream tests during the build and ships autopkgtests
* Dependencies
No universe binary dependencies
Depends: libc6 (>= 2.33), libgcc-s1 (>= 3.0), libstdc++6 (>= 5.2)
* Standards compliance
current 4.5.1 standards-version, debhelper compat 13, dh style simple rules
* Maintenance
Upstream is active, the package is maintained in Debian and desktop team is going to sign up for Ubuntu
description: | updated |
[Summary]
MIR Team ack to this package.
This does need a security review, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: libmarisa0
Recommended TODOs:
- upstream provides tests in test/*, could those be enabled at build time?
[Duplication]
There is no other package in main providing the same functionality.
I mean obviously there are many data-structure helpers, but this one in
particular isn't available elsewhere. It is not a one-off just for
opencc, also librime and libkkc2 are using it which seems reasonable.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
Depends: libc6 (>= 2.33), libgcc-s1 (>= 3.0), libstdc++6 (>= 5.2)
- has libmarisa-dev which will be auto-promoted, but that has no deps
other than libmarisa0 itself
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- there are some maintenance artifacts in the tarball, but none seems
problematic and none goes into the binaries that we will promote.
[Security]
OK:
- history of CVEs does not look concerning
- 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 and translate them into the data structures this
provides. This would usually be done in the context of the user-input which
doesn't sound like a very critical attach surface. OTOH I don't want to hear
that e.g. all Ubuntu input boxes can be broken by a special input string or
such. Therefore I think it is worth to pass this through a security review
as well.
[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs as autopkgtest
- The package has a team bug subscriber (an intend-to-sub by the Desktop Team)
- no translation present, but this is not the Ui but a background feature
- not a python/go package, no extra constraints to consider in that regard
Problems:
- does not have a test suite that runs at build time
But I think that is covered by the autopkgtests, never the less there is an
upstream provided test collection, having that on build would be awesome.
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place (the version we have synced from
experimental contains it)
- d/watch is present and looks ok
- Upstream update history slow, but ok (seems more stable than a lack of attention)
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- Does not have Built-Using
Problems:
- d/rules isn't the cleanest, but nothing that would block this
[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 Ubunt...