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 736749 - oauth2: Possible use of uninitialized variable in on_web_view_navigation_policy_decision_requested
oauth2: Possible use of uninitialized variable in on_web_view_navigation_poli...
Status: RESOLVED FIXED
Product: gnome-online-accounts
Classification: Core
Component: general
3.13.x
Other All
: Normal normal
: ---
Assigned To: GNOME Online Accounts maintainer(s)
GNOME Online Accounts maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-09-16 14:05 UTC by Debarshi Ray
Modified: 2014-10-22 13:23 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
oauth2: Silence uninit_use_in_call from Coverity (1.26 KB, patch)
2014-09-16 14:08 UTC, Debarshi Ray 		committed Details | Review

Description Debarshi Ray 2014-09-16 14:05:13 UTC 
Coverity thinks that response_id can be used uninitialized in on_web_view_navigation_policy_decision_requested in src/goabackend/goaoauth2provider.c.

After reading the code in that function and get_tokens_and_identity (which is where it is connected to the embedded web view), I don't think that this can happen in practice. Before using the web view we clear priv->access_token and priv->authorization_code. So if we ever go to ignore_request then response_id will be either GTK_RESPONSE_OK or GTK_RESPONSE_CLOSE or GTK_RESPONSE_CANCEL.

Having said that, it is possible that I am wrong. So I am thinking of initializing response_id to GTK_RESPONSE_NONE and asserting that it has been set to something else before using it. However, this is something that I don't want to do on the verge of 3.14.0, so let's do this after the freeze.
Comment 1 Debarshi Ray 2014-09-16 14:08:32 UTC 
Created attachment 286297 [details] [review]
oauth2: Silence uninit_use_in_call from Coverity