Two errors here; first, need_secrets_tls() was not updated correctly
for the certificate paths changes that landed recently, and would
have incorrectly returned "no secrets required" for the PATH scheme.
Second, an incorrect strcmp() comparison in need_secrets_phase2()
meant that the wrong TTLS phase2 method would get asked if it
required secrets.
NM didn't pass it to MM anyway, so it was mainly unused, but the band settings
were still wrong. Fix that (and still preserve ABI) by adding a new property
for allowed bands that can actually hold all the bands instead of limiting
to 16-bits. Clean up some of the deprecation stuff at the same time to make
it clearer what's deprecated and what to do about it.
This reverts commit 5b90df0737.
Since commit 71219015ea adds all the
0.7.x certificate and key functions back, we can revert the soname
change and preserve API/ABI.
Since there's a more or less direct mapping between the 0.7.x and
the 0.8.x certificate and key operations, we might as well just
deprecate them instead of removing them entirely.
For private keys, don't just verify that the key can be read; try to
decrypt it to ensure that the password is actually valid.
Also fix a stupid {} mistake that caused crashes when setting pkcs#12
certificates because the check for PATH scheme wouldn't happen and
the private key would be NULL when trying to set the client cert to
the same data as the private key.
To be backwards compatible clients need to handle both paths to private
keys and the decrypted private key data, which is what used to get passed
in the private-key and phase2-private-key attributes of the 802.1x setting.
When moving a connection around between system-settings and user-settings,
if the private key is decrypted data, the settings service needs to store
that decrypted data somewhere so that the key can be sent to NM during
the connection process.
But we don't want to store the decrypted private key data, so we have to
re-encrypt it (possibly generating a private key password if one wasn't
sent with the decrypted data) and save it to disk, then send NM a path
to that private key during connection.
To help clients do this, and so that they don't have to carry around
multiple crypto implementations depending on whether they want to use
NSS or gnutls/gcrypt, add a helper to libnm-util.
Furthermore, I misunderstood a bunch of stuff with crypto padding when
writing the encrypt/decrypt functions long ago, so fix that up. Don't
return padding as part of the decrypted data, and make sure to verify
the padding's expected lengths and values when decrypting. Many thanks
to Nalin Dahyabhai for pointing me in the right direction.
Overload the certificate and key properties to allow paths to the
certificates and keys using a special prefix for the property data.
Add API to libnm-util for easy certificate path handling, and
documentation for NMSetting8021x.
NMSettingBluetooth represents the local connection, and thus should
use "PANU" not NAP, because the local adapter will be in PANU mode.
For now, NAP is only relevant when talking about the *remote* device
in NMDeviceBt or NMBluezDevice.
Instead of requiring applets to hash passphrases, just do it in NM instead.
This should fix confusion where people don't understand that they are seeing
their hashed passphrase.
