Comment 1 for bug 1833745

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

[Reasoning]
So far lmdb was disabled e.g. in bind9 [2], but as outlined in the referred patch [1] this can't really be disabled in AppStream.
So lets take a look, fortunately it seems rather small.

[Duplication]
LMDB is a very thin in memory database. You'd think either of big databases which these days almost all grew in-memory features or mid sized projects like memchached.
But none of these really fits in the same size/use-as-lib/key-value-only tradeoff that LMDB tries to address.
Leveldb comes to mind [3] but that isn't in main either.

So while it feels like "oh no, another in-mem DB" I can't find something that would be a proper replacement.
Also given that bind9, postfix and appstream switched to it makes it less of a special on-off snowflake.

[Embedded sources and static linking]
- no other embedded libraries
- no static build
- no golang

[Security]
- no CVEs yet
- does not run as a daemon itself (lib)
- doesn't use webkit1,2
- doesn't use lib*v8 directly
- does not open a port
- does not processe 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)

The one usual check that applies is that to some extend it "parses data formats" when it persists and reads them from/to disk.
Also the content at least - in the use case triggering this being appstream - can be partially remote.

Further the mmapped files represent a new "attack vector" against tools using this in replacement for internal variables.
Following the "if in doubt let security check it" rule this will need a security review as well.

[Common blockers]
- no FTBFS currently
- runtime builds and runs test suite
- lib only without a lot user visible messages (no translation need)
- not a python package

The package lacks a team subscriber, some team has to step up - since driven by appstream (bug 1538293) probably the Desktop Team?

[Packaging red flags]
- no Ubuntu delta atm
- symbols file exists and it tracked
- d/watch is present
- regular updates in Debian and by Upstream (no big moves, just minor versiosn)
- the current release is packaged
- currently just a sync, so no issue for MOTUs
- only very minor lintian warnings
- d/rules fits a page and debian/* in general is rather clean
- no use of Built-Using
- no golang

[Upstream red flags]
- developed under the umbrella of the openldap project [5] by symas [4]
- some warnigns on
  Wimplicit-fallthrough
  obsolete tags
  undocumented macros
  Nothing severe
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no open important bugs in Debian or Ubuntu or Upstream
- no use of webkit, qtwebkit, seed or libgoa-*
- not in scope for the Unity Dash (or other recent UI)

[Summary]
Approved by MIR team under the two following constraints
- needs package subscriber (I susbcribed didrocks to consider it)
- needs security review

[1]: https://github.com/ximion/appstream/commit/358e9394631b87797f56dcb7e09e459b4044e631#commitcomment-33995178
[2]: https://github.com/ximion/appstream/commit/358e9394631b87797f56dcb7e09e459b4044e631#commitcomment-33995446
[3]: https://mozilla.github.io/firefox-browser-architecture/text/0017-lmdb-vs-leveldb.html
[4]: https://symas.com/lmdb/
[5]: https://github.com/openldap/openldap/tree/master/libraries/liblmdb