egg/egg-unix-credentials.c | 22 19 3 - 0 !
1 file changed, 19 insertions( ), 3 deletions(-)

 support gnu/kfreebsd

===================================================================

pkcs11/gkm/test-data-der.c | 2 1 1 - 0 !
pkcs11/gkm/test-timer.c | 2 1 1 - 0 !
pkcs11/gnome2-store/test-gnome2-private-key.c | 2 1 1 - 0 !
3 files changed, 3 insertions( ), 3 deletions(-)

 skip a few failing tests that have already been reported upstream

See https://bugzilla.gnome.org/754633 and  https://bugzilla.gnome.org/767122
===================================================================

egg/egg-armor.c | 26 21 5 - 0 !
1 file changed, 21 insertions( ), 5 deletions(-)

 egg: write proc-type header before dek-info

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

pkcs11/secret-store/gkm-secret-fields.c | 22 16 6 - 0 !
1 file changed, 16 insertions( ), 6 deletions(-)

 secret-store: sort fields alphabetically before outputting
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

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.

pkcs11/gkm/gkm-mock.c | 67 57 10 - 0 !
pkcs11/secret-store/gkm-secret-fields.c | 4 1 3 - 0 !
2 files changed, 58 insertions( ), 13 deletions(-)

 gkm-mock: also store objects in the order they are taken
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

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

daemon/ssh-agent/test-gkd-ssh-agent-service.c | 23 11 12 - 0 !
1 file changed, 11 insertions( ), 12 deletions(-)

 test-gkd-ssh-agent-service: avoid race condition with server thread

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)
                                        ...
                                        g_cond_signal()
                                        (gets preempted here)
     exit setup()
     enter teardown()
     g_main_loop_quit()
                                        g_main_loop_run()

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.

(I couldn't reproduce this under gdb, because it's a race condition and
is timing-dependent.)

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: Simon McVittie <[email protected]>
Bug-Debian: https://bugs.debian.org/909416