1. 20 Aug, 2021 3 commits
  2. 17 Aug, 2021 1 commit
  3. 18 Mar, 2021 1 commit
    • Eivind Næss's avatar
      Fix clearing password when restoring a valid configuration to be displayed to a user · 2a307a36
      Eivind Næss authored
      
      
      The handling of the various input and cases, and to get these right is difficult; partially because of the number of inputs and the
      various states the component can be in. I've taken the pre-caution by creating a State Machine laid out by the text below that will
      adequately describe the current state, the action taken and the result of each user action as listed below.
      
      I've methodically gone through and tested each state with my change.
      
      Tested the following scenarios:
      
      The seven states, except for 1, 3, and 5 (as they cannot be saved), as spelled out below describe the initial state when restoring a
      configuration using network-manager-openvpn plugin. For each of the starting state (0, 2, 4, 6), sufficient input has been made to
      transition between each of these states.
      
      The states:
      
      State 0: When starting from from all blank fields, Cert is enabled, Key and Password are disabled
        * Set PKCS12 for certificate
          - Key gets PKCS12 value,
          - Password entry is enabled
          - Goto 5
        * Set X509 for Certificate
          - Key becomes enabled
          - Goto 1
      
      State 1: When using X509 for certificate, Key is blank, Password is empty and disabled
        * Change Cert to PCKS12
          - Key gets PKCS12 value
          - Password is enabled
          - Goto 5
        * Change Key to PKCS12
          - Cert gets PKCS12 value
          - Password is enabled
          - Goto 5
        * Change key to use an un-encrypted RSA key
          - No change
          - Goto 2
        * Change key to use an encrypted RSA key
          - Password is enabled
          - Goto 3
      
      State 2: When using X509 for Certificate, Key has an un-encrypted RSA key, Password is empty and disabled
        * Change Cert to PKCS12
          - Key gets PKCS12 value
          - Password is enabled
          - Goto 5
        * Change Key to PKCS12
          - Cert gets PKCS12 value
          - Password is enabled
          - Goto 5
        * Change Cert to different X509 certificate
          - No change
          - Goto 2
        * Change Key to encrypted RSA key
          - Password is enabled
          - Goto 3
        * Change Key to different un-encrypted RSA key
          - No change
          - Goto 2
      
      State 3: When using X509 for Certificate, Key has an *encrypted* RSA key, Password is empty and enabled
        * Change Cert to PKCS12
          - Key gets PKCS12 value
          - Goto 5
        * Change Key to PKCS12
          - Cert gets PKCS12 value
          - Goto 5
        * Change Cert to different X509 certificate
          - No change
          - Goto 3
        * Change Key to un-encrypted RSA key
          - Password is disabled
          - Goto 2
        * Change Key to different encrypted RSA key
          - No change
          - Goto 3
        * Enter password
          - No change
          - Goto 4
      
      State 4: When using X509 for Certificate, Key has an *encrypted* RSA key, Password has value and is enabled
        * Change Cert to PKCS12
          - Key gets PKCS12 value
          - Password is cleared
          - Goto 5
        * Change Key to PKCS12
          - Cert gets PKCS12 value
          - Password is cleared
          - Goto 5
        * Change Key to invalid RSA value (e.g. X509 certificate)
          - Password is cleared
          - Key is marked with error (GTK bug, error marking not visible to end-user in FileChooser component)
          - Goto 2
        * Change Cert to different X509 certificate
          - No change
          - Goto 4
        * Change Key to un-encrypted RSA key
          - Password is cleared
          - Password is disabled
          - Goto 2
        * Change Key to different encrypted RSA key
          - No Change, see Note 1
          - Goto 4
      
      State 5: When using PKCS12 for Certificate and Key, Key is disabled, Password is empty and enabled
        * Change Cert to use X509 certificate
          - Key is cleared
          - Password is disabled
          - Goto 1
        * Enter password
          - No change
          - Goto 6
      
      State 6: When using PKCS12 for Certificate and Key, Key is disabled, Password has a value and is enabled
        * Change Cert to use X509 certificate
          - Key is cleared
          - Password is cleared
          - Password is disabled
          - Goto 1
        * Clear password
          - No change
          - Goto 5
      
      Notes:
      1) To clear password here, we can't destinguish if user set a different key or if network-manager-openvpn restored an existing configuration.
      Signed-off-by: Eivind Næss's avatarEivind Naess <eivnaes@yahoo.com>
      
      #6
      
      !16
      2a307a36
  4. 22 Jun, 2020 3 commits
  5. 10 Jun, 2020 1 commit
  6. 22 Apr, 2020 1 commit
  7. 10 Mar, 2020 1 commit
  8. 06 Mar, 2020 5 commits
    • Thomas Haller's avatar
      version: calculate NMA_API_VERSION based on the version number · e07506ed
      Thomas Haller authored
      The concept of NMA_VERSION_CUR_STABLE and NMA_VERSION_NEXT_STABLE is
      flawed. Only the current API version of the source matters.
      
      If the current checkout is still in development (from master branch,
      odd numbers, e.g. 1.8.29+), then this is already aspiring the upcoming
      API (e.g. 1.8.30). Hence, also for such development version, it should
      pretend to be already the to-be-released version.
      
      For releases (tagged, with even numbers, like 1.8.28), obviously the
      version is exactly the API version.
      
      Since we have a versioning scheme based on odd/even numbers, we can
      calculate the current/upcoming API version. Do that.
      
      This also allows us to skip bumping the NMA_VERSION_CUR_STABLE
      and NMA_VERSION_NEXT_STABLE macros. That was easy for forget, resulting
      in a broken release. While the release process was documented to bump
      these two defines, it's easy to forget.
      
      The same is done by libnm, which also follows the odd/even versioning
      scheme.
      e07506ed
    • Thomas Haller's avatar
      8f487970
    • Thomas Haller's avatar
      release: bump version to 1.8.28 · 0c40a6ae
      Thomas Haller authored
      0c40a6ae
    • Thomas Haller's avatar
      release: update NEWS · e8fbe799
      Thomas Haller authored
      e8fbe799
    • Thomas Haller's avatar
      po: update · af13c06f
      Thomas Haller authored
      af13c06f
  9. 05 Mar, 2020 4 commits
  10. 16 Feb, 2020 12 commits
  11. 14 Feb, 2020 5 commits
  12. 13 Feb, 2020 3 commits