Let's reconsider some more applications installed by default

[Michael Catanzaro]

On Sat, 2015-08-29 at 00:05 +0300, Elad Alfassa wrote:
> We can't patch Firefox without getting approval from Mozilla and
> still call it Firefox, due to trademark guidelines and such. 
> I honestly don't see what you'd put in a Firefox app menu that won't
> be duplicating what is already available within the app itself.
> I'm still not convinced we can install the theme by default. As much
> as I would like this, we have no way to guarantee the theme will keep
> being updated, we have no way to make it so it's only enabled for
> GNOME users and not for users of other desktops (it's possible to do,
> but it's not implemented yet), and we can't block critical Firefox
> updates on theme update (sometimes a .0 version of Firefox also has
> important security fixes).

All great arguments to not use Firefox. :) But I think Mozilla will
work with us to permit the changes we request. They want us to stick
with Firefox obviously, and I expect they will permit changes to make
Firefox work better in our environment. Theme maintenance, of course,
is another matter....

> You are biased, as you said before. Epiphany still has rendering
> problems in many websites,

The rendering code is actually almost all cross-platform, so such
issues usually affect Safari as well. But in practice, issues are quite
rare nowadays. I've been using Epiphany for three years now and the
progress is apparent.

>  it doesn't support privacy-enhancing extensions such as privacy
> badger and HTTPS Everywhere

I am in favor of built-in support for HTTPS Everywhere, enabled by
default, using [1]. This should be fairly easy to implement, since most
of the work is already done in [1].

I don't want to support Privacy Badger: I tried it last week and I
noticed a broken site almost immediately. The EasyPrivacy list seems to
not break things at least, so we could use that. And Firefox has a new
list (off by default and hidden) that we could use. We should look at
EasyPrivacy as the quickest step forward, since it's just a matter of
hooking it up to the existing adblock filters. This is probably just a
weekend hack; I just haven't found time recently. :(

[1] https://github.com/grindhold/libhttpseverywhere/

> , it doens't support custom adblocking lists (the default adblocking 
> list only works for global websites and not for local ad networks in 
> my country, for example!)

I agree, we need to add UI for this. In the meantime, you can create
~/.config/epiphany/filters.list containing a semicolon-separated list
of URIs (e.g. https://easylist-downloads.adblockplus.org/easylist.txt).
But that's of course not an acceptable solution we can give to users.
And it should be smart enough to pick a locale-specific blocklist
automatically.

>  it doesn't support many newer web platform APIs,

Again, we support a comparable set of features to Safari; I don't think
this is really a problem.

>  doesn't have a sync solution... the list goes on and on.
 
I agree this would be great to have.

> SELinux policy bugs are less common nowdays, indeed. This still
> doesn't mean we don't need the notifications to exist.
> (also it would be nice if SELinux could actually do more useful stuff
> such as blocking random apps like Steam or Firefox from stealing your
> SSH private key... that PDF-based attack that stole Firefox users'
> private keys could easily be mitigated by SELinux if we had a policy
> for that in place)

It would be nice to keep the notifications, but I think it's less
important than ensuring the default set of applications is reasonably
user-friendly.

> I remember this was mentioned last time we talked about default apps,
> but that was, what? a year ago? Perhaps we should do another status
> check about this.

I did. :(

> This is a severe problem that shouldn't be ignored.

But upstream is dead, so it will be ignored. :(

I also filed: https://bugzilla.gnome.org/show_bug.cgi?id=747030

In general, any application that uses libsoup directly, or uses
obsolete versions of WebKit, likely does certificate verification wrong
and should be audited to find out. Nobody is going to do that, of
course.

>  At the very least, we need to disable all social functionality in
> Shotwell until this is solved. This has serious implications on user
> safety.

+1 from me, though it might be easier to fix... anyway, note that I
haven't confirmed this to be an issue: I merely noted the quite high
probability that it is an issue.

> Also, please make sure you make it more well known next time you know
> about a (publicly known) severe security issue in one of our default
> (or commonly used) apps.

Probably should have, but I guess I am just depressingly used to such
things at this point... anyway, the certificate verification issue is
not more serious than Shotwell's use of WebKit1, which should be well
-known.

> If this was not publicly known before you mentioned this on your
> mailing list (I mean, I guess everybody knew it uses an old webkit,
> but it's possible that not everybody knew old webkit doesn't verify
> certificates), this is even worse... please make sure to responsibly
> disclose security bugs privately if this is the case.

GNOME doesn't have any policy for security bugs, nor does it have priva
te bug reports. I don't really think private reports are a good idea,
either, unless they are timed and become public automatically after a
few weeks.

> You mentioned Evolution uses an old version of webkit as well. does 
> it mean it doesn't verify certificates of resources such as images 
> that are downloaded from the web while reading an email message? This 
> kind of a severe issue needs to be fixed ASAP...

Evolution performs certificate verification correctly, to the best of
my knowledge. The issue with Evolution is that it uses an obsolete
version of WebKit that doesn't get security updates anymore. (Same
issue with Empathy and Rhythmbox and Geary. And Bijiben, but Bijiben at
least doesn't hit the network.)

Michael