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.
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>
Some Secret Service API backend implementations (like keepassxc)
throws UnknownObject (instead of UnknownMethod as gnome-keyring do)
after creating an item in the non-existent
/org/freedesktop/secrets/aliases/default.
The documentation of g_dbus_error_register_error_domain suggests that
the argument passed to it should not be volatile.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
When full filenames are used in generated sources it makes the resulting
debug packages non-reproducible. Best practise is to use basename instead.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Our official instructions only tell how to build with Meson, our CI is
only done with Meson and I wouldn't be surprised if most developers only
used Meson as well.
In other words, the autotools build is outdated. Let's say our goodbye
and drop it in the next stable release.
