This makes the internal logic of _secret_attributes_validate public,
so applications can check and recover when an invalid attributes table
is passed to other libsecret API, such as secret_service_clear.
This resets self->etag only after successful load of the contents, by
using a temporary variable and checking error of
g_file_replace_contents_finish, etc.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
As the GVariant returned in secret_service_real_prompt_finish should
be already sunk by secret_prompt_perform_finish, calling
g_variant_ref_sink actually increases the refcount and causes a leak.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
The GVariant returned in
secret_service_get_secret{,s}_for_dbus_path{,s}_finish should be
unref'ed after use.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
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.
