Let's reconsider some more applications installed by default

[Michael Catanzaro]

On Sat, 2015-08-29 at 14:23 +0300, Elad Alfassa wrote:
> Well, some of the issues are webkitgtk specific, such as the ones
> where it
> pretends to be other browsers and break the entire world while doing
> so.

We "pretend" to be Safari in the sense that Safari is in our user
agent, since otherwise broken servers (like www.google.com) send us
crap versions of various web pages (I've yet to see this break any site
compared to having no major browser in the user agent, though of course
that is possible). We have a hardcoded rule to pretend to be Chrome
when visiting Yahoo, since otherwise Yahoo sends a mobile page. And
we're prepared to use that rule for other sites as well, when needed
(e.g. theverge only sends us nice fonts if we pretend to be Chrome),
but we currently don't.

If you want, you can remove Safari from the UA with dconf-editor and
see how it affects different sites. Most will be unchanged, but enough
will break that it's not advisable. :( UA sniffing is a big problem,
but the only way to fix it is for other browsers to send blank UAs.

> You can't pick a locale specific blocklist automatically. I live in
> Israel
> and use an English locale, and I use many Israeli websites and many
> global
> websites. In reality, I need (at least) two lists, and you have no
> automatic way to detect which ones I'm going to require.

We can use locale to make a good guess, but I agree that UI is
required.

> Well, we should not ship a default app with a dead upstream. It's
> better to
> ship something which is not yet fully mature than something that is
> outright insecure.

I agree; let's get rid of it! :D

> Can you please check if what you're saying is correct, so we can
> patch it
> out of shotwell if it is?

Well testing it requires effort that I'm not going to spend, :) plus it
looks like Shotwell's Facebook integration is totally broken nowadays
[1], and upstream doesn't care. But no doubt it's still going to send
your password, and it has support for many non-Facebook sites too
(YouTube, ...). Anyway, a quick grep of the code for "soup" and "ssl"
and "tls" shows nothing that looks like certificate verification. I
really don't see any possibility that it is verifying TLS certificates
currently: the person who submitted the patch to port it to WebKit2
noted that the patch causes verification to fail in Ubuntu (Facebook's
certs were at the time not valid for glib-networking apps in Ubuntu,
since Ubuntu had removed the GTE CyberTrust root cert that it chains up
to, which Ubuntu has since restored). That means the app was either
previously doing no verification at all (which is only caught now
because modern WebKit is secure by default), or else it was verifying
using something other than glib (quite difficult and extremely
unlikely, IMO).

[1] https://bugzilla.gnome.org/show_bug.cgi?id=748991

> Fedora has an option to mark a bug as a security sensitive one, which
> hides
> it from the public. This is the correct way to report a security bug.


TBH, you're going to have to walk me through this (maybe with a
screenshot?) because I don't see such an option anywhere.

> This
> is called "responsible disclosure" and is a very important practice
> in the
> infosec industry. If you disclose a security issue publicly, people
> who
> didn't know about it before might start exploiting it before you can
> ship a
> fix to your users.

Red Hat Bugzilla is not a good place for upstream GNOME bugs: there are
way too many and they will just be ignored. Shotwell bugs are assigned
to Matthias, who has 1000 other bugs. I would be impressed if all he
did was report it publicly upstream (he would spend all day moving bugs
if he did that regularly). Besides, if the bug is marked private
downstream, then there is no possibility for it to be fixed....

Responsible disclosure to upstream developers is great if upstream has
and promotes such a process, but in GNOME, all bugs are public unless a
Bugzilla admin manually sets it private (at least, I have found no way
to create a private bug), and frankly I think that's for the best. Many
such reports are not addressed in a timely manner, and keeping them
hidden is a disservice to the public, which should know about product
security problems. (I agree, private bugs are fine if addressed in a
timely manner and set public on a short deadline after they are
reported, e.g. 2-3 months. I disapprove of WebKit's policy of keeping
bugs private forever.)