[MIR] marisa

Bug #1914808 reported by Gunnar Hjalmarsson
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
marisa (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

* Availability

It's available on the Ubuntu supported architectures
https://bugs.launchpad.net/ubuntu/+source/marisa/0.2.6-3~exp2ubuntu1

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://security-tracker.debian.org/tracker/source-package/marisa
https://people.canonical.com/~ubuntu-security/cve/pkg/marisa.html
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=marisa

* Quality assurance

The desktop team is going to subscribe to the package

https://launchpad.net/ubuntu/+source/marisa/+bugs
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=marisa

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
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (3.2 KiB)

[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...

Read more...

Changed in marisa (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks for the review, Christian!

On 2021-02-08 13:42, Christian Ehrhardt  wrote:
> Recommended TODOs:
> - upstream provides tests in test/*, could those be enabled at build
> time?

As far as I can see they are already enabled via dh_auto_test. From the amd64 build log:

PASS: io-test
PASS: trie-test
PASS: base-test
PASS: vector-test
PASS: marisa-test
============================================================================
Testsuite summary for marisa 0.2.6
============================================================================
# TOTAL: 5
# PASS: 5
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0

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

Indeed Gunnar (seb128 gave me the same hint).
I was distracted by the full page of no-tests entries after dh_auto_test , but you are right it is there.
One todo gone, yet we still wait for security.

Revision history for this message
Seth Arnold (seth-arnold) wrote :
Revision history for this message
Seth Arnold (seth-arnold) wrote :

I reviewed marisa 0.2.6-3~exp2ubuntu2 as checked into hirsute. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

marisa is a trie-based datastructure. There's both a library package and
command line interfaces as well as bindings for ruby, python, and perl.

- CVE History:
  - None in our database
- Build-Depends?
  - chrpath, debhelper-compat, dh-python, perl, pkg-kde-tools,
    python3-all-dev, ruby, ruby-dev, swig
- pre/post inst/rm scripts?
  - automatically-added python stuff
- init scripts?
  - None
- systemd units?
  - None
- dbus services?
  - None
- setuid binaries?
  - None
- binaries in PATH?
  -rwxr-xr-x root/root ./usr/bin/marisa-benchmark
  -rwxr-xr-x root/root ./usr/bin/marisa-build
  -rwxr-xr-x root/root ./usr/bin/marisa-common-prefix-search
  -rwxr-xr-x root/root ./usr/bin/marisa-dump
  -rwxr-xr-x root/root ./usr/bin/marisa-lookup
  -rwxr-xr-x root/root ./usr/bin/marisa-predictive-search
  -rwxr-xr-x root/root ./usr/bin/marisa-reverse-lookup
- sudo fragments?
  - None
- polkit files?
  - None
- udev rules?
  - None
- unit tests / autopkgtests?
  - Pretty extensive; debian/tests/ runs some simple bindings tests, too
- cron jobs?
  - None
- Build logs:
  - Some deprecation warnings in Ruby bindings, not too bad

- Processes spawned?
  - None
- Memory management?
  - Manual-style C++ memory management; it looked good
- File IO?
  - File paths provided by clients; coverity reported a race condition
    between a stat and mmap call, minor issue
- Logging?
  - None
- Environment variable usage?
  - None
- Use of privileged functions?
  - None
- Use of cryptography / random number sources etc?
  - None
- Use of temp files?
  - None
- Use of networking?
  - None
- Use of WebKit?
  - None
- Use of PolicyKit?
  - None

- Any significant cppcheck results?
  - two false positives, nothing else
- Any significant Coverity results?
  - many false positives, one TOCTTOU bug, minor
- Any significant shellcheck results?
  - only results are in debian's tests
- Any significant bandit results?
  - None

The actual trie portion of marisa is pretty involved. We will need to rely
on upstream for support of the computational pieces. The interoperation
portions of marisa are fairly straightforward older-style C++. This
looked fine.

Security team ACK for promoting marisa to main.

Changed in marisa (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
status: New → In Progress
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks for your review, Seth! With that it will be possible to enable opencc support to ibus-libpinyin (bug #1923187).

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Override component to main
libmarisa0 0.2.6-3~exp2ubuntu2 in impish amd64: universe/libs/extra/100% -> main
libmarisa0 0.2.6-3~exp2ubuntu2 in impish arm64: universe/libs/extra/100% -> main
libmarisa0 0.2.6-3~exp2ubuntu2 in impish armhf: universe/libs/extra/100% -> main
libmarisa0 0.2.6-3~exp2ubuntu2 in impish i386: universe/libs/extra/100% -> main
libmarisa0 0.2.6-3~exp2ubuntu2 in impish ppc64el: universe/libs/extra/100% -> main
libmarisa0 0.2.6-3~exp2ubuntu2 in impish riscv64: universe/libs/extra/100% -> main
libmarisa0 0.2.6-3~exp2ubuntu2 in impish s390x: universe/libs/extra/100% -> main
Override [y|N]? y
7 publications overridden.

Changed in marisa (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.