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.) -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
