A GPtrArray allocated to temporarily hold (un)locked item paths was
not freed when the collection has a non-empty D-Bus path.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
In gnome-keyring, the secret items attributes are not visible until the keyring
is unlocked. But in libsecret, the synchronous secret search function unlocks
the keyring after and not before the attributes dbus pull.
So when the keyring is locked and you run secret_service_search_sync(), you get
hashed or empty attributes because the keyring was locked at the time these
attributes were pulled. If you run this function when the keyring is already
unlocked, there is no problem.
This commit moves the unlock routine before the attributes pull to make the
synchronous search function working correctly when the keyring is locked
initially.
Issues #6 gnome-shell#4780
In gnome-keyring, the secret items attributes are not visible until the keyring
is unlocked. But in libsecret, the asynchronous secret search function unlocks
the keyring after and not before the attributes dbus pull.
So when the keyring is locked and you run secret_service_search(), you get
hashed or empty attributes because the keyring was locked at the time these
attributes were pulled. If you run this function when the keyring is already
unlocked, there is no problem.
This commit moves the unlock routine before the attributes pull to make the
asynchronous search function working correctly when the keyring is locked
initially.
The secret_search_unlock_load_or_complete function should be renamed to
secret_service_load_or_complete. To keep this commit readable, it is done in
the next commit.
Issues #6 gnome-shell#4780
Calling g_cancellable_disconnect() inside a cancelled handler is a
guaranteed deadlock. Cancellables should only be canceled once, so we
don't need to worry about a second cancellation occurring. I think it's
sufficent to disconnect when the InitClosure is freed.
Fixes#86
GLib is discussing deprecating/removing it upstream [1] since it has
only limited uses. Next to that, it seems to bork stack traces here when
using ASAN (for which you also have to specify `G_SLICE=always-malloc`
and some other envvars too).
In other words, let's just get rid of using `GSlice` and call the
allocation APIs directly.
[1]: https://gitlab.gnome.org/GNOME/glib/-/issues/1079
That way, we have a function we can also call in case we want to provide
a synchronous constructor.
This also fixes some cases where the `EggTpm2Context` was not properly
cleaned up in case of some error paths.
Don't waste precious CI time reinstalling/upgrading packages.
Most of the scripts here were taken from GLib's CI scripts, but adjusted
to deal with dependencies that might change between branches rather than
different distros.
These changes temporarily fix the fedora:asan timeout error caused
by meson. With allow_failure keyword in place the pipeline will
complete even there is a timeout error in fedora:asan
Our GAsyncInitable implementations in SecretService, SecretCollection,
and SecretItem internally wrap GDBusProxy::init_async and perform
additional error processing. To chain up we used to pass around a
single GTask, which caused an issue in the (additional) error path:
GDBusProxy::init_async may have already called
g_task_return_boolean(task, TRUE) and in that case GLib produces the
following warning:
g_task_return_error: assertion '!task->ever_returned' failed
This fixes the issue by creating a temporary GTask around
GDBusProxy::init_async call.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
