GitLab will be down for maintenance this Sunday 13th June, from approx 7-11am UTC. This is for a PostgreSQL migration. See the tracker issue for more informations.

  1. 30 Apr, 2018 1 commit
  2. 08 Feb, 2018 1 commit
  3. 16 Jan, 2018 2 commits
  4. 15 Jan, 2018 1 commit
  5. 18 Dec, 2017 1 commit
  6. 23 Nov, 2017 3 commits
  7. 16 Nov, 2017 1 commit
    • Thomas Haller's avatar
      all: use nm_str_hash() instead of g_str_hash() · a6be2f4a
      Thomas Haller authored
      We also do this for libnm and libnm-core, where it causes visible changes
      in behavior. But if somebody would rely on the hashing implementation
      for hash tables, it would be seriously flawed.
      a6be2f4a
  8. 08 Mar, 2017 1 commit
  9. 06 Feb, 2017 1 commit
  10. 24 Nov, 2016 1 commit
  11. 23 Nov, 2016 1 commit
  12. 03 Oct, 2016 1 commit
  13. 16 Jun, 2016 1 commit
    • Thomas Haller's avatar
      shared: move shared files to subdirectory "shared/nm-utils/" · 4b288136
      Thomas Haller authored
      The "shared" directory contains files that are possibly used by all components
      of NetworkManager repository.
      
      Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
      and used there without modification. Move those files to a separate directory.
      By moving them to a common directory, it is clearer that they belong
      together. Also, you can easier compare the copied versions to their
      original via
      
        $ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
      4b288136
  14. 15 Jun, 2016 1 commit
    • Thomas Haller's avatar
      libnm/vpn: add nm_vpn_editor_plugin_load_vt() · cf34211c
      Thomas Haller authored
      Let VPN plugins return a virtual function table to extend
      the API while bypassing libnm. This allows to add and use
      new functionality to VPN plugins without updating libnm.
      
      The actual definitions are in a header-only file
      "nm-vpn-editor-plugin-call.h", which can be copied to the
      caller/plugin.
      cf34211c
  15. 20 Apr, 2016 1 commit
  16. 26 Mar, 2016 1 commit
    • Thomas Haller's avatar
      libnm: accept invalid connections in NMVpnServicePlugin · 559ab7bd
      Thomas Haller authored
      When we receive a connection from NetworkManager it is not guaranteed
      that the connection verifies. For example, if the current libnm version
      is older then the NetworkManager version.
      
      Be more accepting and don't do any verification of the connection.
      
      For NMVpnPluginOld this change is uncritical, because there are probably
      no users of this API anyway.
      
      NMVpnServicePlugin is new API since nm-1-1. However, this API is already
      strongly used by all the plugins we ported over. So this change is
      affecting them.
      This should only matter if libnm's and NetworkManager's version differ,
      because NetworkManager just doesn't send out an invalid connection. It
      actually only matters if NetworkManager is a newer version and sends an
      invalid connection to the client. That is anyway badly tested and probably
      this changes rather improves compatibility than breaking existing users.
      559ab7bd
  17. 03 Mar, 2016 1 commit
  18. 02 Mar, 2016 1 commit
    • Dan Williams's avatar
      libnm-glib/libnm/vpn: fix handling of ConnectInteractive() failure (rh #1298732) · abc700c5
      Dan Williams authored
      If the plugin supports interactive mode, but the VPN binary (like vpnc
      or openvpn) doesn't support it, then the plugin should return
      NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED from its connect_interactive()
      hook.  This lets NetworkManager know to fall back to plain Connect().
      
      Since this notification is done through an error return, the VPN service
      plugin code sees the failure and moves the plugin state back to
      STOPPED.  NetworkManager sees that state change, and terminates the
      connection attempt while waiting for a reply to the Connect() method.
      
      (VPN service plugins that don't support interactive mode at all don't
      have this problem because that error is returned before the plugin's
      state is moved to STARTING.)
      
      To fix this, do two things:
      
      1) if the connect_interactive() hook fails and returns the error
      NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED, postpone the STOPPED
      state change for a few seconds to allow NM time to fall back to
      plain Connect().  We still want to move the plugin state back to
      STOPPED eventually, because otherwise it could stay in STARTING
      forever.
      
      2) change state to STARTING only if the connect/connect_interactive
      plugin hooks were successful.  Otherwise the plugin would still be
      in STARTING state, and it's not valid to call Connect()/ConnectInteractive()
      during the STARTING state.
      
      https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00091.html
      https://bugzilla.redhat.com/show_bug.cgi?id=1298732
      abc700c5
  19. 19 Feb, 2016 1 commit
    • Thomas Haller's avatar
      all: cleanup includes and let "nm-default.h" include "config.h" · 8bace23b
      Thomas Haller authored
      - All internal source files (except "examples", which are not internal)
        should include "config.h" first. As also all internal source
        files should include "nm-default.h", let "config.h" be included
        by "nm-default.h" and include "nm-default.h" as first in every
        source file.
        We already wanted to include "nm-default.h" before other headers
        because it might contains some fixes (like "nm-glib.h" compatibility)
        that is required first.
      
      - After including "nm-default.h", we optinally allow for including the
        corresponding header file for the source file at hand. The idea
        is to ensure that each header file is self contained.
      
      - Don't include "config.h" or "nm-default.h" in any header file
        (except "nm-sd-adapt.h"). Public headers anyway must not include
        these headers, and internal headers are never included after
        "nm-default.h", as of the first previous point.
      
      - Include all internal headers with quotes instead of angle brackets.
        In practice it doesn't matter, because in our public headers we must
        include other headers with angle brackets. As we use our public
        headers also to compile our interal source files, effectively the
        result must be the same. Still do it for consistency.
      
      - Except for <config.h> itself. Include it with angle brackets as suggested by
        https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
      8bace23b
  20. 12 Feb, 2016 1 commit
    • Thomas Haller's avatar
      build: cleanup default includes · 2c2d9d2e
      Thomas Haller authored
      - "gsystem-local-alloc.h" and <gio/gio.h> are already included via
        "nm-default.h". No need to include them separately.
      
      - include "nm-macros-internal.h" via "nm-default.h" and drop all
        explict includes.
      
      - in the modified files, ensure that we always include "config.h"
        and "nm-default.h" first. As second, include the header file
        for the current source file (if applicable). Then follow external
        includes and finally internal nm includes.
      
      - include nm headers inside source code files with quotes
      
      - internal header files don't need to include default headers.
        They can savely assume that "nm-default.h" is already included
        and with it glib, nm-glib.h, nm-macros-internal.h, etc.
      2c2d9d2e
  21. 28 Jan, 2016 1 commit
  22. 13 Nov, 2015 1 commit
  23. 23 Oct, 2015 1 commit
  24. 16 Oct, 2015 1 commit
  25. 14 Oct, 2015 1 commit
  26. 13 Oct, 2015 4 commits
    • Lubomir Rintel's avatar
      libnm/vpn-service-plugin: remove nm_vpn_service_plugin_{get,set}_state() · fd61b217
      Lubomir Rintel authored
      The plugins set state only on failures and often forget to do that. Do the
      correct status transition to STOPPED in nm_vpn_service_plugin_failure() instead.
      
      The get_state() is only used to find out whether to fail or orderly disconnect
      depending on whether we're STARTING or already STARTED. Handle that in
      nm_vpn_service_plugin_disconnect() in a generic manner instead.
      fd61b217
    • Lubomir Rintel's avatar
      libnm/vpn-service-plugin: quit when the peer we watch disconnects · 78f263a5
      Lubomir Rintel authored
      We're of no use anymore as another user would start an instance with
      a different bus name.
      78f263a5
    • Lubomir Rintel's avatar
      libnm/vpn-service-plugin: add watch-peer property · 9f15abbd
      Lubomir Rintel authored
      Make it possible to construct the plugin instance in a way that disconnects the
      connection if the DBus client that activated it drops off the bus. This makes the
      plugins conveniently clean up when NetworkManager crashes.
      
      We need this, as with multiple VPN support we can loose track of the client bus
      names when the daemon crashes leaving to nice way to clean up on respawn.
      
      However, this behavior is not desired for debugging or hypotetical VPN plugin
      users other than NetworkManager (say; "gdbus call -m o.fd.NM.VPN.Plugin.Connect").
      Let the plugin decide when to use it.
      9f15abbd
    • Lubomir Rintel's avatar
      1bb55379
  27. 01 Oct, 2015 1 commit
    • Lubomir Rintel's avatar
      nm-vpn-service-plugin: increase the quit timer · b1512221
      Lubomir Rintel authored
      We now (since 3272ff6f libnm/libnm-glib: don't quit in the middle of asking for
      secrets) always hook on the quit timer when NM asks the plugin if it needs
      secrets. The timer is 20 seconds, which seems too short.
      
      Let's make it three minutes. Don't bother adding another timer or using a
      distinct timeout: it does no harm for the plugin to remain unused for three
      minutes on a bus.
      
      Another option would be to completely unhook it; however the plugin wouldn't
      learn if the user cancelled the NM's secrets request and would remain unused
      on the bus forever.
      b1512221
  28. 25 Aug, 2015 1 commit
  29. 17 Aug, 2015 2 commits
  30. 05 Aug, 2015 1 commit
  31. 29 Jul, 2015 3 commits