> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
