Getting colder with our second freeze... it's 3.31.91 release day and string freeze, upload a tarball and lock those strings 🏂

  1. 10 Feb, 2019 2 commits
  2. 09 Feb, 2019 3 commits
  3. 30 Jan, 2019 3 commits
    • Daiki Ueno's avatar
      Merge branch 'wip/header-order' into 'master' · 4fa0719d
      Daiki Ueno authored
      Don't assume iterating a hash table will give items in the same order they were inserted
      
      Closes #21
      
      See merge request !9
      4fa0719d
    • Iain Lane's avatar
      gkm-mock: Also store objects in the order they are taken · 7aba0e6a
      Iain Lane authored
      With GLib 2.59, the `test-login-auto` test fails:
      
        Gcr-CRITICAL **: 14:34:24.126: expected prompt property 'choice-label'
        to be "Automatically unlock this keyring whenever I\342\200\231m
        logged in", but it is instead ""
      
      This is because, in `mock_secret_C_Initialize()` we assign two sets of
      fields to the mock module, one with `CKA_G_LOGIN_COLLECTION` → `CK_TRUE`
      and one with it pointing to `CK_FALSE`.
      
      This variable is used to decide, via `is_login_keyring()`, whether to call
      `setup_unlock_keyring_login()` or `setup_unlock_keyring_other()`. The
      first one sets `choice-label` to the empty string. The second one is
      what we want, and upgrading GLib made it flip.
      
      The reason is the same as the previous two fixes: the mock-secret-store
      expects to be able to insert items into a hash table and then iterate it
      and get them out in the same order. That was never guaranteed, and now
      doesn't happen.
      
      Let's keep a parallel list which keeps track of the order things were
      added. And then instead of iterating the hash table, we iterate this
      list.
      
      Closes #21
      7aba0e6a
    • Iain Lane's avatar
      secret-store: Sort fields alphabetically before outputting · 3091bf66
      Iain Lane authored
      The assumption that we'd get values out of a hash table in the same
      order we put them in stopped holding with GLib 2.59:
      
        ERROR:…/gnome-keyring/pkcs11/secret-store/test-secret-item.c:379:test_fields_attr:
        assertion failed: (memcmp (buffer, "name1\0value1\0name2\0value2", 26)
        == 0)
      
      Let's ensure a consistent order by sorting the fields before returning
      them.
      
      Closes #21.
      3091bf66
  4. 29 Jan, 2019 1 commit
    • Iain Lane's avatar
      egg: Write Proc-Type header before DEK-Info · 23fdfe72
      Iain Lane authored
      These headers (at least for OpenSSL) must come in this order. We
      shouldn't assume that `g_hash_table_foreach` is going to give a
      particular ordering - it's not guaranteed, and has changed with GLib
      2.59.
      
      Fixes #21
      23fdfe72
  5. 03 Jan, 2019 1 commit
  6. 29 Dec, 2018 1 commit
  7. 24 Dec, 2018 1 commit
  8. 15 Dec, 2018 1 commit
  9. 02 Dec, 2018 1 commit
  10. 31 Oct, 2018 1 commit
  11. 27 Oct, 2018 1 commit
  12. 10 Oct, 2018 1 commit
  13. 05 Oct, 2018 1 commit
    • Jacob Keller's avatar
      pam: lookup XDG_RUNTIME_DIR using get_any_env · b22d058a
      Jacob Keller authored
      The pam_gnome_keyring.so PAM module needs to find the daemon control
      file, which is stored in $XDG_RUNTIME_DIR/keyring/control.
      Unfortunately when commit 2ca51a0a ("daemon: Stop exporting the
      $GNOME_KEYRING_CONTROL env variable", 2014-03-06) switched to using
      XDG_RUNTIME_DIR preferentially over GNOME_KEYRING_CONTROL, it was looked
      up using getenv().
      
      Unfortunately XDG_RUNTIME_DIR isn't always set in the environment, but
      may need to be looked up from pam_getenv. Indeed, the function
      get_any_env already exists for this purpose.
      
      Because of the incorrect environment lookup, lookup_daemon will
      incorrectly report that the gnome-keyring-daemon is not running, even
      though it is. This results in starting the daemon multiple times, and
      potentially failing to shut it down, or start it correctly when changing
      the password.
      
      To fix this, move the code for determining the control file path from
      gkr-pam-client.c into gkr-pam-module.c This will using get_any_env(),
      and avoids the need for passing the pam_handle_t variable into
      gkr-pam-client.c
      
      It does mean that the control variable must be allocated with space,
      since we need to combine the environment value with a different suffix
      depending on if we use GNOME_KEYRING_CONTROL or XDG_RUNTIME_DIR.
      
      Add a function get_control_file, so that the logic for determining the
      control file path remains in one location.
      Signed-off-by: Jacob Keller's avatarJacob Keller <jacob.keller@gmail.com>
      b22d058a
  14. 28 Aug, 2018 1 commit
  15. 27 Aug, 2018 1 commit
  16. 16 Aug, 2018 1 commit
  17. 24 Jul, 2018 2 commits
  18. 18 Jul, 2018 1 commit
  19. 14 Jul, 2018 1 commit
  20. 12 Jun, 2018 3 commits
  21. 25 May, 2018 2 commits
  22. 13 May, 2018 1 commit
  23. 07 May, 2018 3 commits
  24. 18 Apr, 2018 1 commit
  25. 27 Mar, 2018 1 commit
  26. 24 Mar, 2018 1 commit
  27. 23 Mar, 2018 1 commit
  28. 20 Mar, 2018 2 commits