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 757843 - Adding a wifi AP connection with invalid PSK for WPA-PSK via d-bus should fail
Adding a wifi AP connection with invalid PSK for WPA-PSK via d-bus should fail
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: API
1.0.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-11-09 18:47 UTC by Glenn Washburn
Modified: 2015-11-20 09:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Glenn Washburn 2015-11-09 18:47:55 UTC
I've tried this on NM versions 1.0.2 and 1.0.6, with similar results.

I am adding a wifi AP connection to NM which uses WPA-PSK and provides an invalid password (less than 8 chars).  NM will hapily create this connection, though is should fail an give an appropriate reason.  Once created, bringing up the connection will ask for a password, because the given password fails the valid password check.  And the NM logs give no specific indication of why the password fails.

However, after adding the connection and then restarting NM, I do get this warning message in the NM logs: '<warn>  ifcfg-rh: loading "/
etc/sysconfig/network-scripts/ifcfg-wifi-ap" fails: Invalid WPA_PSK (passphrases
 must be between 8 and 63 characters long (inclusive))'

It would be nice to have that warning sent back as an error message in a failure response to the connection add with an invalid WPA password.

I'm not sure if this is specific to the ifcfg-rh plugin, which I'm using, or specific to wifi AP mode (as opposed to other modes).

Here is a python dictionary representation of the connection that is causing the bug:
{
     'connection': {'id': 'wifi-ap',
                    'type': '802-11-wireless',
                    'uuid': '<uuid>',
                    'gateway-ping-timeout': 0},
     '802-11-wireless': {'mode': 'ap',
                         'security': '802-11-wireless-security',
                         'ssid': 'eenbridge10000'},
     '802-11-wireless-security': {'key-mgmt': 'wpa-psk',
                                  'psk': '10000'},
     'ipv4': {'method': 'manual',
              'never-default': True,
              'addresses': [['10.137.0.1', '16', '0.0.0.0']],
     },
     'ipv6': {'method': 'ignore'},
}
Comment 2 Jiri Klimes 2015-11-10 14:42:50 UTC
A fix is available in jk/con-add-verify-secrets-bgo757843.
Comment 3 Dan Williams 2015-11-10 17:31:41 UTC
> libnm: add nm_setting_verify_secrets() and nm_connection_verify_secrets()

Need Since: 1.2 and AVAILABLE_IN annotations.

Maybe add a simple "string" secret verify helper and use that everywhere?  Most of the secrets are just strings.  Probably could have just:

gboolean _nm_setting_verify_secret_string(const char *string, const char *setting_name, const char *property, GError **error);


Otherwise LGTM.
Comment 4 Jiri Klimes 2015-11-11 12:19:29 UTC
(In reply to Dan Williams from comment #3)
> > libnm: add nm_setting_verify_secrets() and nm_connection_verify_secrets()
> 
> Need Since: 1.2 and AVAILABLE_IN annotations.
> 
Fixed.

> Maybe add a simple "string" secret verify helper and use that everywhere? 
> Most of the secrets are just strings.  Probably could have just:
> 
> gboolean _nm_setting_verify_secret_string(const char *string, const char
> *setting_name, const char *property, GError **error);
> 

Added the helper and also _verify_wep_key() helper in nm-setting-wireless-security.c
Re-pushed.
Comment 5 Jiri Klimes 2015-11-20 09:41:40 UTC
Committed to master as
0f6baee core: verify secrets when adding connection via D-Bus (bgo #757843)
b41b32c libnm: add nm_setting_verify_secrets() and nm_connection_verify_secrets()