When libgcrypt is available, libsecret links with it. When dynamic
linking is used, there is no problem: libsecret.so has a NEEDED
pointing to libgcrypt, so linking an application with -lsecret works
fine. However, when doing static linking, you must specify the entire
chain of libraries, otherwise you get unresolved symbols errors, such
as:
host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libsecret-1.a(libsecret_1_la-secret-session.o): In function `request_open_session_aes':
build/libsecret-0.18.3/libsecret/secret-session.c:99: undefined reference to `gcry_mpi_release'
build/libsecret-0.18.3/libsecret/secret-session.c:101: undefined reference to `gcry_mpi_aprint'
build/libsecret-0.18.3/libsecret/secret-session.c:107: undefined reference to `gcry_free'
In order to solve this, we simply need to indicate in the Libs.private
field of the .pc file that we depend on libgcrypt.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Retrieved from:
https://git.buildroot.net/buildroot/tree/package/libsecret/0001-libsecret.pc-add-Libs.private-field-for-libgcrypt.patch]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This interface provides a separation between the
frontend (secret_password*) and the backend (SecretService). That
makes it easier to replace SecretService with a custom backend
implementation.
Now with meson build system libsecret FTBFS without valgrind installed.
Two issues: (1) egg-testing.c depends on valgrind/valgrind.h unnecessarily;
(2) we forgot to add "build" directory as a header directory for meson.
This commit resolves both of them.
The condition checking g_task_is_valid was inverted, resulting in errors
being ignored.
Move the check to a g_return_val_if_fail to be in line with all other
uses of g_task_is_valid.
Fixes https://bugs.archlinux.org/task/63666
Previously, we used a custom TAP driver written in Python. Now that
Automake's TAP driver has sufficient features, the script should be no
longer necessary.
Given these functions take a hash table built from valid attributes,
there is no need to re-validate. This is also consistent with the
secret_service API.
This adds the secret_value_unref_to_password function that
unreferences and returns the stored secret in non-pageable memory.
This is supposed to be used with secret_password_lookup_binary*
functions.
This adds a set of functions that takes a SecretValue instead of a
text password when storing a secret. This is useful if the stored
password is not null-terminated.
This adds a set of functions that return a SecretValue instead of a
text password when looking up a secret. This is useful if the stored
password is not null-terminated.
This is a ground work for adding a local storage backend. As
SecretItem is derived from GDBusProxy, it cannot be simply exposed to
the application through the secret_password_search() if the item is
not backed by the DBus API. This adds an abstract interface
representing a read-only view of a secret item for that purpose.