After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 778369 - missing warning when submitting password to non-secure website
missing warning when submitting password to non-secure website
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Passwords, Cookies, & Certificates
3.23.x
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-02-09 01:02 UTC by Jeremy Bicha
Modified: 2017-02-09 04:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sensitive form warnings should not depend on remember password setting (2.70 KB, patch)
2017-02-09 04:01 UTC, Michael Catanzaro
committed Details | Review
web-view: Fix insecure password warning for insecure targets (1.29 KB, patch)
2017-02-09 04:01 UTC, Michael Catanzaro
committed Details | Review

Description Jeremy Bicha 2017-02-09 01:02:32 UTC
epiphany 3.23.5-0ubuntu1
webkit2gtk 2.15.4-1ubuntu2
Ubuntu GNOME 17.04 Alpha amd64

I tried to test bug 775167 but I don't see any warning when I enter a password into an http website (non-https).

I tried on multiple semi-private WordPress sites and on http://osnews.com/
Comment 1 Michael Catanzaro 2017-02-09 02:41:17 UTC
I can reproduce the issue on http://osnews.com. It's a standard HTML form with input type="password", so it should work; there must be a bug in my code.
Comment 2 Michael Catanzaro 2017-02-09 03:23:09 UTC
I'm not sure what's wrong yet, but I did find a second bug: this code only triggers if password saving is enabled, so if you uncheck the remember passwords setting or use a private profile (like I usually do for testing) then it will never run at all.
Comment 3 Michael Catanzaro 2017-02-09 03:43:28 UTC
There's a logic error: the warning only works correctly if a form on an insecure page submits to a secure URI. I did a refactoring at one point, probably broke it then, and apparently I only tested that case after doing so.
Comment 4 Michael Catanzaro 2017-02-09 04:01:32 UTC
The following fixes have been pushed:
aa4164c Sensitive form warnings should not depend on remember password setting
1ab1dd9 web-view: Fix insecure password warning for insecure targets
Comment 5 Michael Catanzaro 2017-02-09 04:01:35 UTC
Created attachment 345286 [details] [review]
Sensitive form warnings should not depend on remember password setting

The code that triggers the sensitive form focused warnings only runs if
the remember passwords setting is enabled. Oops! We should warn users
about insecure password forms regardless of whether or not Epiphany
remembers the user's passwords.
Comment 6 Michael Catanzaro 2017-02-09 04:01:39 UTC
Created attachment 345287 [details] [review]
web-view: Fix insecure password warning for insecure targets

Towards the end of development, I inverted the meaning of this boolean
in a small refactoring, and in so doing accidentally broke this
condition. The result was that the insecure password warning only worked
if the target of the form was a secure page. And it just so happened
that my primary test site was an insecure page where the login form used
a secure target, which is how I didn't notice for two months.