On Nov 23, 2016 2:21 PM, <carlosg(a)gnome.org> wrote:
wrote:
the
tracker-extract may
be expected to open() potentially untrusted files,
tracker-miner-fs merely opens private tracker files, and all basic
filesystem data extraction is performed through the
opendir/stat/inotify_add_watch syscalls, what is exactly insecure in there?
Sorry, maybe I misunderstood what a "miner" is. What I mean is: disable
anything that tries to parse file contents. Presumably this means
tracker-extract.
Yes, why is then all of Tracker on the spotlight?
there is nothing insecure in tracker design to consider its miners an
inherent security risk.
Yes there is. It opens files that may be drive-by downloads and parses
And here we jump to judging all of Tracker again... No, read again what I wrote:
"There is nothing insecure in tracker design to consider its miners an inherent
security risk"
There is nothing specific in Tracker *design* about opening files, at all. Tracker is a
semantic database with a focus on local access/content, period. Your gripe happens to be
against a certain implementation of these "miners" populating this database, and
you keep mistaking the part with the whole.
So, again, there is no justification to consider every other Tracker component just as
insecure in this regard.
them with code that was never designed witg security in mind, is
written in
memory-unsafe languages, isn't sandboxed, and apparently loads plugins.
* Memory-unsafe languages: Sure, the same memory-unsafe language your kernel is written
in, or your pid 1, or your graphics server... Factoring out per-mimetype extraction
specifics, tracker-extract is actually dead simple: 1) pick unprocessed file uri, 2)
"extract metadata" black box, 3) send metadata to the tracker-store process via
dbus. Do you really think the language of choice matters much here...?
* not sandboxed: granted, as said flatpak integration is being planned. You're welcome
to join!
* loads plugins: Wrong, tracker-extract uses a very restricted set of modules, loaded from
a very specific directory. One of them happens to use gstreamer (the de-facto media
library on linux, you know), which as it turns out is *a lot* happier than tracker-extract
at opening plugins. I tbh wonder why aren't we debating about the future of
gstreamer1-plugins-bad, or why users of the gstreamer library can't whitelist the
trusted modules to load.
This is every bit as bad as all the crapy wormable antivirus systems on
Windows that Google has been busy poking holes in.
contents
Full-text search is not mandatory. Nautilus works without it.
ever
means
applications useless based on... not exactly sure what.
The applications that depend on tracker-extract are depending on wildly
insecure code that exposes a huge attack surface. This is IMO not okay.
It sounds grandiloquent at least!
Cheers,
Carlos