On Mon, 5 Dec 2016 13:44:40 +0000 Sam Thursfield <sss...@gmail.com> wrote:
> The design of Tracker takes the risks into account. Metadata > extraction is isolated in its own process (tracker-extract) which can > crash without (theoretically) causing any harm. I don't see how that helps against security vulnerabilities. Having an isolated process probably helps in a way that a crash won't cause the whole tracker service to malfunction. Thus parsing broken files won't cause a service disruption. But as long as this process runs with normal user rights this doesn't protect in a security sense. > > I think there needs to be a wider discussion about this and the > > fundamental design choices done here need to be questioned. > > What questions do you have in particular? Quite frankly, I don't claim to have all the answers here, that's why I formulated it in an open "needs discussion" way. I think sandboxing the tracker parser (which you already indicated in your mail) is probably the most reasonable way to go forward. This isn't exactly my area of expertise, so I can't comment on which technique here is most promising. The other issue I think is that the quality of huge parts of the foss ecosystem needs to be improved. The good news here is that we got some powerful tools in terms of fuzzing (afl, libfuzzer) and memory safety bug detection (asan) in the past years. Ideally all free software devs should be aware of those tools and use them in their development process. I'm trying to help here where I can, see e.g. also my recent post on this list [1]. If our libraries would be better tested we could be more comfortable feeding it with untrusted inputs. [1] https://www.mail-archive.com/desktop-devel-list@gnome.org/msg28161.html -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list