1. 15 May, 2019 2 commits
  2. 10 May, 2019 2 commits
  3. 20 Apr, 2019 1 commit
    • Matthew Garrett's avatar
      egg: Request that secure memory not be dumped to disk · e6822428
      Matthew Garrett authored
      Linux 3.4 added support for the MADV_DONTDUMP option to madvise(), which
      requests that the covered memory not be included in coredumps. It makes
      sense to use this to prevent cases where application crashes could
      result in secrets being persisted to disk or included in dumps that are
      uploaded to remote servers for analysis. I've avoided making this fatal
      since there's a chance this code could be built on systems that have
      MADV_DONTDUMP but run on systems that don't.
  4. 16 Apr, 2019 1 commit
    • Simon McVittie's avatar
      test-gkd-ssh-agent-service: Avoid race condition with server thread · 91bc9368
      Simon McVittie authored
      These tests create a server thread in setup() and join it in teardown(),
      but there are various race conditions between them that can cause the
      test to hang. These are particularly reproducible when building on a
      single-CPU machine or VM, and particularly in the startup_shutdown
      test (which doesn't do anything, so it runs teardown() immediately
      after setup()).
      It's possible to get this preemption pattern:
           ___ Main thread ___                ___ Server thread ___
           g_thread_new()                     (starts)
           g_cond_wait() (blocks)
                                              (gets preempted here)
           exit setup()
           enter teardown()
      which means g_main_loop_run() will never terminate, because it wasn't
      running yet when the main thread told the GMainLoop to quit, and the
      main thread won't tell it to quit again.
      One way to solve this would be for the server thread to signal
      test->cond from an idle callback instead of directly from
      server_thread(), to guarantee that the GMainLoop is already running.
      However, it seems easier to reason about if we avoid GMainLoop and
      iterate the main context directly.
      Signed-off-by: 's avatarSimon McVittie <smcv@debian.org>
      Bug-Debian: https://bugs.debian.org/909416
  5. 16 Mar, 2019 1 commit
  6. 02 Mar, 2019 4 commits
  7. 22 Feb, 2019 1 commit
  8. 10 Feb, 2019 2 commits
  9. 09 Feb, 2019 3 commits
  10. 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
    • 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
      Closes #21
    • 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:
        assertion failed: (memcmp (buffer, "name1\0value1\0name2\0value2", 26)
        == 0)
      Let's ensure a consistent order by sorting the fields before returning
      Closes #21.
  11. 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
      Fixes #21
  12. 03 Jan, 2019 1 commit
  13. 29 Dec, 2018 1 commit
  14. 24 Dec, 2018 1 commit
  15. 15 Dec, 2018 1 commit
  16. 02 Dec, 2018 1 commit
  17. 31 Oct, 2018 1 commit
  18. 27 Oct, 2018 1 commit
  19. 10 Oct, 2018 1 commit
  20. 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
      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>
  21. 28 Aug, 2018 1 commit
  22. 27 Aug, 2018 1 commit
  23. 16 Aug, 2018 1 commit
  24. 24 Jul, 2018 2 commits
  25. 18 Jul, 2018 1 commit
  26. 14 Jul, 2018 1 commit
  27. 12 Jun, 2018 3 commits