Let's reconsider some more applications installed by default

[Elad Alfassa]

On Fri, Aug 28, 2015 at 11:39 PM, Michael Catanzaro <mcatanzaro at gnome.org>
wrote:

> On Fri, 2015-08-28 at 22:38 +0300, Elad Alfassa wrote:
> > I don't see how "adding an app menu" would make Evolution any better.
> > Following the HIG doesn't mean "implementing every pattern that
> > exists in the HIG".
>
> Of course apps shouldn't need to implement every single pattern, but
> they should implement at least the basics. An application menu is the
> bare minimums for your app to feel well-integrated in Fedora
> Workstation. The desktop environment provides the menu, and a little
> arrow indicating that there are menu items, and the only menu item is
> Quit? We should not consider that to be acceptable for default apps,
> anymore.


I disagree.


>
> > Regarding "installing extensions", I assume you mean stuff like
> > HTitle and the GNOME Theme... well, I'm not sure HTitle will continue
> > to be supported once firefox moves to its new addon API... as we
> > discussed in the past in this mailing list, we don't want to be
> > installing any addons by default unless we can grantee they'll be
> > supported for as long as our release is supported -  if Firefox
> > updates and breaks one of them, reverting the user to "normal"
> > Firefox would be a bad experience.
> >
> > My previous comment about the HIG applies here too.
>
> We would also need to never update Firefox until after the theme has
> first been updated. Regarding HTitle: we can do it as a patch instead
> of an extension (you're right; HTitle probably won't be possible as a
> WebExtension). Or just not implement that at all. The theme and app
> menu are the most important parts.
>

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).


>
> If we don't want to theme Firefox properly... Epiphany works great for
> me. :)
>

You are biased, as you said before. Epiphany still has rendering problems
in many websites, it doesn't support privacy-enhancing extensions such as
privacy badger and HTTPS Everywhere, 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!), it doesn't support many
newer web platform APIs, doesn't have a sync solution... the list goes on
and on.


>
> > The problem is I don't think it's wise to enable SELinux by default
> > without having any UI to let the user know when a violation happens.
> > And we do want to keep SELinux enabled.
>
> I do want to keep SELinux enabled. I don't think users need to know
> when a violation happens. That's just a bug, and I don't see any reason
> to treat SELinux bugs as more special or more horrible than other bugs.
>

No, a selinux violation is not always a bug. Sometimes it's a misbehaving
3rd party app. Sometimes it happens when you misconfigure your VPN.
Sometimes it's actually SELinux blocking something that should be blocked.


>
> But frankly, I don't remember the last time I've had an SELinux
> violation. totem-video-thumbnailer gets blocked from accessing the
> Internet whenever I view my web cache in nautilus, but that's a real
> bug in totem. And an example of one that users don't need to know
> about.
>

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)


>
> > I think we can replace it with GNOME Photos today. Is there any
> > reason not to? Regardless If it sends your password without verifying
> > certificates then it's a bug that needs to be solved, not a reason to
> > drop it completely. Have you filed the bug?
>
> Debarshi doesn't want to include Photos until it matures further.
>

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.


>
> Regarding the TLS issue: consider that it currently depends on obsolete
> WebKit, which means it has no security updates. That's an even more ser
> ious issue. And modern WebKit handles this automatically, so it will be
> fixed once they upgrade. See
> https://bugzilla.gnome.org/show_bug.cgi?id=751709
>
> This is a severe problem that shouldn't be ignored. At the very least, we
need to disable all social functionality in Shotwell until this is solved.
This has serious implications on user safety.
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.
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.

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...


-- 
-Elad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20150829/ce3a7d7b/attachment.html>