1. 28 May, 2019 1 commit
  2. 11 Mar, 2019 1 commit
  3. 07 Mar, 2019 1 commit
  4. 22 Feb, 2019 1 commit
    • Thomas Haller's avatar
      all: move nm_utils_hexstr2bin*() to shared · 53b747ff
      Thomas Haller authored
      libnm exposes simplified variants of hexstr2bin in its public API. I
      think that was a mistake, because libnm should provide NetworkManager
      specific utils. It should not provide such string functions.
      
      However, nmcli used to need this, so it was added to libnm.
      
      The better approach is to add it to our internally shared static
      library, so that all interested components can make use of it.
      53b747ff
  5. 21 Feb, 2019 1 commit
  6. 12 Feb, 2019 4 commits
  7. 06 Feb, 2019 1 commit
  8. 05 Feb, 2019 1 commit
  9. 04 Feb, 2019 1 commit
  10. 20 Dec, 2018 1 commit
  11. 19 Dec, 2018 2 commits
    • Thomas Haller's avatar
      all: don't use static buffer for nm_utils_inet*_ntop() · a51c09dc
      Thomas Haller authored
      While nm_utils_inet*_ntop() accepts a %NULL buffer to fallback
      to a static buffer, don't do that.
      
      I find the possibility of using a static buffer here error prone
      and something that should be avoided. There is of course the downside,
      that in some cases it requires an additional line of code to allocate
      the buffer on the stack as auto-variable.
      a51c09dc
    • Aleksander Morgado's avatar
      settings,gsm: deprecate and stop using 'number' property · 6ed21e83
      Aleksander Morgado authored
      The 'number' property in GSM settings is a legacy thing that comes
      from when ModemManager used user-provided numbers, if any, to connect
      3GPP modems.
      
      Since ModemManager 1.0, this property is completely unused for 3GPP
      modems, and so it doesn't make sense to use it in the NetworkManager
      settings. Ofono does not use it either.
      
      For AT+PPP-based 3GPP modems, the 'number' to call to establish the
      data connection is decided by ModemManager itself, e.g. for standard
      GSM/UMTS/LTE modems it will connect a given predefined PDP context,
      and for other modems like Iridium it will have the number to call
      hardcoded in the plugin itself.
      
      https://github.com/NetworkManager/NetworkManager/pull/261
      6ed21e83
  12. 13 Dec, 2018 1 commit
  13. 12 Dec, 2018 2 commits
    • Beniamino Galvani's avatar
      ifcfg-rh: fix persisting sriov setting · d48f389c
      Beniamino Galvani authored
      The writer should write all properties of the sriov setting when the
      setting exists without additional logic. Likewise, the reader should
      instantiate a sriov setting when any sriov key is present and blindly
      set properties from keys.
      
      The old code did not always preserve the presence of a sriov setting
      after a write/read cycle.
      
      Fixes: c02d1c48
      d48f389c
    • Beniamino Galvani's avatar
      cli: strictly validate SR-IOV attributes · 769e0726
      Beniamino Galvani authored
      Report an error when the user tries to add an unknown attribute
      instead of silently accepting (and ignoring) it.
      
      Note that this commit also changes the behavior of public API
      nm_utils_sriov_vf_from_str() to return an error when an unknown
      attribute is found. I think the previous behavior was buggy as wrong
      attributes were simply ignored without any way for the user to know.
      
      Fixes: a9b4532f
      769e0726
  14. 29 Nov, 2018 1 commit
    • Lubomir Rintel's avatar
      all: say Wi-Fi instead of "wifi" or "WiFi" · b385ad01
      Lubomir Rintel authored
      Correct the spelling across the *entire* tree, including translations,
      comments, etc. It's easier that way.
      
      Even the places where it's not exposed to the user, such as tests, so
      that we learn how is it spelled correctly.
      b385ad01
  15. 23 Oct, 2018 1 commit
  16. 22 Oct, 2018 1 commit
  17. 04 Oct, 2018 1 commit
    • Thomas Haller's avatar
      keyfile: split automatically setting ID/UUID for keyfile · 837d44ff
      Thomas Haller authored
      keyfile already supports omitting the "connection.id" and
      "connection.uuid". In that case, the ID would be taken from the
      keyfile's name, and the UUID was generated by md5 hashing the
      full filename.
      
      No longer do this during nm_keyfile_read(), instead let all
      callers call nm_keyfile_read_ensure_*() to their liking. This is done
      for two reasons:
      
       - a minor reason is, that one day we want to expose keyfile API
         as public API. That means, we also want to read keyfiles from
         stdin, where there is no filename available. The implementation
         which parses stdio needs to define their own way of auto-generating
         ID and UUID. Note how nm_keyfile_read()'s API no longer takes a
         filename as argument, which would be awkward for the stdin case.
      
       - Currently, we only support one keyfile directory, which (configurably)
         is "/etc/NetworkManager/system-connections".
         In the future, we want to support multiple keyfile dirctories, like
         "/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles".
         Here we want that a file "foo" (which does not specify a UUID) gets the
         same UUID regardless of the directory it is in. That seems better, because
         then the UUID won't change as you move the file between directories.
         Yes, that means, that the same UUID will be provided by multiple
         files, but NetworkManager must already cope with that situation anyway.
         Unfortunately, the UUID generation scheme hashes the full path. That
         means, we must hash the path name of the file "foo" inside the
         original "system-connections" directory.
         Refactor the code so that it accounds for a difference between the
         filename of the keyfile, and the profile_dir used for generating
         the UUID.
      837d44ff
  18. 30 Sep, 2018 2 commits
  19. 28 Sep, 2018 1 commit
  20. 17 Sep, 2018 1 commit
  21. 15 Sep, 2018 1 commit
  22. 14 Sep, 2018 2 commits
    • Thomas Haller's avatar
      libnm: drop API nm_connection_get_setting_{6lowpan,sriov,wpan}() · fe866fbe
      Thomas Haller authored
      Note that NMSettingEthtool and NMSettingMatch don't have such
      functions either.
      
      We have API
      
        nm_connection_get_setting (NMConnection *, GType)
        nm_connection_get_setting_by_name (NMConnection *, const char *)
      
      which can be used generically, meaning: the requested setting type
      is an argument to the function. That is generally more useful and
      flexible.
      
      Don't add API which duplicates existing functionality and is (arguably)
      inferiour. Drop it now. This is an ABI/API break for the current development
      cycle where the 1.14.0 API is still unstable. Indeed it's already after
      1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
      this API/ABI and is badly impacted by this change.
      
      Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
      are slightly inconvenient in C still, because they usually require a cast.
      We should fix that by changing the return type to "void *". Such
      a change may be possibly any time without breaking API/ABI (almost, it'd
      be an API change when taking a function pointer without casting).
      
      (cherry picked from commit a10156f5)
      fe866fbe
    • Thomas Haller's avatar
      libnm: drop API nm_connection_get_setting_{6lowpan,sriov,wpan}() · a10156f5
      Thomas Haller authored
      Note that NMSettingEthtool and NMSettingMatch don't have such
      functions either.
      
      We have API
      
        nm_connection_get_setting (NMConnection *, GType)
        nm_connection_get_setting_by_name (NMConnection *, const char *)
      
      which can be used generically, meaning: the requested setting type
      is an argument to the function. That is generally more useful and
      flexible.
      
      Don't add API which duplicates existing functionality and is (arguably)
      inferiour. Drop it now. This is an ABI/API break for the current development
      cycle where the 1.14.0 API is still unstable. Indeed it's already after
      1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
      this API/ABI and is badly impacted by this change.
      
      Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
      are slightly inconvenient in C still, because they usually require a cast.
      We should fix that by changing the return type to "void *". Such
      a change may be possibly any time without breaking API/ABI (almost, it'd
      be an API change when taking a function pointer without casting).
      a10156f5
  23. 13 Sep, 2018 2 commits
  24. 06 Sep, 2018 3 commits
    • Beniamino Galvani's avatar
      44d77a74
    • Thomas Haller's avatar
      settings: make NMSettingsPlugin a regular GObject instance and not an interface · 657b0714
      Thomas Haller authored
      NMSettingsPlugin was a glib interface, not a regular GObject
      instance. Accordingly, settings plugins would implement this interface
      instead of subclassing a parent type.
      
      Refactor the code, and make NMSettingsPlugin a GObject type. Plugins
      are now required to subclass this type.
      
      Glib interfaces are more cumbersome than helpful. At least, unless
      there is a good reason for using them.
      
      Our settings plugins are all internal API and are entirely under
      our control. It also means, this change is fine, as there are no
      implementations outside of this source tree.
      
      Using interfaces do would allow more flexibility in implementing the
      settings plugin.
      For example, the plugin would be able to derive from any other GObject
      type, like NMKimchiRefrigerator. But why would we even? Let's not add monster
      classes that implement house appliances beside NMSettingsPluginInterface.
      The settings plugin should have one purpose only: being a settings plugin.
      Hence, requiring it to subclass NMSettingsPlugin is more than resonable. We
      don't need interfaces for this.
      
      Now that NMSettingsPlugin is a regular object instance, it may also have
      state, and potentially could provide common functionality for the plugin
      implementation -- if that turns out to be useful. Arguably, an interface can
      have state too, for example by attaching the state somewhere else (like
      NMConnection does). But let's just say no.
      
      On a minor note, this also avoids some tiny overhead that comes with
      glib interfaces.
      657b0714
    • Thomas Haller's avatar
  25. 04 Sep, 2018 6 commits
    • Thomas Haller's avatar
      ifcfg-rh: don't use 802-1x certifcate setter functions · e3ac45c0
      Thomas Haller authored
      The certificate setter function like nm_setting_802_1x_set_ca_cert()
      actually load the file from disk, and validate whether it is a valid
      certificate. That is very wrong to do.
      
      For one, the certificates are external files, which are not embedded
      into the NMConnection. That means, strongly validating the files while
      loading the ifcfg files, is wrong because:
       - if validation fails, loading the file fails in its entirety with
         a warning in the log. That is not helpful to the user, who now
         can no longer use nmcli to fix the path of the certificate (because
         the profile failed to load in the first place).
       - even if the certificate is valid at load-time, there is no guarantee
         that it is valid later on, when we actually try to use the file. What
         good does such a validation do? nm_setting_802_1x_set_ca_cert() might
         make sense during nmcli_connection_modify(). At the moment when we
         create or update the profile, we do want to validate the input and
         be helpful to the user. Validating the file later on, when reloading
         the profile from disk seems undesirable.
       - note how keyfile also does not perform such validations (for good
         reasons, I presume).
      
      Also, there is so much wrong with how ifcfg reader handles EAP files.
      There is a lot of duplication, and trying to be too smart. I find it
      wrong how the "eap_readers" are nested. E.g. both eap_peap_reader() and
      "tls" method call to eap_tls_reader(), making it look like that
      NMSetting8021x can handle multiple EAP profiles separately. But it cannot. The
      802-1x profile is a flat set of properties like ca-cert and others. All
      EAP methods share these properties, so having this complex parsing
      is not only complicated, but also wrong. The reader should simply parse
      the shell variables, and let NMSetting8021x::verify() handle validation
      of the settings. Anyway, the patch does not address that.
      
      Also, the setting of the likes of NM_SETTING_802_1X_CLIENT_CERT_PASSWORD was
      awkwardly only done when
           privkey_format != NM_SETTING_802_1X_CK_FORMAT_PKCS12
        && scheme == NM_SETTING_802_1X_CK_SCHEME_PKCS11
      It is too smart. Just read it from file, if it contains invalid data, let
      verify() reject it. That is only partly addressed.
      
      Also note, how writer never actually writes the likes of
      IEEE_8021X_CLIENT_CERT_PASSWORD. That is another bug and not fixed
      either.
      e3ac45c0
    • Thomas Haller's avatar
      ifcfg-rh: rework parsing secrets · 6b763af1
      Thomas Haller authored
      - rename secret related functions to have a "_secret" prefix.
        Also, rename read_8021x_password() because it's not only useful
        for 802-1x.
      
      - In particular, this patch adds _secret_read_ifcfg() helper (formerly
        read_8021x_password()), which is smart enough to obtain secrets from
        the keys ifcfg file. We have other places where we don't get this
        right.
      
      - on a minor note, the patch also makes an effort to clear passwords
        and certifcate data from memory. Yes, there are countless places
        where we don't do that, but in this case, it's done and is as simple
        as replacing gs_free with nm_auto_free_secret, etc.
      6b763af1
    • Thomas Haller's avatar
      ifcfg-rh/trivial: rename variable for ifcfg keys file · 4b6aa207
      Thomas Haller authored
      The term "keys" is used ambigiously. Rename occurances which reference
      the "keys" ifcfg-rh file.
      
      While at it, rename the file "parsed" to "main_ifcfg". It follows the
      same pattern as the "keys_ifcfg" name.
      4b6aa207
    • Thomas Haller's avatar
      build: enable building both crypto backends for tests · e01f7f2c
      Thomas Haller authored
      If the library is available, let's at least compile both
      crypto backends.
      
      That is helpful when developing on crypto backends, so that
      one does not have to configure the build twice.
      
      With autotools, the build is only run during `make check`.
      Not for meson, but that is generally the case with our meson
      setup, that it also builds tests during the regular build step.
      e01f7f2c
    • Thomas Haller's avatar
      shared: move file-get-contents and file-set-contents helper to shared/ · ff163d9d
      Thomas Haller authored
      These functions are not specific to "src/". Also, they will be needed
      by outside of "src/" soon.
      ff163d9d
    • Thomas Haller's avatar
      core: extend nm_utils_*_get_contents() to zero temporary memory · 6b813b90
      Thomas Haller authored
      When reading a file, we may allocate intermediate buffers (realloc()).
      Also, reading might fail halfway through the process.
      
      Add a new flag that makes sure that this memory is cleared. The
      point is when reading secrets, that we don't accidentally leave
      private sensitive material in memory.
      6b813b90