After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764554 - tracker-1.6.2 bundles a vulnerable sqlite version
tracker-1.6.2 bundles a vulnerable sqlite version
Status: RESOLVED WONTFIX
Product: tracker
Classification: Core
Component: General
1.6.x
Other Linux
: Normal normal
: ---
Assigned To: tracker-general
tracker-general
Depends on:
Blocks:
 
 
Reported: 2016-04-03 17:50 UTC by Pacho Ramos
Modified: 2016-05-05 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Pacho Ramos 2016-04-03 17:50:32 UTC
It looks like tracker-1.6.2 started to bundle a sqlite copy to workaround its incompatibility with sqlite >= 3.11 

The problem of relying on bundled libs is that they can also contain security issues and bugs and it is harder to ensure they are solved soon enough. It's now the case with sqlite-3.12, that is solving some security issues that affect the bundled (3.11) copy: 
https://sqlite.org/src/info/424b7aee3310b978
https://sqlite.org/src/info/b8dc1b9f5d413000
https://sqlite.org/src/info/ff1b1ac3313ba9d7

With 3.12 we should be able to rely on:
https://www.sqlite.org/cgi/src/info/374b5108087a2eae

And try to patch tracker to use something like:
--- src/libtracker-fts/fts3_tokenizer.c
+++ src/libtracker-fts/fts3_tokenizer.c
@@ -332,6 +332,9 @@
   sqlite3_stmt *pStmt;
   const char zSql[] = "SELECT fts3_tokenizer(?, ?)";
 
+#ifdef SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER
+  sqlite3_db_config(db, SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER, 1, NULL);
+#endif
   rc = sqlite3_prepare_v2(db, zSql, -1, &pStmt, 0);
   if( rc!=SQLITE_OK ){
     return rc;
--- src/libtracker-fts/tracker-fts-tokenizer.c
+++ src/libtracker-fts/tracker-fts-tokenizer.c
@@ -219,6 +219,9 @@
   sqlite3_stmt *stmt;
 
   pTokenizer = &trackerTokenizerModule;
+#ifdef SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER
+  sqlite3_db_config(db, SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER, 1, NULL);
+#endif
   rc = sqlite3_prepare_v2(db, "SELECT fts3_tokenizer(?, ?)",
                           -1, &stmt, 0);
 

As we are discussing downstream at https://bugs.gentoo.org/show_bug.cgi?id=576728

Thanks
Comment 1 Debarshi Ray 2016-04-04 08:33:19 UTC
Have you seen bug 762226 ?
Comment 2 Arfrever Frehtes Taifersar Arahesis 2016-04-04 14:29:28 UTC
Yes, we have seen that bug.

Using FTS5 (as implemented in Tracker >=1.7.4) is optimal fix.

For Tracker 1.4.4 and 1.6.3, assuming that backport of usage of FTS5 is not possible, it would be better to use SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER option, which was released in SQLite 3.12.0 (and earlier backported to 3.11.0 and 3.11.1 in Gentoo).
Comment 3 Pacho Ramos 2016-04-04 18:53:05 UTC
Yes, as Arfrever reported, we checked that bug to try to find a way for fixing it for 1.6.x versions :/
Comment 4 Carlos Garnacho 2016-05-05 16:30:11 UTC
Fair points about bundling libraries. I wasn't happy myself with the choice, but it is one I'd rather not revisit... Tracker 1.6 is meant to be stable (it was stable for almost 6 months when hell broke loose), bumping dependencies to most recent sqlite and updating code to cope with incompabilities between <3.11, 3.11 and >=3.12 is not something I will consider there.

Of the three security issues you link, #1 and #2 do not affect tracker (We don't use its ICU tokenizer), #3 might but doesn't look like something as easily exploitable as to justifying the change.

I understand 1.6 may end up in LTSs and other distros that take time to catch up, I would hope that those either ship a contemporary sqlite, or compile it with -DSQLITE_ENABLE_FTS3_TOKENIZER in order to avoid breaking existing code. In the latter case, I support distros patching Tracker to drop the internal sqlite copy.

So sorry I consider Tracker 1.6 a dead horse, but 1.8 has been out for some time already, and I really don't have the attention span to beat it anymore...