gnome-keyring merge requestshttps://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests2018-06-12T14:43:00Zhttps://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/1build: Enable gitlab-ci2018-06-12T14:43:00ZDaiki Uenobuild: Enable gitlab-cihttps://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/2ssh-agent: Make public key parsing even robuster2021-01-15T21:16:57ZDaiki Uenossh-agent: Make public key parsing even robusterThis amends commit f3f3cc70 to take into account of the fact that the
key type is prefixed to the decoded blob. Suggested by Mantas
Mikulėnas in:
https://bugzilla.gnome.org/show_bug.cgi?id=795699This amends commit f3f3cc70 to take into account of the fact that the
key type is prefixed to the decoded blob. Suggested by Mantas
Mikulėnas in:
https://bugzilla.gnome.org/show_bug.cgi?id=795699https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/3gitlab-ci: Switch to fedora:latest from fedora:rawhide2018-07-24T10:45:43ZDaiki Uenogitlab-ci: Switch to fedora:latest from fedora:rawhidehttps://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/4build: Update tap scripts for Python 3 compat2018-08-30T05:58:01ZJan Tojnarbuild: Update tap scripts for Python 3 compatThis replaces tap-driver and tap-gtester with fresh versions from Cockpit.
* https://github.com/cockpit-project/cockpit/pull/9500
* https://wiki.gnome.org/Initiatives/GnomeGoals/Python3PortingThis replaces tap-driver and tap-gtester with fresh versions from Cockpit.
* https://github.com/cockpit-project/cockpit/pull/9500
* https://wiki.gnome.org/Initiatives/GnomeGoals/Python3Portinghttps://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/5pam: lookup XDG_RUNTIME_DIR using get_any_env2019-12-15T20:06:37ZJacob Kellerpam: lookup XDG_RUNTIME_DIR using get_any_envThe pam_gnome_keyring.so PAM module needs to find the daemon control
file, which is stored in $XDG_RUNTIME_DIR/keyring/control.
Unfortunately when commit 2ca51a0aef5b ("daemon: Stop exporting the
$GNOME_KEYRING_CONTROL env variable", 201...The pam_gnome_keyring.so PAM module needs to find the daemon control
file, which is stored in $XDG_RUNTIME_DIR/keyring/control.
Unfortunately when commit 2ca51a0aef5b ("daemon: Stop exporting the
$GNOME_KEYRING_CONTROL env variable", 2014-03-06) switched to using
XDG_RUNTIME_DIR preferentially over GNOME_KEYRING_CONTROL, it was looked
up using getenv().
Unfortunately XDG_RUNTIME_DIR isn't always set in the environment, but
may need to be looked up from pam_getenv. Indeed, the function
get_any_env already exists for this purpose.
Because of the incorrect environment lookup, lookup_daemon will
incorrectly report that the gnome-keyring-daemon is not running, even
though it is. This results in starting the daemon multiple times, and
potentially failing to shut it down, or start it correctly when changing
the password.
To fix this, move the code for determining the control file path from
gkr-pam-client.c into gkr-pam-module.c This will using get_any_env(),
and avoids the need for passing the pam_handle_t variable into
gkr-pam-client.c
It does mean that the control variable must be allocated with space,
since we need to combine the environment value with a different suffix
depending on if we use GNOME_KEYRING_CONTROL or XDG_RUNTIME_DIR.
Add a function get_control_file, so that the logic for determining the
control file path remains in one location.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/6Create and unlock login keyring for passwordless accounts2020-03-04T14:25:01ZWill ThompsonCreate and unlock login keyring for passwordless accountsWithout this change, passwordless accounts (which are not created by gnome-initial-setup) do not automatically get a login keyring, so launching an application (such as Chromium) which uses the login keyring causes the user to be prompte...Without this change, passwordless accounts (which are not created by gnome-initial-setup) do not automatically get a login keyring, so launching an application (such as Chromium) which uses the login keyring causes the user to be prompted to create one.
The stock version of gnome-control-center does not permit creating passwordless accounts, but there's nothing to stop an administrator creating one the old-fashioned way.
Endless's fork of gnome-control-center adds UI to create passwordless accounts, which makes this situation more likely.
Endless also patches gnome-initial-setup to allow creating the initial administrator account with no password, but that account doesn't hit this problem because gnome-initial-setup manually creates a keyring and sets its passphrase to "" when it's done. (This keyring is not unlocked at login, but it is silently unlocked when it's needed, which is equivalent from the user's perspective.)
This is a continuation of c5da2060b1b6f7649463dacdfcb55dd6bee803af where @matthiasc tried to make this work for gnome-initial-setup's benefit. The corresponding change in gnome-initial-setup was subsequently reverted https://gitlab.gnome.org/GNOME/gnome-initial-setup/commit/b249c898668e02c771ce1707368d2919d3b2f7de because that change didn't work – I think this is why.https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/7Revert "pkcs11: Don't install p11-kit module configuration"2019-01-07T10:26:42ZMichael GrattonRevert "pkcs11: Don't install p11-kit module configuration"This reverts commit 5d8326eaf1ebce1cde2ee797c03f261da3159aae.
Fixes #20This reverts commit 5d8326eaf1ebce1cde2ee797c03f261da3159aae.
Fixes #20https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/8pkcs11: Expose module to specific programs2020-09-14T13:53:10ZDaiki Uenopkcs11: Expose module to specific programsSee !7.
@mjog would you be able to check if geary's certificate pinning still works with this change?See !7.
@mjog would you be able to check if geary's certificate pinning still works with this change?https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/9Don't assume iterating a hash table will give items in the same order they we...2019-01-30T17:13:55ZIain LaneDon't assume iterating a hash table will give items in the same order they were insertedThis was never supported, and started to not happen with GLib 2.59. In gnome-keyring we had assumed this was true in various places.This was never supported, and started to not happen with GLib 2.59. In gnome-keyring we had assumed this was true in various places.https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/10autogen.sh: Use autoreconf instead deprecated gnome-common2019-02-09T17:13:35ZJavier Jardónautogen.sh: Use autoreconf instead deprecated gnome-commonSee https://wiki.gnome.org/Projects/GnomeCommon/MigrationSee https://wiki.gnome.org/Projects/GnomeCommon/Migrationhttps://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/11Fixes #26: restore behaviour before b22d058a when control file isn't found2019-03-02T06:32:36ZRoderich SchuppFixes #26: restore behaviour before b22d058a when control file isn't foundSee my analysis in #26See my analysis in #26https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/12test-gkd-ssh-agent-service: Avoid race condition with server thread2019-04-16T11:13:52ZSimon McVittietest-gkd-ssh-agent-service: Avoid race condition with server threadThese tests create a server thread in setup() and join it in teardown(),
but there are various race conditions between them that can cause the
test to hang. These are particularly reproducible when building on a
single-CPU machine or VM,...These tests create a server thread in setup() and join it in teardown(),
but there are various race conditions between them that can cause the
test to hang. These are particularly reproducible when building on a
single-CPU machine or VM, and particularly in the startup_shutdown
test (which doesn't do anything, so it runs teardown() immediately
after setup()).
It's possible to get this preemption pattern:
___ Main thread ___ ___ Server thread ___
g_thread_new() (starts)
g_cond_wait() (blocks)
...
g_cond_signal()
(gets preempted here)
exit setup()
enter teardown()
g_main_loop_quit()
g_main_loop_run()
which means g_main_loop_run() will never terminate, because it wasn't
running yet when the main thread told the GMainLoop to quit, and the
main thread won't tell it to quit again.
One way to solve this would be for the server thread to signal
test->cond from an idle callback instead of directly from
server_thread(), to guarantee that the GMainLoop is already running.
However, it seems easier to reason about if we avoid GMainLoop and
iterate the main context directly.
[Debian bug #909416](https://bugs.debian.org/909416)https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/13Fail tests if still running after 5 minutes2019-03-10T10:29:18ZSimon McVittieFail tests if still running after 5 minutesWhen diagnosing build-time tests that get stuck, such as the one in
!12, it's helpful for the test to abort after some reasonable timeout
(leaving a core dump and any previous log output), rather than relying on
some external process to ...When diagnosing build-time tests that get stuck, such as the one in
!12, it's helpful for the test to abort after some reasonable timeout
(leaving a core dump and any previous log output), rather than relying on
some external process to kill the entire build after a longer arbitrary
timeout like an hour (which would also terminate whatever test harnesses,
logging, etc. are in use, limiting the available diagnostics).
The implementation of egg_tests_set_fatal_timeout() is heavily based
on code that I contributed to dbus. The choice of a 5 minute timeout is
completely arbitrary (dbus mostly uses 1 minute): please adjust up or
down as appropriate.
If a particular test case is known to be particularly slow, you can call
egg_tests_set_fatal_timeout() in setup() and/or teardown() to reset the
timer, effectively providing a per-test-case timeout. I haven't done
this in any of the tests.
When running under valgrind or qemu, or on a particularly slow CPU,
the environment variable TEST_FATAL_TIMEOUT_MULTIPLIER can be set to
an integer to multiply all of these timeouts. For example,
TEST_FATAL_TIMEOUT_MULTIPLIER=10 has worked well when running dbus tests
under valgrind, and 20 works well for qemu-system-risc64.
---
I used this while debugging the issue that led to !12. At some point I'll probably contribute something similar to GLib, but that will be new API, so it won't be available without a new GLib dependency.
Please adjust the timeout based on what you think is a reasonable maximum time for a test to take (and then perhaps double it, to account for slower architectures like ARM and MIPS).https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/14egg: Request that secure memory not be dumped to disk2019-04-20T06:30:50ZMatthew Garrettegg: Request that secure memory not be dumped to diskLinux 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 p...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.https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/15Fix the check for MADV_DONTDUMP2019-06-02T12:49:01ZMatthew GarrettFix the check for MADV_DONTDUMPAC_CHECK_DEFINE doesn't take an include path, so this is broken - we
should be using AX_CHECK_DEFINE instead.AC_CHECK_DEFINE doesn't take an include path, so this is broken - we
should be using AX_CHECK_DEFINE instead.https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/16rpc-layer: fix build with musl-libc2019-05-10T13:58:39ZDaiki Uenorpc-layer: fix build with musl-libcThe recent POSIX suggests to include <sys/select.h> for select().
Reported by Anthony G. Basile.
Fixes #29.The recent POSIX suggests to include <sys/select.h> for select().
Reported by Anthony G. Basile.
Fixes #29.https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/17build: Remove configure check for MADV_DONTDUMP2019-05-15T05:06:41ZDaiki Uenobuild: Remove configure check for MADV_DONTDUMPIt can be checked in the source code instead.
Fixes #30 It can be checked in the source code instead.
Fixes #30 https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/18dbus: Implement secret portal backend2019-10-01T16:19:14ZDaiki Uenodbus: Implement secret portal backendThis adds a portal backend interface that sends application's master secret through FD passing.This adds a portal backend interface that sends application's master secret through FD passing.https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/19Possible race fix2019-09-05T19:26:41ZBenjamin BergPossible race fixWe are seeing issues, this might fix them (a quick test during GUADEC suggests it actually does).
Would be good to wait a bit longer; @carlosg is running the patch for now to see if he continues to run in to the issue. Either way, the p...We are seeing issues, this might fix them (a quick test during GUADEC suggests it actually does).
Would be good to wait a bit longer; @carlosg is running the patch for now to see if he continues to run in to the issue. Either way, the patch should be safe to merge.https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/20Remove tap-gtester, rely on GLib 2.38+ built-in TAP output instead2019-09-26T14:30:38ZSimon McVittieRemove tap-gtester, rely on GLib 2.38+ built-in TAP output insteadGLib 2.62+ outputs TAP by default, which breaks the tap-gtester
script's expectations. In older GLib versions since 2.38, --tap is an
opt-in to the TAP output mode, so use that.
This is essentially the same issue as
https://github....GLib 2.62+ outputs TAP by default, which breaks the tap-gtester
script's expectations. In older GLib versions since 2.38, --tap is an
opt-in to the TAP output mode, so use that.
This is essentially the same issue as
https://github.com/cockpit-project/cockpit/pull/11998 (cockpit was the
source of the tap-gtester script), GNOME/gcr!19, and GNOME/libsecret!5.
Bug-Debian: https://bugs.debian.org/940157