F24 GStreamer zero day

[Michael Catanzaro]

Hi,

Is anybody working on fixing [1]?

The exploit is a little impractical in that it only works if you have
not updated any F24 base packages except GStreamer, but we should still
fix it. I don't see any GStreamer updates in bodhi yet.

Michael

[1]
http://arstechnica.com/security/2016/11/elegant-0day-unicorn-underscores-...

[Sérgio Basto]

On Ter, 2016-11-22 at 18:57 -0600, Michael Catanzaro wrote:
>  Hi,
>  
>  Is anybody working on fixing [1]?
>  
>  The exploit is a little impractical in that it only works if you have
>  not updated any F24 base packages except GStreamer, but we should
>  still
>  fix it. I don't see any GStreamer updates in bodhi yet. 
for gstreamer 
https://bugzilla.redhat.com/show_bug.cgi?id=1395128
https://bugzilla.redhat.com/show_bug.cgi?id=1395768
https://bugzilla.redhat.com/show_bug.cgi?id=1397064

for gstreamer1 
https://bugzilla.redhat.com/show_bug.cgi?id=1397065
https://bugzilla.redhat.com/show_bug.cgi?id=1395769

but no commits in scm yet 


>  Michael
>  
>  [1] http://arstechnica.com/security/2016/11/elegant-0day-unicorn-unde
>  rscores-serious-concerns-about-linux-security/
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 
-- 
Sérgio M. B.

[Florian Weimer]

On 11/23/2016 02:15 AM, Sérgio Basto wrote:
>  On Ter, 2016-11-22 at 18:57 -0600, Michael Catanzaro wrote:
> > Hi,
> >
> > Is anybody working on fixing [1]?
> >
> > The exploit is a little impractical in that it only works if you have
> > not updated any F24 base packages except GStreamer, but we should
> > still
> > fix it. I don't see any GStreamer updates in bodhi yet.
>
>  for gstreamer
>  https://bugzilla.redhat.com/show_bug.cgi?id=1395128
>  https://bugzilla.redhat.com/show_bug.cgi?id=1395768
>  https://bugzilla.redhat.com/show_bug.cgi?id=1397064
>
>  for gstreamer1
>  https://bugzilla.redhat.com/show_bug.cgi?id=1397065
>  https://bugzilla.redhat.com/show_bug.cgi?id=1395769
>
>  but no commits in scm yet 
What about the larger picture?  Can tracker be made optional again for 
the GNOME desktop?

Thanks,
Florian

[Peter Robinson]

> >> Hi,
> >>
> >> Is anybody working on fixing [1]?
> >>
> >> The exploit is a little impractical in that it only works if you have
> >> not updated any F24 base packages except GStreamer, but we should
> >> still
> >> fix it. I don't see any GStreamer updates in bodhi yet.
> >
> >
> > for gstreamer
> > https://bugzilla.redhat.com/show_bug.cgi?id=1395128
> > https://bugzilla.redhat.com/show_bug.cgi?id=1395768
> > https://bugzilla.redhat.com/show_bug.cgi?id=1397064
> >
> > for gstreamer1
> > https://bugzilla.redhat.com/show_bug.cgi?id=1397065
> > https://bugzilla.redhat.com/show_bug.cgi?id=1395769
> >
> > but no commits in scm yet
>
>
>  What about the larger picture?  Can tracker be made optional again for the
>  GNOME desktop? 
It wouldn't be hard to do by splitting the tracker libs out to a sub
package but the last time I attempted to achieve that I got push back.

Peter

[Michael Catanzaro]

On Wed, 2016-11-23 at 09:39 +0100, Florian Weimer wrote:
>  
>  What about the larger picture?  Can tracker be made optional again
>  for 
>  the GNOME desktop?
>  
>  Thanks,
>  Florian 
No, many of our core applications depend on tracker to be able to see
files, and others (e.g. nautilus) use tracker to make search not take
forever. I don't think we'll support running without tracker anytime
soon. If someone wants to work on splitting little-used GStreamer
plugins into subpackages or sandboxing tracker miners (e.g. maybe with
SELinux?) that would be a more practical way forward.

Anyway, let's also mention the bright side of this: Chris says Fedora
is now way harder to exploit than Ubuntu, thanks to our new hardening
flags. So kudos to the folks who pushed that forward recently.

Michael

[Hans de Goede]

Hi,

On 23-11-16 15:36, Michael Catanzaro wrote:
>  On Wed, 2016-11-23 at 09:39 +0100, Florian Weimer wrote:
> >
> > What about the larger picture?  Can tracker be made optional again
> > for
> > the GNOME desktop?
> >
> > Thanks,
> > Florian
>
>  No, many of our core applications depend on tracker to be able to see
>  files, and others (e.g. nautilus) use tracker to make search not take
>  forever. 
I don't think that is entirely true. I've recently been trying
to get gnome3 to run on under-powered machines like cheap ARM
tablets, and I can do "dnf remove tracker" more or less just
fine, I loose totem due to some weird dependency chain, and I
think also gnome-documents which I guess is an issue for some
use-cases, but most of gnome will stay and work just fine.

>  I don't think we'll support running without tracker anytime
>  soon. 
I think that is rather short sighted, although tracker overall
does well with not hogging the system it is still simply too
heavy for some systems, both in memory use and in generated
IOs, take e.g. GNOME3 on a raspberry pi running from a sdcard,
there you really don't want tracker, so if you say:

"I don't think we'll support running without tracker anytime
soon."

I read:

"I don't think we will have a usable GNOME3 on the Raspberry
Pi anytime soon."

Regards,

Hans

[Michael Catanzaro]

On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote:
>  I don't think that is entirely true. I've recently been
> trying
>  to get gnome3 to run on under-powered machines like cheap ARM
>  tablets, and I can do "dnf remove tracker" more or less just
>  fine, I loose totem due to some weird dependency chain, and I
>  think also gnome-documents which I guess is an issue for some
>  use-cases, but most of gnome will stay and work just fine. 
Besides those, also gnome-photos and gnome-music (which aren't
installed by default currently, but will eventually be). And indexed
search is really very important for nautilus.

Michael

[Andrew Lutomirski]

On Nov 23, 2016 10:12 AM, "Michael Catanzaro" <mcatanzaro(a)gnome.org&gt;
wrote:
>  On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote:
>  > I don't think that is entirely true. I've recently been trying
>  > to get gnome3 to run on under-powered machines like cheap ARM
>  > tablets, and I can do "dnf remove tracker" more or less just
>  > fine, I loose totem due to some weird dependency chain, and I
>  > think also gnome-documents which I guess is an issue for some
>  > use-cases, but most of gnome will stay and work just fine.
>
>  Besides those, also gnome-photos and gnome-music (which aren't
>  installed by default currently, but will eventually be). And indexed
>  search is really very important for nautilus. 
That's indexed search by *name*, right?  I can't imagine *any* reason that
running a codec in the indexer is needed for nautilus.

--Andy

[Adam Williamson]

On Wed, 2016-11-23 at 10:33 -0800, Andrew Lutomirski wrote:
>  On Nov 23, 2016 10:12 AM, "Michael Catanzaro"
> <mcatanzaro(a)gnome.org&gt; wrote:
>  > 
>  > On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote:
>  > > I don't think that is entirely true. I've recently been trying
>  > > to get gnome3 to run on under-powered machines like cheap ARM
>  > > tablets, and I can do "dnf remove tracker" more or less just
>  > > fine, I loose totem due to some weird dependency chain, and I
>  > > think also gnome-documents which I guess is an issue for some
>  > > use-cases, but most of gnome will stay and work just fine.
>  > 
>  > Besides those, also gnome-photos and gnome-music (which aren't
>  > installed by default currently, but will eventually be). And indexed
>  > search is really very important for nautilus.
>  
>  That's indexed search by *name*, right?  I can't imagine *any* reason that
>  running a codec in the indexer is needed for nautilus. 
"I want to find all the files I have that are songs by Justin Bieber,
so I can shoot them into outer space".
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Chris Murphy]

On Wed, Nov 23, 2016 at 10:36 AM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Wed, 2016-11-23 at 10:33 -0800, Andrew Lutomirski wrote:
> > On Nov 23, 2016 10:12 AM, "Michael Catanzaro" <mcatanzaro(a)gnome.org&gt;
> wrote:
> > >
> > > On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote:
> > > > I don't think that is entirely true. I've recently been trying
> > > > to get gnome3 to run on under-powered machines like cheap ARM
> > > > tablets, and I can do "dnf remove tracker" more or less just
> > > > fine, I loose totem due to some weird dependency chain, and I
> > > > think also gnome-documents which I guess is an issue for some
> > > > use-cases, but most of gnome will stay and work just fine.
> > >
> > > Besides those, also gnome-photos and gnome-music (which aren't
> > > installed by default currently, but will eventually be). And indexed
> > > search is really very important for nautilus.
> >
> > That's indexed search by *name*, right?  I can't imagine *any* reason that
> > running a codec in the indexer is needed for nautilus.
>
>  "I want to find all the files I have that are songs by Justin Bieber,
>  so I can shoot them into outer space". 
Pretty sure such metadata is a function of the container format, e.g.
mp4, m4a, rather than the codec used for encoding the music or video
itself.

-- 
Chris Murphy

[Stephen John Smoogen]

On 23 November 2016 at 14:03, Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Wed, Nov 23, 2016 at 10:36 AM, Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
> > On Wed, 2016-11-23 at 10:33 -0800, Andrew Lutomirski wrote:
> >> On Nov 23, 2016 10:12 AM, "Michael Catanzaro"
> <mcatanzaro(a)gnome.org&gt; wrote:
> >> >
> >> > On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote:
> >> > > I don't think that is entirely true. I've recently been trying
> >> > > to get gnome3 to run on under-powered machines like cheap ARM
> >> > > tablets, and I can do "dnf remove tracker" more or less just
> >> > > fine, I loose totem due to some weird dependency chain, and I
> >> > > think also gnome-documents which I guess is an issue for some
> >> > > use-cases, but most of gnome will stay and work just fine.
> >> >
> >> > Besides those, also gnome-photos and gnome-music (which aren't
> >> > installed by default currently, but will eventually be). And indexed
> >> > search is really very important for nautilus.
> >>
> >> That's indexed search by *name*, right?  I can't imagine *any* reason
> that
> >> running a codec in the indexer is needed for nautilus.
> >
> > "I want to find all the files I have that are songs by Justin Bieber,
> > so I can shoot them into outer space".
>
>  Pretty sure such metadata is a function of the container format, e.g.
>  mp4, m4a, rather than the codec used for encoding the music or video
>  itself. 
It might be but because most people tie those two things together when
they are writing code.. they get bundled together. This is why codecs
have been such a rich target in Windows (and in some ways Mac) malware
over the years. You get two channels to build an exploit for free :).

>  --
>  Chris Murphy
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Bastien Nocera]

----- Original Message -----
>  On 23 November 2016 at 14:03, Chris Murphy
> <lists(a)colorremedies.com&gt; wrote:
>  > On Wed, Nov 23, 2016 at 10:36 AM, Adam Williamson
>  > <adamwill(a)fedoraproject.org&gt; wrote:
>  >> On Wed, 2016-11-23 at 10:33 -0800, Andrew Lutomirski wrote:
>  >>> On Nov 23, 2016 10:12 AM, "Michael Catanzaro"
> <mcatanzaro(a)gnome.org&gt;
>  >>> wrote:
>  >>> >
>  >>> > On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote:
>  >>> > > I don't think that is entirely true. I've recently been
> trying
>  >>> > > to get gnome3 to run on under-powered machines like cheap ARM
>  >>> > > tablets, and I can do "dnf remove tracker" more or less
> just
>  >>> > > fine, I loose totem due to some weird dependency chain, and I
>  >>> > > think also gnome-documents which I guess is an issue for some
>  >>> > > use-cases, but most of gnome will stay and work just fine.
>  >>> >
>  >>> > Besides those, also gnome-photos and gnome-music (which aren't
>  >>> > installed by default currently, but will eventually be). And indexed
>  >>> > search is really very important for nautilus.
>  >>>
>  >>> That's indexed search by *name*, right?  I can't imagine *any*
> reason
>  >>> that
>  >>> running a codec in the indexer is needed for nautilus.
>  >>
>  >> "I want to find all the files I have that are songs by Justin Bieber,
>  >> so I can shoot them into outer space".
>  >
>  > Pretty sure such metadata is a function of the container format, e.g.
>  > mp4, m4a, rather than the codec used for encoding the music or video
>  > itself.
>  
>  It might be but because most people tie those two things together when
>  they are writing code.. they get bundled together. This is why codecs
>  have been such a rich target in Windows (and in some ways Mac) malware
>  over the years. You get two channels to build an exploit for free :). 
They're not bundled together. Especially seeing as the popular filetypes
have codecs depending on patents whereas the container formats don't.

We've been able to tell you how long your DivX or MPEG-4 files were,
out-of-the-box, on Fedora, for years. We just can't play them out-of-the-box.

[Carlos Garnacho]

Hi Hans,

(Talking with my Tracker maintainer hat)

>  Hi,
>  
>  On 23-11-16 15:36, Michael Catanzaro wrote:
>  
>  I don't think that is entirely true. I've recently been trying
>  to get gnome3 to run on under-powered machines like cheap ARM
>  tablets, and I can do "dnf remove tracker" more or less just
>  fine, I loose totem due to some weird dependency chain, and I
>  think also gnome-documents which I guess is an issue for some
>  use-cases, but most of gnome will stay and work just fine.
>  
>  
>  I think that is rather short sighted, although tracker overall
>  does well with not hogging the system it is still simply too
>  heavy for some systems, both in memory use and in generated
>  IOs, take e.g. GNOME3 on a raspberry pi running from a sdcard,
>  there you really don't want tracker, so if you say: 
I can see how Tracker's extra involved I/O may become noticeable in such hw/scenarios
(mainly coming from tracker-miner-fs I presume), it roots in inotify being notoriously bad
for indexers...

But memory, I beg to differ :). Running on massif a from-scratch indexing of this
laptop's homedir, tracker-store peaks at 16MB and runs under half of that for 67/69
snapshots. tracker-miner-fs peaks at 13MB and sits on half of that afterwards.

In short only tracker-extract is "expected" to misbehave memory-wise (due to
third party libraries, bugs, leaks in those, ...). The other daemons are rather moderate
in memory consumption, although maybe seen over the "I can do without this"
prism, sure looks like a waste ;).

Worth pointing out too, tracker-extract had for years a hard memory limit, so if anything
asked too much memory, tracker-extract would crash and be eventually (re)started at some
point. I ended up removing it because the many bogus retrace reports, the many "it
didn't index this super-important file" complains and because some file/library
combinations actually needed more memory than given (poppler, if you wonder). If a library
leaks or allocates too much memory, it's a bug in the library and should be fixed
there, or so I thought :).

>  
>  "I don't think we'll support running without tracker anytime
>  soon."
>  
>  I read:
>  
>  "I don't think we will have a usable GNOME3 on the Raspberry
>  Pi anytime soon." 
Tracker comes from the mobile world, it has been used several times there with success,
and has a number of gsettings that allow it to accommodate to very different workloads
(most of them sacrificing instantness for reduced resources). But Tracker is, by default,
optimized for the desktop.

It would be nice if Tracker worked better out of the box on those setups, however I'd
rather put all my fish on the "fix file notification" pan, as that's IMHO
the key to making Tracker a single size for all.

Cheers,
  Carlos

[Florian Weimer]

On 11/23/2016 10:15 PM, carlosg(a)gnome.org wrote:

>  But memory, I beg to differ :). Running on massif a from-scratch
> indexing of this laptop's homedir, tracker-store peaks at 16MB and runs under half of
> that for 67/69 snapshots. tracker-miner-fs peaks at 13MB and sits on half of that
> afterwards. 
What about the impact on kernel caches?  The additional activity will 
evict things which would otherwise be used by foreground processes.

Thanks,
Florian

[Carlos Garnacho]

>  On 11/23/2016 10:15 PM, carlosg(a)gnome.org wrote:
>  
>  
>  What about the impact on kernel caches?  The additional activity will 
>  evict things which would otherwise be used by foreground processes. 
Tracker processes call sched_setscheduler/ioprio/nice to lower their priorities to a
minimum, that's as educated as you can get from userspace. And anyway...
tracker-miner-fs sits idle 99% of the time, every activity is punctual and finite, but of
course dependent on your own activity in the inspected folders.

Cheers,
  Carlos

[Florian Weimer]

On 11/24/2016 11:27 AM, Carlos Garnacho wrote:
> > On 11/23/2016 10:15 PM, carlosg(a)gnome.org wrote:
> >
> >
> > What about the impact on kernel caches?  The additional activity will
> > evict things which would otherwise be used by foreground processes.
>
>  Tracker processes call sched_setscheduler/ioprio/nice to lower their priorities to a
> minimum, that's as educated as you can get from userspace. 
I don't think this has any impact on caches.

I'm not even sure how effective cgroups would be to make sure that the 
indexing activity doesn't disturb the rest of the system.

Florian

[Hans de Goede]

Hi,

On 23-11-16 22:15, carlosg(a)gnome.org wrote:
>  Hi Hans,
>
>  (Talking with my Tracker maintainer hat)
>
> > Hi,
> >
> > On 23-11-16 15:36, Michael Catanzaro wrote:
> >
> > I don't think that is entirely true. I've recently been trying
> > to get gnome3 to run on under-powered machines like cheap ARM
> > tablets, and I can do "dnf remove tracker" more or less just
> > fine, I loose totem due to some weird dependency chain, and I
> > think also gnome-documents which I guess is an issue for some
> > use-cases, but most of gnome will stay and work just fine.
> >
> >
> > I think that is rather short sighted, although tracker overall
> > does well with not hogging the system it is still simply too
> > heavy for some systems, both in memory use and in generated
> > IOs, take e.g. GNOME3 on a raspberry pi running from a sdcard,
> > there you really don't want tracker, so if you say:
>
>  I can see how Tracker's extra involved I/O may become noticeable in such hw/scenarios
> (mainly coming from tracker-miner-fs I presume), it roots in inotify being notoriously bad
> for indexers... 
The problem we've at the moment is basically that we perform
pretty poorly on resource constrained devices, part of that
is a shitload of running services (on a 512MB device I need
to disable gdm and use startx because running gdm +
gnome-shell together results in swapping which is very
painful on a sdcard).

My "solution" for that is to just dnf remove a whole bunch
of stuff, tracker only being one of them.

I must admit I've never noticed a problem specifically caused
by tracker, the whole experience just sucks, so I've pretty
much been disabling everything I can.

I would prefer a better solution, but given how very bad sdcards
typically are at random access, something like tracker really
_might_ be a problem.

Question which directories does tracker actually scan / monitor by
default ?

>  But memory, I beg to differ :). Running on massif a from-scratch
> indexing of this laptop's homedir, tracker-store peaks at 16MB and runs under half of
> that for 67/69 snapshots. tracker-miner-fs peaks at 13MB and sits on half of that
> afterwards.
>
>  In short only tracker-extract is "expected" to misbehave memory-wise (due to
> third party libraries, bugs, leaks in those, ...). The other daemons are rather moderate
> in memory consumption, although maybe seen over the "I can do without this"
> prism, sure looks like a waste ;).
>
>  Worth pointing out too, tracker-extract had for years a hard memory limit, so if anything
> asked too much memory, tracker-extract would crash and be eventually (re)started at some
> point. I ended up removing it because the many bogus retrace reports, the many "it
> didn't index this super-important file" complains and because some file/library
> combinations actually needed more memory than given (poppler, if you wonder). If a library
> leaks or allocates too much memory, it's a bug in the library and should be fixed
> there, or so I thought :). 
Is that memory limit still there, but configurable and disabled
now, or ?

Can we re-instantiate it ? I would really like to be able
to offer close to the full gnome3 experience on resource
constrained devices, so I'm wondering if tracker can be
configured to behave a bit nicer there. Maybe we can even
get it to autodetect such systems. E.g. re-instate the
hardlimit on systems with less then 1GB of RAM ?

Regards,

Hans




> >
> > "I don't think we'll support running without tracker anytime
> > soon."
> >
> > I read:
> >
> > "I don't think we will have a usable GNOME3 on the Raspberry
> > Pi anytime soon."
>
>  Tracker comes from the mobile world, it has been used several times there with success,
> and has a number of gsettings that allow it to accommodate to very different workloads
> (most of them sacrificing instantness for reduced resources). But Tracker is, by default,
> optimized for the desktop.
>
>  It would be nice if Tracker worked better out of the box on those setups, however I'd
> rather put all my fish on the "fix file notification" pan, as that's IMHO
> the key to making Tracker a single size for all.

[Carlos Garnacho]

Hi,

>  Hi,
>  
>  On 23-11-16 22:15, carlosg(a)gnome.org wrote:
>  
>  The problem we've at the moment is basically that we perform
>  pretty poorly on resource constrained devices, part of that
>  is a shitload of running services (on a 512MB device I need
>  to disable gdm and use startx because running gdm +
>  gnome-shell together results in swapping which is very
>  painful on a sdcard). 
Oh, sure. Obviously the mobile scenarios I'm talking about didn't have that many
processes running, nor multi-user setups. However, this is not a Tracker problem per se,
rather a general one about minimum required memory to run a multi-user ready full-blown
gnome desktop.

>  
>  My "solution" for that is to just dnf remove a whole bunch
>  of stuff, tracker only being one of them.
>  
>  I must admit I've never noticed a problem specifically caused
>  by tracker, the whole experience just sucks, so I've pretty
>  much been disabling everything I can. 
Well, if you concretize and turn into upstream bugs, I'll look into it. That's all
I can tell :).

>  
>  I would prefer a better solution, but given how very bad sdcards
>  typically are at random access, something like tracker really
>  _might_ be a problem.
>  
>  Question which directories does tracker actually scan / monitor by
>  default ? 
XDG folders recursively, $HOME non-recursively. This is all configurable in the privacy
pane in the control-center fwiw.

>  
>  
>  Is that memory limit still there, but configurable and disabled
>  now, or ?
>  
>  Can we re-instantiate it ? I would really like to be able
>  to offer close to the full gnome3 experience on resource
>  constrained devices, so I'm wondering if tracker can be
>  configured to behave a bit nicer there. Maybe we can even
>  get it to autodetect such systems. E.g. re-instate the
>  hardlimit on systems with less then 1GB of RAM ? 
It can be restablished, I'm not sure you'd enjoy the extra abrtd activity when
tracker-extract "crashes" though :/, unless you disabled that too, that is...

I guess I can make it check low-resources scenarios and try to do the best out of the box
wrt i/o and cpu. But memory-wise I still think the best I can do is valgrinding the hell
out of it, and file bugs to leaky libraries [1], as I've done over the years.

Cheers,
  Carlos

[1] https://bugzilla.gnome.org/show_bug.cgi?id=748608 comes to mind

[Matthew Miller]

On Thu, Nov 24, 2016 at 11:02:19AM -0000, Carlos Garnacho wrote:
>  > Question which directories does tracker actually scan / monitor
> by
>  > default ?
>  XDG folders recursively, $HOME non-recursively. This is all
>  configurable in the privacy pane in the control-center fwiw. 
It doesn't seem to be -- I see Screen Lock, Location Services, Usage &
History, Purge Trash, and Problem Reporting. I have to to install
tracker-preferences to get a GUI for these settings, as far as I can
see.




-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Mathieu Bridon]

On Thu, 2016-11-24 at 12:09 -0500, Matthew Miller wrote:
>  On Thu, Nov 24, 2016 at 11:02:19AM -0000, Carlos Garnacho wrote:
>  > > Question which directories does tracker actually scan / monitor
>  > > by default ?
>  > 
>  > XDG folders recursively, $HOME non-recursively. This is all
>  > configurable in the privacy pane in the control-center fwiw.
>  
>  It doesn't seem to be -- I see Screen Lock, Location Services, Usage
>  & History, Purge Trash, and Problem Reporting. I have to to install
>  tracker-preferences to get a GUI for these settings, as far as I can
>  see. 
It's configurable in the Search panel of the control center.

(the gear icon in the bottom right)


-- 
Mathieu

[Matthew Miller]

On Thu, Nov 24, 2016 at 07:05:38PM +0100, Mathieu Bridon wrote:
>  > > XDG folders recursively, $HOME non-recursively. This is
> all
>  > > configurable in the privacy pane in the control-center fwiw.
>  > It doesn't seem to be -- I see Screen Lock, Location Services, Usage
>  > & History, Purge Trash, and Problem Reporting. I have to to install
>  > tracker-preferences to get a GUI for these settings, as far as I can
>  > see.
>  It's configurable in the Search panel of the control center.
>  (the gear icon in the bottom right) 
Cool, thanks. That's probably more obvious than Privacy anyway. :)

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Carlos Garnacho]

>  On Thu, Nov 24, 2016 at 11:02:19AM -0000, Carlos Garnacho wrote:
>  
>  It doesn't seem to be -- I see Screen Lock, Location Services, Usage &
>  History, Purge Trash, and Problem Reporting. I have to to install
>  tracker-preferences to get a GUI for these settings, as far as I can
>  see. 
Oh, I said privacy, I meant search:
Control-center > search > gear button

The folders that are being indexed can be configured in that dialog.

Cheers,
  Carlos

[Andrew Lutomirski]

On Nov 23, 2016 6:37 AM, "Michael Catanzaro" <mcatanzaro(a)gnome.org&gt;
wrote:
>  or sandboxing tracker miners (e.g. maybe with
>  SELinux?) that would be a more practical way forward. 
This seems like it would be a fantastic use of the infrastructure behind
xdg-app.

[Carlos Garnacho]

Hi,
>  
>  This seems like it would be a fantastic use of the infrastructure behind
>  xdg-app. 
Fwiw, better flatpak integration was already on the top of the goal list for Tracker.
Ideally ready for 1.12 if time allows.

Cheers,
  Carlos

[Stephen John Smoogen]

On 23 November 2016 at 09:36, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  On Wed, 2016-11-23 at 09:39 +0100, Florian Weimer wrote:
> >
> > What about the larger picture?  Can tracker be made optional again
> > for
> > the GNOME desktop?
> >
> > Thanks,
> > Florian
>
>  No, many of our core applications depend on tracker to be able to see
>  files, and others (e.g. nautilus) use tracker to make search not take
>  forever. I don't think we'll support running without tracker anytime
>  soon. If someone wants to work on splitting little-used GStreamer
>  plugins into subpackages or sandboxing tracker miners (e.g. maybe with
>  SELinux?) that would be a more practical way forward. 
In that case, I expect that we are going to be doing cleanups over and
over again. Because while this time it is Gstreamer it could have been
any one of the myriad other helpers pulled in.  The bigger problem is
that the two major defenses of ALSR and DEP can be gotten past. That
will have effects on any security decisions that have thought "too
hard to do realistically so we rely on that".




-- 
Stephen J Smoogen.

[Andrew Lutomirski]

On Nov 23, 2016 8:11 AM, "Stephen John Smoogen" <smooge(a)gmail.com&gt; wrote:
>  On 23 November 2016 at 09:36, Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
wrote:
>  > On Wed, 2016-11-23 at 09:39 +0100, Florian Weimer wrote:
>  >>
>  >> What about the larger picture?  Can tracker be made optional again
>  >> for
>  >> the GNOME desktop?
>  >>
>  >> Thanks,
>  >> Florian
>  >
>  > No, many of our core applications depend on tracker to be able to see
>  > files, and others (e.g. nautilus) use tracker to make search not take
>  > forever. I don't think we'll support running without tracker anytime
>  > soon. If someone wants to work on splitting little-used GStreamer
>  > plugins into subpackages or sandboxing tracker miners (e.g. maybe with
>  > SELinux?) that would be a more practical way forward.
>
>  In that case, I expect that we are going to be doing cleanups over and
>  over again. Because while this time it is Gstreamer it could have been
>  any one of the myriad other helpers pulled in.  The bigger problem is
>  that the two major defenses of ALSR and DEP can be gotten past. That
>  will have effects on any security decisions that have thought "too
>  hard to do realistically so we rely on that".
>
>  
Can we leave tracker enabled but disable literally every miner?  AFAIK the
mandatory uses of tracker only care about filenames and don't need contents
at all.

I would go even farther and argue that Fedora should not, by default, ever
enable a miner that isn't running in *strict* seccomp mode.  If that means
that cat pictures aren't identified as such, so be it.  And if it means
that several Fedora releases go by with a less functional search, that's
fine too.

--Andy

[Carlos Garnacho]

Hi,

>  On Nov 23, 2016 8:11 AM, "Stephen John Smoogen"
> <smooge(a)gmail.com&gt; wrote:
>  wrote:
>  
>  Can we leave tracker enabled but disable literally every miner?  AFAIK the 
That is literally, overreacting. Of all tracker processes, only 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?

Sure, tracker-extract depends on "untrusted" 3rd party libraries, but there is
nothing insecure in tracker design to consider its miners an inherent security risk.

>  mandatory uses of tracker only care about filenames and don't
> need contents
>  at all. 
Not true, full-text search works over more than filenames.

>  
>  I would go even farther and argue that Fedora should not, by default, ever
>  enable a miner that isn't running in *strict* seccomp mode.  If that means
>  that cat pictures aren't identified as such, so be it.  And if it means
>  that several Fedora releases go by with a less functional search, that's
>  fine too. 
*points to the written above*, you're talking about rendering entire applications
useless based on... not exactly sure what.

Cheers,
  Carlos

[Andrew Lutomirski]

On Nov 23, 2016 2:21 PM, <carlosg(a)gnome.org&gt; wrote:
>  Hi,
>
>  > On Nov 23, 2016 8:11 AM, "Stephen John Smoogen"
> <smooge(a)gmail.com&gt; 
wrote:
>  > wrote:
>  >
>  > Can we leave tracker enabled but disable literally every miner?  AFAIK 
the
>  That is literally, overreacting. Of all tracker processes, only 
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.

>  Sure, tracker-extract depends on "untrusted" 3rd party libraries, but
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
them with code that was never designed witg security in mind, is written in
memory-unsafe languages, isn't sandboxed, and apparently loads plugins.

This is every bit as bad as all the crapy wormable antivirus systems on
Windows that Google has been busy poking holes in.

>  > mandatory uses of tracker only care about filenames and don't need
contents
>  > at all.
>
>  Not true, full-text search works over more than filenames. 
Full-text search is not mandatory.  Nautilus works without it.

>  >
>  > I would go even farther and argue that Fedora should not, by default, 
ever
>  > enable a miner that isn't running in *strict* seccomp mode. 
> If that 
means
>  > that cat pictures aren't identified as such, so be it.  And
> if it means
>  > that several Fedora releases go by with a less functional search, that's
>  > fine too.
>
>  *points to the written above*, you're talking about rendering entire
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.

[Andrew Lutomirski]

On Wed, Nov 23, 2016 at 2:58 PM, Andrew Lutomirski <luto(a)mit.edu&gt; wrote:
> >
> > >
> > > I would go even farther and argue that Fedora should not, by default,
> > > ever
> > > enable a miner that isn't running in *strict* seccomp mode.  If that
> > > means
> > > that cat pictures aren't identified as such, so be it.  And if it means
> > > that several Fedora releases go by with a less functional search, that's
> > > fine too.
> >
> > *points to the written above*, you're talking about rendering entire
> > 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. 
Fixing this shouldn't even be hard.  It could be done like this:

Version A: Instead of having tracker-extract be a dbus service that
extracts directly, have it run tracker-extract once per file.  Rather
than passing in the file by name, though, pass it as an fd and run
tracker-extract in a context in which it has read-only access to /usr
and /etc and has nothing else in its namespace.

Version B: Have tracker-extract fork and open the file.  Before
reading it at all, though, it heavily sandboxes itself such that it
can't use the filesystem.  Then it extracts the file and exits.

It may be that tracker-extract the service is already forking once per
file, in which case these reduce to more or less the same thing.

And I really would argue that Fedora should turn off tracker-extract
by default until something like this gets done.  The current state of
affairs is, in my opinion, unacceptably dangerous.

[Carlos Garnacho]

>  On Nov 23, 2016 2:21 PM, <carlosg(a)gnome.org&gt; 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

[Andrew Lutomirski]

On Wed, Nov 23, 2016 at 5:03 PM, Carlos Garnacho <carlosg(a)gnome.org&gt; wrote:
>  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. 
I'm objecting to whatever piece of software opens thoroughly untrusted
files out of ~/Downloads and parses them.  If that's not "Tracker",
then I apologize.

>  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. 
Firefox is a big piece of code that loads untrusted stuff.  It's
written in a memory-unsafe language, and there's a big team working on
fixing that.  It's not sandboxed, and there's a project to fix that.
And it's still a major attack vector, but at least it has a very
serious security team.

The fact that flatpak integration is being planned is great.  I hope
that flatpak has an exceedingly strict mode for applications like
this.

Tracker is just as exposed as Firefox because it (or some piece of it
or whatever) parses stuff in Downloads.

[Carlos Garnacho]

Hi,

>  On Wed, Nov 23, 2016 at 5:03 PM, Carlos Garnacho
> <carlosg(a)gnome.org&gt; wrote:
>  
>  I'm objecting to whatever piece of software opens thoroughly untrusted
>  files out of ~/Downloads and parses them.  If that's not "Tracker",
>  then I apologize.
>  
>  
>  Firefox is a big piece of code that loads untrusted stuff.  It's
>  written in a memory-unsafe language, and there's a big team working on
>  fixing that.  It's not sandboxed, and there's a project to fix that.
>  And it's still a major attack vector, but at least it has a very
>  serious security team. 
Sounds great, do they also get the blame for gstreamer bugs? I've got lots of fun so
share ;). 

According to you Firefox is just as insecure, and I can tell that Firefox uses GStreamer
to open untrusted content over the internet. Why downloading the file at all, you could be
tricked into a webpage that auto-plays the infected content, it could even be an ad
unbeknownst by the site, you got every bit as infected and Tracker wasn't involved,
using the exact piece of sofware as attack vector that we're talking nowadays.

Actually, nice comparison, Tracker and Firefox share 90% of the underlying 3rd party
libraries to implement support for every format (jpegs, gifs, pdfs, videos, you name it),
whatever security bug is found in those libraries will affect Firefox and Tracker
equally.

And as for the projects themselves, Tracker is a fraction of Firefox in terms of code
size, and tracker-extract inside Tracker is another fraction. That makes a whole lot
difference between auditing or securing a *web engine* and a process that essentially
iterates over files. Why is Firefox then any more credible? Must be the serious looks of
their security team.

>  
>  The fact that flatpak integration is being planned is great.  I hope
>  that flatpak has an exceedingly strict mode for applications like
>  this.
>  
>  Tracker is just as exposed as Firefox because it (or some piece of it
>  or whatever) parses stuff in Downloads. 
Tracker-extract is not as exposed as Firefox, because the file needs being in the local
filesystem for starters. The web world is well known for figuratively throwing 3rd party
media content to your face, even in otherwise trusted websites.

Anyway, the dead horse took its beating, things won't get done just talking, I'm
back to work.

Cheers,
  Carlos

[Michael Catanzaro]

On Thu, 2016-11-24 at 10:02 +0000, Carlos Garnacho wrote:
>  Tracker-extract is not as exposed as Firefox, because the file needs
>  being in the local filesystem for starters. The web world is well
>  known for figuratively throwing 3rd party media content to your face,
>  even in otherwise trusted websites. 
I think the concern here is that browsers allow websites to download
files to your computer without any user interaction. Epiphany goes as
far as to open them automatically. I've never previously considered
that it's a security risk, simply because attacking an unsandboxed web
engine seems like a much easier attack vector, but maybe we should
think about changing this behavior.

That said, we cannot stop running tracker on ~/Downloads because we
want to show downloaded files in our core apps. Similarly, we're going
to be processing the files with thumbnailers like the totem thumbnailer
as well. Even if we sandbox tracker-extract, that does nothing to avoid
bugs that exploit the thumbnailer, so we should really be looking at
GStreamer-level mitigation anyway.

Michael

[Lars Seipel]

On Thu, Nov 24, 2016 at 09:03:24AM -0600, Michael Catanzaro wrote:
>  On Thu, 2016-11-24 at 10:02 +0000, Carlos Garnacho wrote:
>  > Tracker-extract is not as exposed as Firefox, because the file needs
>  > being in the local filesystem for starters. The web world is well
>  > known for figuratively throwing 3rd party media content to your face,
>  > even in otherwise trusted websites.
>  
>  I think the concern here is that browsers allow websites to download
>  files to your computer without any user interaction. Epiphany goes as
>  far as to open them automatically. I've never previously considered
>  that it's a security risk, […] 
What does that mean, exactly? Does it pass the downloaded file to
xdg-open or equivalent? Just because you clicked on a link on some
website, no matter the file type and association involved? Seriously?

[Michael Catanzaro]

On Fri, 2016-11-25 at 01:46 +0100, Lars Seipel wrote:
>  What does that mean, exactly? Does it pass the downloaded file to
>  xdg-open or equivalent? 
"or equivalent" -- it uses Gio and not xdg-open

>   Just because you clicked on a link on some
>  website, no matter the file type and association involved? Seriously? 
Actually there is a list of "safe" MIME types in Epiphany, and the file
is only opened if shared-mime-info thinks it's of a "safe" type. It
*should* be hard to exploit shared-mime-info, so that's fine... but the
safe list is pretty big and nobody has been maintaining it.

Michael

[Andrew Lutomirski]

On Nov 24, 2016 2:03 AM, "Carlos Garnacho" <carlosg(a)gnome.org&gt; wrote:
>  Hi,
>
>  > On Wed, Nov 23, 2016 at 5:03 PM, Carlos Garnacho <carlosg(a)gnome.org&gt;
wrote:
> >  
>  > I'm objecting to whatever
> piece of software opens thoroughly untrusted
>  > files out of ~/Downloads and parses them.  If that's not "Tracker",
>  > then I apologize.
> >  
> >  
>  > Firefox is a big piece of code
> that loads untrusted stuff.  It's
>  > written in a memory-unsafe language, and there's a big team working on
>  > fixing that.  It's not sandboxed, and there's a project to fix that.
>  > And it's still a major attack vector, but at least it has a very
>  > serious security team.
>
>  Sounds great, do they also get the blame for gstreamer bugs? I've got 
lots of
fun so share ;).
>  According to you Firefox is just as insecure, and I can tell that Firefox 
uses
GStreamer to open untrusted content over the internet. Why downloading
the file at all, you could be tricked into a webpage that auto-plays the
infected content, it could even be an ad unbeknownst by the site, you got
every bit as infected and Tracker wasn't involved, using the exact piece of
sofware as attack vector that we're talking nowadays.

Because Firefox doesn't allow all of the GStreamer content types.  And
Firefox has its own mp4 container parser written in Rust these days, I
think.

IOW they admit its a problem and they've made it better.

>  And as for the projects themselves, Tracker is a fraction of Firefox in 
terms of
code size, and tracker-extract inside Tracker is another fraction.
That makes a whole lot difference between auditing or securing a *web
engine* and a process that essentially iterates over files. Why is Firefox
then any more credible? Must be the serious looks of their security team.

If a distro didn't provide a browser by default, no one would notice.  If a
distro didn't index media metadata in Downloads by default, I suspect most
users wouldn't even notice.

> >  
>  > The fact that flatpak integration is being planned is
> great.  I hope
>  > that flatpak has an exceedingly strict mode for applications like
>  > this.
> >  
>  > Tracker is just as exposed as Firefox because it (or some
> piece of it
>  > or whatever) parses stuff in Downloads.
>
>  Tracker-extract is not as exposed as Firefox, because the file needs 
being in the
local filesystem for starters. The web world is well known for
figuratively throwing 3rd party media content to your face, even in
otherwise trusted websites.
>  
Then at *least* stop indexing Downloads by default.

My point is that the default tracker configuration is wildly insecure and
it could be improved quite easily.

[Kevin Kofler]

Florian Weimer wrote:
>  What about the larger picture?  Can tracker be made optional again
> for
>  the GNOME desktop? 
Tracker is just a red herring. GStreamer flaws can be exploited directly in 
any browser that actually uses GStreamer, e.g., all the WebKit (WebKitGtk, 
QtWebKit, but not Blink/Chromium) ones, KHTML, etc. For Chromium/Chrome, you 
only have to go through the download autosaving misfeature and Tracker 
because Chromium/Chrome does not use GStreamer. These flaws are much more 
critical than people seem to think!

        Kevin Kofler

[Richard W.M. Jones]

On Wed, Nov 23, 2016 at 09:39:03AM +0100, Florian Weimer wrote:
>  On 11/23/2016 02:15 AM, Sérgio Basto wrote:
>  >On Ter, 2016-11-22 at 18:57 -0600, Michael Catanzaro wrote:
>  >>Hi,
>  >>
>  >>Is anybody working on fixing [1]?
>  >>
>  >>The exploit is a little impractical in that it only works if you have
>  >>not updated any F24 base packages except GStreamer, but we should
>  >>still
>  >>fix it. I don't see any GStreamer updates in bodhi yet.
>  >
>  >for gstreamer
>  >https://bugzilla.redhat.com/show_bug.cgi?id=1395128
>  >https://bugzilla.redhat.com/show_bug.cgi?id=1395768
>  >https://bugzilla.redhat.com/show_bug.cgi?id=1397064
>  >
>  >for gstreamer1
>  >https://bugzilla.redhat.com/show_bug.cgi?id=1397065
>  >https://bugzilla.redhat.com/show_bug.cgi?id=1395769
>  >
>  >but no commits in scm yet
>  
>  What about the larger picture?  Can tracker be made optional again
>  for the GNOME desktop? 
I have this in my .bashrc:

# Kill with fire.
killall -9 -r tracker-.* >& /dev/null

Seems to be the only way to permanently disable it that I have found
(I'm not using GNOME).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Sérgio Basto]

On Ter, 2016-11-29 at 14:24 +0000, Richard W.M. Jones wrote:
>  On Wed, Nov 23, 2016 at 09:39:03AM +0100, Florian Weimer wrote:
>  > 
>  > On 11/23/2016 02:15 AM, Sérgio Basto wrote:
>  > > 
>  > > On Ter, 2016-11-22 at 18:57 -0600, Michael Catanzaro wrote:
>  > > > 
>  > > > Hi,
>  > > > 
>  > > > Is anybody working on fixing [1]?
>  > > > 
>  > > > The exploit is a little impractical in that it only works if
>  > > > you have
>  > > > not updated any F24 base packages except GStreamer, but we
>  > > > should
>  > > > still
>  > > > fix it. I don't see any GStreamer updates in bodhi yet.
>  > > for gstreamer
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=1395128
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=1395768
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=1397064
>  > > 
>  > > for gstreamer1
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=1397065
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=1395769
>  > > 
>  > > but no commits in scm yet
>  > What about the larger picture?  Can tracker be made optional again
>  > for the GNOME desktop?
>  I have this in my .bashrc:
>  
>  # Kill with fire.
>  killall -9 -r tracker-.* >& /dev/null
>  
>  Seems to be the only way to permanently disable it that I have found
>  (I'm not using GNOME). 
I use 
rpm -e tracker.x86_64  --nodeps

>  Rich.
>   
-- 
Sérgio M. B.

[Ahmad Samir]

On 29 November 2016 at 16:24, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Wed, Nov 23, 2016 at 09:39:03AM +0100, Florian Weimer wrote:
> > On 11/23/2016 02:15 AM, Sérgio Basto wrote:
> > >On Ter, 2016-11-22 at 18:57 -0600, Michael Catanzaro wrote:
> > >>Hi,
> > >>
> > >>Is anybody working on fixing [1]?
> > >>
> > >>The exploit is a little impractical in that it only works if you have
> > >>not updated any F24 base packages except GStreamer, but we should
> > >>still
> > >>fix it. I don't see any GStreamer updates in bodhi yet.
> > >
> > >for gstreamer
> > >https://bugzilla.redhat.com/show_bug.cgi?id=1395128
> > >https://bugzilla.redhat.com/show_bug.cgi?id=1395768
> > >https://bugzilla.redhat.com/show_bug.cgi?id=1397064
> > >
> > >for gstreamer1
> > >https://bugzilla.redhat.com/show_bug.cgi?id=1397065
> > >https://bugzilla.redhat.com/show_bug.cgi?id=1395769
> > >
> > >but no commits in scm yet
> >
> > What about the larger picture?  Can tracker be made optional again
> > for the GNOME desktop?
>
>  I have this in my .bashrc:
>
>  # Kill with fire.
>  killall -9 -r tracker-.* >& /dev/null
>
>  Seems to be the only way to permanently disable it that I have found
>  (I'm not using GNOME).
>
>  Rich. 
On F25 (not sure about older releases), on can mask the tracker
systemd user service(s):
# cd /etc/systemd/user/
# for i in $(rpm -ql tracker | grep systemd.*.service); do ln -s
/dev/null $(basename $i); done

the tracker processes won't get started the next time you log in.

-- 
Ahmad Samir

[Ahmad Samir]

On 30 November 2016 at 23:19, Ahmad Samir <ahmadsamir3891(a)gmail.com&gt; wrote:
>  On 29 November 2016 at 16:24, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
> > On Wed, Nov 23, 2016 at 09:39:03AM +0100, Florian Weimer wrote:
> >> On 11/23/2016 02:15 AM, Sérgio Basto wrote:
> >> >On Ter, 2016-11-22 at 18:57 -0600, Michael Catanzaro wrote:
> >> >>Hi,
> >> >>
> >> >>Is anybody working on fixing [1]?
> >> >>
> >> >>The exploit is a little impractical in that it only works if you have
> >> >>not updated any F24 base packages except GStreamer, but we should
> >> >>still
> >> >>fix it. I don't see any GStreamer updates in bodhi yet.
> >> >
> >> >for gstreamer
> >> >https://bugzilla.redhat.com/show_bug.cgi?id=1395128
> >> >https://bugzilla.redhat.com/show_bug.cgi?id=1395768
> >> >https://bugzilla.redhat.com/show_bug.cgi?id=1397064
> >> >
> >> >for gstreamer1
> >> >https://bugzilla.redhat.com/show_bug.cgi?id=1397065
> >> >https://bugzilla.redhat.com/show_bug.cgi?id=1395769
> >> >
> >> >but no commits in scm yet
> >>
> >> What about the larger picture?  Can tracker be made optional again
> >> for the GNOME desktop?
> >
> > I have this in my .bashrc:
> >
> > # Kill with fire.
> > killall -9 -r tracker-.* >& /dev/null
> >
> > Seems to be the only way to permanently disable it that I have found
> > (I'm not using GNOME).
> >
> > Rich.
>
>  On F25 (not sure about older releases), on can mask the tracker
>  systemd user service(s):
>  # cd /etc/systemd/user/
>  # for i in $(rpm -ql tracker | grep systemd.*.service); do ln -s
>  /dev/null $(basename $i); done
>
>  the tracker processes won't get started the next time you log in.
>  
This doesn't work if one uses startx to log in instead of logging in
via a graphical display manager; in that case this seems to work:
$ mkdir -p ~/.local/share/dbus-1/services
$ cd ~/.local/share/dbus-1/services
$ cp /usr/share/dbus-1/services/*Tracker* .
$ perl -p -i -e 's!Exec=.*!Exec=/bin/false!' *Tracker*

-- 
Ahmad Samir

[Michael Catanzaro]

On Wed, 2016-11-23 at 01:15 +0000, Sérgio Basto wrote:
>  for gstreamer 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1395128
>  https://bugzilla.redhat.com/show_bug.cgi?id=1395768
>  https://bugzilla.redhat.com/show_bug.cgi?id=1397064
>  
>  for gstreamer1 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1397065
>  https://bugzilla.redhat.com/show_bug.cgi?id=1395769
>  
>  but no commits in scm yet  
For the record: it's been one week since this zero-day was published,
and so far there has been action on only one of those five bug reports.
It illustrates our typical problem that nobody handles security updates
when the Fedora maintainer is not watching Bugzilla.

Michael

[Stephen John Smoogen]

On 29 November 2016 at 13:26, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  On Wed, 2016-11-23 at 01:15 +0000, Sérgio Basto wrote:
> > for gstreamer
> > https://bugzilla.redhat.com/show_bug.cgi?id=1395128
> > https://bugzilla.redhat.com/show_bug.cgi?id=1395768
> > https://bugzilla.redhat.com/show_bug.cgi?id=1397064
> >
> > for gstreamer1
> > https://bugzilla.redhat.com/show_bug.cgi?id=1397065
> > https://bugzilla.redhat.com/show_bug.cgi?id=1395769
> >
> > but no commits in scm yet
>
>  For the record: it's been one week since this zero-day was published,
>  and so far there has been action on only one of those five bug reports.
>  It illustrates our typical problem that nobody handles security updates
>  when the Fedora maintainer is not watching Bugzilla.
>  
I went to look up what the state of the bug was upstream and while
this one seemed closed the amount of bugs in red coloured NEW status
in the GNOME bugzilla when searching for gstreamer didn't say things
were any better over there.

In any case, here are the two people who need to be bugged to give
some sort of answer..

[2016-11-29-13:31] <smooge> whoowns gstreamer
[2016-11-29-13:31] <zodbot> company
[2016-11-29-13:31] <smooge> whoowns gstreamer1
[2016-11-29-13:31] <zodbot> bpepple
[2016-11-29-13:31] <smooge> .fasinfo company
[2016-11-29-13:31] <zodbot> User: company, Name: Benjamin Otte, email:
otte(a)redhat.com, Creation: 2010-01-11, IRC Nick: Company, Timezone:
Europe/Berlin, Locale: en, GPG key ID: , Status: active
[2016-11-29-13:31] <zodbot> Approved Groups: fedorabugs cla_redhat
cla_done packager
[2016-11-29-13:31] <smooge> .fasinfo bpepple
[2016-11-29-13:31] <zodbot> User: bpepple, Name: Brian Pepple, email:
bdpepple(a)gmail.com, Creation: 2005-04-13, IRC Nick: bpepple, Timezone:
US/Eastern, Locale: en, GPG key ID: 810CC15E, Status: active
[2016-11-29-13:31] <zodbot> Approved Groups: cla_done fedorabugs
@packager ambassadors cla_fedora @provenpackager cla_fpca

>  Michael
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

[Michael Stahl]

On 23.11.2016 01:57, Michael Catanzaro wrote:
>  Hi,
>  
>  Is anybody working on fixing [1]?
>  
>  The exploit is a little impractical in that it only works if you have
>  not updated any F24 base packages except GStreamer, but we should still
>  fix it. I don't see any GStreamer updates in bodhi yet. 
on a related note, i notice that i have this package installed, which i
haven't requested to be installed:

> > rpm -qa | grep gstreamer1-plugins
>  gstreamer1-plugins-base-devel-1.8.3-1.fc24.x86_64
>  gstreamer1-plugins-bad-free-1.8.3-1.fc24.x86_64
>  gstreamer1-plugins-good-1.8.3-1.fc24.x86_64
>  gstreamer1-plugins-base-1.8.3-1.fc24.x86_64 
> > dnf -C info gstreamer1-plugins-bad-free
>  Last metadata expiration check: 0:57:12 ago on Wed Nov 23 10:44:37 2016.
>  Installed Packages
>  Name        : gstreamer1-plugins-bad-free
>  Arch        : x86_64
>  Epoch       : 0
>  Version     : 1.8.3
>  Release     : 1.fc24
>  Size        : 5.4 M
>  Repo        : @System
>  From repo   : updates
>  Summary     : GStreamer streaming media framework "bad" plugins
>  URL         : http://gstreamer.freedesktop.org/
>  License     : LGPLv2+ and LGPLv2
>  Description : GStreamer is a streaming media framework, based on graphs of
>              : elements which operate on media data.
>              : 
>              : This package contains plug-ins that aren't tested well enough, or
>              : the code is not of good enough quality. 
so to their credit the upstream authors in this case are honest enough
that their C code is full of holes and shouldn't be used by anybody;
however:

> > dnf remove gstreamer1-plugins-bad-free
>  Dependencies resolved.
>  ================================================================================
>   Package                           Arch   Version           Repository     Size
>  ================================================================================
>  Removing:
>   PackageKit-Qt5                    x86_64 0.9.5-6.fc24      @@commandline 330 k
>   appstream                         x86_64 0.9.8-3.fc24      @updates      670 k
>   appstream-qt                      x86_64 0.9.8-3.fc24      @updates       92 k
>   breeze-cursor-theme               noarch 5.7.5-1.fc24      @updates       11 M
>   cheese                            x86_64 2:3.20.2-1.fc24   @@commandline 406 k
>   cln                               x86_64 1.3.4-4.fc24      @@commandline 1.5 M
>   empathy                           x86_64 3.12.12-2.fc24    @updates       15 M
>   f23-backgrounds-kde               noarch 23.1.0-2.fc24     @@commandline 211
>   f23-kde-theme                     noarch 23.0-6.fc24       @@commandline 4.4 M
>   f24-backgrounds-kde               noarch 24.1.2-1.fc24     @@commandline 211
>   f24-kde-theme                     noarch 24.5-1.fc24       @@commandline 2.4 M
>   f24-kde-theme-core                x86_64 5.7.5-2.fc24      @updates      169 k
>   farstream02                       x86_64 0.2.7-3.fc24      @@commandline 695 k
>   gnome-dvb-daemon                  x86_64 0.2.91-0.2.20160917git2d32148.fc24
>                                                              @updates      2.1 M
>   gstreamer1-plugins-bad-free       x86_64 1.8.3-1.fc24      @updates      5.4 M
>   gstreamer1-rtsp-server            x86_64 1.8.3-1.fc24      @updates      361 k
>   hplip-gui                         x86_64 3.16.10-1.fc24    @updates      2.1 M
>   kactivitymanagerd                 x86_64 5.7.5-1.fc24      @updates      682 k
>   kde-cli-tools                     x86_64 5.7.5-1.fc24      @updates      3.4 M
>   kde-settings-plasma               noarch 24-7.fc24         @updates      3.4 k
>   kdecoration                       x86_64 5.7.5-1.fc24      @updates      185 k
>   kf5-bluez-qt                      x86_64 5.27.0-1.fc24     @updates      700 k
>   kf5-frameworkintegration          x86_64 5.27.0-1.fc24     @updates      1.6 M
>   kf5-frameworkintegration-libs     x86_64 5.27.0-1.fc24     @updates       66 k
>   kf5-kactivities-stats             x86_64 5.27.0-1.fc24     @updates      290 k
>   kf5-kdnssd                        x86_64 5.27.0-1.fc24     @updates      247 k
>   kf5-kdoctools                     x86_64 5.27.0-1.fc24     @updates      2.2 M
>   kf5-kemoticons                    x86_64 5.27.0-1.fc24     @updates      2.2 M
>   kf5-kholidays                     x86_64 16.08.2-1.fc24    @updates      708 k
>   kf5-kjsembed                      x86_64 5.27.0-1.fc24     @updates      1.7 M
>   kf5-kpeople                       x86_64 5.27.0-1.fc24     @updates      465 k
>   kf5-kwayland                      x86_64 5.27.0-1.fc24     @updates      1.3 M
>   kf5-kxmlrpcclient                 x86_64 5.27.0-1.fc24     @updates      123 k
>   kf5-networkmanager-qt             x86_64 5.27.0-1.fc24     @updates      1.3 M
>   khotkeys                          x86_64 5.7.5-1.fc24      @updates      2.3 M
>   kio-extras                        x86_64 16.08.2-1.fc24    @updates      1.9 M
>   kmenuedit                         x86_64 5.7.5-1.fc24      @updates      1.5 M
>   konsole5                          x86_64 16.08.2-1.fc24    @updates      474 k
>   konsole5-part                     x86_64 16.08.2-1.fc24    @updates      1.4 M
>   kscreenlocker                     x86_64 5.7.5-1.fc24      @updates      669 k
>   kwin                              x86_64 5.7.5-1.fc24      @updates       67 k
>   kwin-common                       x86_64 5.7.5-1.fc24      @updates       13 M
>   kwin-libs                         x86_64 5.7.5-1.fc24      @updates      4.2 M
>   kwrited                           x86_64 5.7.5-1.fc24      @updates       55 k
>   libkscreen-qt5                    x86_64 5.7.5-1.fc24      @updates      926 k
>   libkworkspace5                    x86_64 5.7.5-2.fc24      @updates      194 k
>   libpurple                         x86_64 2.11.0-1.fc24     @@commandline  29 M
>   libqalculate                      x86_64 0.9.7-17.fc24     @@commandline 5.5 M
>   oxygen-fonts                      x86_64 5.4.3-2.fc24      @@commandline   0
>   oxygen-sound-theme                noarch 5.7.5-1.fc24      @updates      1.9 M
>   plasma-breeze                     x86_64 5.7.5-1.fc24      @updates      1.1 M
>   plasma-breeze-common              noarch 5.7.5-1.fc24      @updates       10 M
>   plasma-desktop                    x86_64 5.7.5-1.fc24      @updates       27 M
>   plasma-discover                   x86_64 5.7.5-1.fc24      @updates      781 k
>   plasma-discover-libs              x86_64 5.7.5-1.fc24      @updates      2.1 M
>   plasma-integration                x86_64 5.7.5-1.fc24      @updates      316 k
>   plasma-milou                      x86_64 5.7.5-1.fc24      @updates      265 k
>   plasma-pa                         x86_64 5.7.5-1.fc24      @updates      648 k
>   plasma-systemsettings             x86_64 5.7.5-1.fc24      @updates      945 k
>   plasma-workspace                  x86_64 5.7.5-2.fc24      @updates       19 M
>   plasma-workspace-common           x86_64 5.7.5-2.fc24      @updates       44 k
>   plasma-workspace-drkonqi          x86_64 5.7.5-2.fc24      @updates      4.8 M
>   plasma-workspace-geolocation      x86_64 5.7.5-2.fc24      @updates      169 k
>   plasma-workspace-geolocation-libs x86_64 5.7.5-2.fc24      @updates       40 k
>   plasma-workspace-libs             x86_64 5.7.5-2.fc24      @updates      6.0 M
>   polkit-kde                        x86_64 5.7.5-1.fc24      @updates      245 k
>   powerdevil                        x86_64 5.7.5-1.fc24      @updates      2.1 M
>   python-qt5-rpm-macros             noarch 5.6-4.fc24        @updates      137
>   python3-qt5                       x86_64 5.6-4.fc24        @updates       22 M
>   qt5-qdbusviewer                   x86_64 5.6.1-2.fc24      @updates      133 k
>   qt5-qtconnectivity                x86_64 5.6.1-2.fc24      @updates      1.3 M
>   qt5-qtenginio                     x86_64 1:1.6.1-2.fc24    @updates      589 k
>   qt5-qtgraphicaleffects            x86_64 5.6.1-1.fc24      @updates      1.9 M
>   qt5-qtimageformats                x86_64 5.6.1-1.fc24      @updates      348 k
>   qt5-qtmultimedia                  x86_64 5.6.1-3.fc24      @updates      3.1 M
>   qt5-qtwebsockets                  x86_64 5.6.1-2.fc24      @updates      230 k
>   scim-libs                         x86_64 1.4.17-1.fc24     @@commandline 1.1 M
>   telepathy-farstream               x86_64 0.6.1-7.fc24      @@commandline 195 k
>   telepathy-haze                    x86_64 0.8.0-3.fc22      @System       231 k
>   totem                             x86_64 1:3.20.1-1.fc24   @@commandline 7.4 M
>   totem-nautilus                    x86_64 1:3.20.1-1.fc24   @@commandline  31 k
>   xcb-util-cursor                   x86_64 0.1.2-3.fc24      @@commandline  27 k
>  
>  Transaction Summary
>  ================================================================================
>  Remove  82 Packages
>  
>  Installed size: 242 M
>  Is this ok [y/N]: 
looks like both core Gnome apps and Qt5/KDE have apparently managed to
grow dependencies on the toxic codecs.

[Kevin Kofler]

Michael Stahl wrote:
>  looks like both core Gnome apps and Qt5/KDE have apparently managed
> to
>  grow dependencies on the toxic codecs. 
The thing is, they both need only one or two of the offending codecs (not 
necessarily the same ones). In the Plasma case, the dependency is kwin → 
qt5-qtmultimedia → libgstphotography-1.0.so.0. If that were moved to a 
dedicated subpackage, we would avoid dragging in the whole set.

But still, GStreamer upstream's approach of "oh, those plugins are bad, 
don't use them, we don't care about their security" does not work at all. 
People WILL end up installing them no matter what we do (even if we don't 
package them at all, they will surely spring up in Copr/OBS/wherever), and 
an attack can be as simple as visiting a web page. Upstream really needs to 
audit ALL plugins for security.

        Kevin Kofler

[Matthew Miller]

On Tue, Nov 22, 2016 at 06:57:45PM -0600, Michael Catanzaro wrote:
>  Is anybody working on fixing [1]?
>  The exploit is a little impractical in that it only works if you have
>  not updated any F24 base packages except GStreamer, but we should still
>  fix it. I don't see any GStreamer updates in bodhi yet. 
I talked to Josh Bressers a little bit about it, and he was going to
bring the bigger issue to Eric and the Fedora Security Team — with the
holidays that might not be happening immediately. That is, the issues
here
https://scarybeastsecurity.blogspot.com/2016/11/0day-poc-risky-design-dec...
with sandboxing tracker and gstreamer, and installing the "bad" codecs
without warning.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader