This change is a part of the port PAM module from gnome-keyring
patch set.
These changes port gnome-keyring/egg/egg-unix-credentials.c to
libsecret/egg
Furthermore ports gnome-keyring/egg/egg-buffer.c to libsecret/egg
Signed-off-by: Dhanuka Warusadura <dhanuka@gnome.org>
This turns the `-Dgcrypt` build time option into a more generic
`-Dcrypto` option, which enables user to choose which cryptographic
library to link with. It currently supports libgcrypt (`libgcrypt`)
and GnuTLS (`gnutls`); for the latter, GnuTLS 3.8.2 is the minimum
required version.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
This moves low-level cryptographic functions into egg/egg-keyring1.c,
to make it easy to support multiple crypto backend libraries.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
This wraps gcry_mpi_t usage in the API with opaque strucs, so it would
be easier to port egg-dh to other crypto libraries.
Signed-off-by: Daiki Ueno <dueno@src.gnome.org>
These changes define the TPM2 API and add its implementations
to the incubation area (egg/).
Summary of the public API:
`egg_tpm2_initialize`: Start a TPM context.
`egg_tpm2_finalize`: End a TPM context.
`egg_tpm2_generate_master_password`: Generate and returns an
encrypted master password in `GBytes` format. TSS Marshaling,
GVariant serialization is used.
`egg_tpm2_decrypt_master_password`: Decrypts a master password
generated from `egg_tpm2_generate_master_password`. TSS
Unmarshaling, GVariant deserialization is used.
TPM2 API: TSS Enhanced System API (ESAPI)
Proposal: [extend file backend to use TPM2 derived encryption keys](https://gitlab.gnome.org/Teams/Engagement/gsoc-2021/-/issues/13)
Related MRs: [#86](https://gitlab.gnome.org/GNOME/libsecret/-/merge_requests/86)
Related Issues: [#63](https://gitlab.gnome.org/GNOME/libsecret/-/issues/63)
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.
Linux 3.4 added support for the MADV_DONTDUMP option to madvise(), which
requests that the covered memory not be included in coredumps. It makes
sense to use this to prevent cases where application crashes could
result in secrets being persisted to disk or included in dumps that are
uploaded to remote servers for analysis. I've avoided making this fatal
since there's a chance this code could be built on systems that have
MADV_DONTDUMP but run on systems that don't.
Apart from having more developer-friendly messages if the assertions go
wrong, it also prevents the assertions not being run if
`G_DISABLE_ASSERT` is defined (e.g. for performance reasons).
libsecret ships headers from valgrind, but they seem to come from an old
version. Update to the headers from valgrind-3.11.0-1.fc23.x86_64
in order to get VG_DO_ADDED_LEAK_CHECK definition.
https://bugzilla.gnome.org/show_bug.cgi?id=756766
libcrypt no longer supports setting our own threading callbacks,
and is thread-safe if we call gcry_check_version() before creating
threads.
Unfortunately we can't guarantee that we call gcry_check_version()
early enough, we try our best. Most of the callers of libsecret either
don't use libgcrypt, or also initialize it appropriately themselves.
Bump libgcrypt dependency to 1.4.5+, and have earlier versions use
the native pthread implementation of locking.
Allow parallel building and testing by using a single Makefile.am
Implement parallel testing using TAP, with various drivers and
compilers living in the build/ directory.
Fix all sorts of issues that this caused, including builddir != srcdir,
leaks in tests and so on.
It would have been nice to break out all the above into separate
commits ... blush.
Don't try to use G_IS_OBJECT() to see if an object was finalized
as this segfaults in corner cases, even with our crafty check
for a pointer within our memory space.
https://bugzilla.gnome.org/show_bug.cgi?id=705202
This does not cause a change in behavior (as evidenced by tests,
at least on linux when built with gcc) but is more correct code,
and less likely to be miscompiled.
The condition (i < 256) in the following loop is always false since i
is of type guchar, which is at most 255.
guchar i;
...
for (i = 1; i < 256; ++i) { ... }
This patch changes i to a larger type gint.
Also in the loop we have:
gcry_md_write (md2, &i, 1);
change it to use gcry_md_putc().
* Cleanup secure memory allocator for valgrind.
* Bring valgrind headers in.
* Add lots of suppressions for glib, gdbus, gcrypt
* Fix up a bunch of bugs where things weren't getting freed
* Add new 'make check-memory' target
