On Fri, Aug 28, 2015 at 11:39 PM, Michael Catanzaro <mcatanzaro@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.