summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Release 3.31.903.31.90Daiki Ueno2019-02-102-1/+7
|
* Merge branch 'wip/dueno/pkcs11-enable-in' into 'master'Daiki Ueno2019-02-101-0/+6
|\ | | | | | | | | pkcs11: Expose module to specific programs See merge request GNOME/gnome-keyring!8
| * pkcs11: Expose module to specific programsDaiki Ueno2019-02-091-0/+6
|/
* Merge branch 'jjardon/gnome-common-removal' into 'master'Daiki Ueno2019-02-091-20/+28
|\ | | | | | | | | autogen.sh: Use autoreconf instead deprecated gnome-common See merge request GNOME/gnome-keyring!10
| * autogen.sh: Use autoreconf instead deprecated gnome-commonJavier Jardón2019-02-091-20/+28
|/ | | | See https://wiki.gnome.org/Projects/GnomeCommon/Migration
* Merge branch 'wip/header-order' into 'master'Daiki Ueno2019-01-303-21/+92
|\ | | | | | | | | | | | | Don't assume iterating a hash table will give items in the same order they were inserted Closes #21 See merge request GNOME/gnome-keyring!9
| * gkm-mock: Also store objects in the order they are takenIain Lane2019-01-302-13/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With GLib 2.59, the `test-login-auto` test fails: Gcr-CRITICAL **: 14:34:24.126: expected prompt property 'choice-label' to be "Automatically unlock this keyring whenever I\342\200\231m logged in", but it is instead "" This is because, in `mock_secret_C_Initialize()` we assign two sets of fields to the mock module, one with `CKA_G_LOGIN_COLLECTION` → `CK_TRUE` and one with it pointing to `CK_FALSE`. This variable is used to decide, via `is_login_keyring()`, whether to call `setup_unlock_keyring_login()` or `setup_unlock_keyring_other()`. The first one sets `choice-label` to the empty string. The second one is what we want, and upgrading GLib made it flip. The reason is the same as the previous two fixes: the mock-secret-store expects to be able to insert items into a hash table and then iterate it and get them out in the same order. That was never guaranteed, and now doesn't happen. Let's keep a parallel list which keeps track of the order things were added. And then instead of iterating the hash table, we iterate this list. Closes #21
| * secret-store: Sort fields alphabetically before outputtingIain Lane2019-01-301-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The assumption that we'd get values out of a hash table in the same order we put them in stopped holding with GLib 2.59: ERROR:…/gnome-keyring/pkcs11/secret-store/test-secret-item.c:379:test_fields_attr: assertion failed: (memcmp (buffer, "name1\0value1\0name2\0value2", 26) == 0) Let's ensure a consistent order by sorting the fields before returning them. Closes #21.
| * egg: Write Proc-Type header before DEK-InfoIain Lane2019-01-291-5/+21
|/ | | | | | | | | These headers (at least for OpenSSL) must come in this order. We shouldn't assume that `g_hash_table_foreach` is going to give a particular ordering - it's not guaranteed, and has changed with GLib 2.59. Fixes #21
* Update Japanese translationRyuta Fujii2019-01-031-231/+260
|
* Merge branch 'mjog/reinstate-p11kit-module' into 'master'Daiki Ueno2018-12-294-0/+16
|\ | | | | | | | | | | | | Revert "pkcs11: Don't install p11-kit module configuration" Closes #20 See merge request GNOME/gnome-keyring!7
| * Revert "pkcs11: Don't install p11-kit module configuration"Michael James Gratton2018-12-254-0/+16
|/ | | | | | This reverts commit 5d8326eaf1ebce1cde2ee797c03f261da3159aae. Fixes #20
* Replace Bugzilla by Gitlab URL in DOAP fileAndre Klapper2018-12-151-1/+1
|
* Update French translationCharles Monzat2018-12-021-158/+165
|
* Update Occitan translationCédric Valmary2018-10-311-224/+259
|
* Update Esperanto translationCarmen Bianca BAKKER2018-10-271-205/+201
|
* Merge branch 'jk-fix-reading-xdg-runtime-dir' into 'master'Daiki Ueno2018-10-102-20/+55
|\ | | | | | | | | pam: lookup XDG_RUNTIME_DIR using get_any_env See merge request GNOME/gnome-keyring!5
| * pam: lookup XDG_RUNTIME_DIR using get_any_envJacob Keller2018-10-052-20/+55
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'tap-python3' into 'master'Daiki Ueno2018-08-282-41/+128
|\ | | | | | | | | build: Update tap scripts for Python 3 compat See merge request GNOME/gnome-keyring!4
| * build: Update tap scripts for Python 3 compatJan Tojnar2018-08-282-41/+128
|/ | | | | | | | | | | | | | | This 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/Python3Porting Also returned the following commits that are not included in Cockpit: * 918ab836fd23f9b2c0bf655c7f4f575bffff3189 * 7e75a62e846551c19b9c875f7b237a07ee3b93e1 * 7120f44ceedd5c10802781d64a5829b3c6d8e13f Maybe they should be upstreamed.
* Update MSGID_BUGS_ADDRESS in po/MakevarsPiotr Drąg2018-08-161-2/+2
|
* Merge branch 'wip/dueno/gitlab-ci' into 'master'Daiki Ueno2018-07-241-4/+4
|\ | | | | | | | | gitlab-ci: Switch to fedora:latest from fedora:rawhide See merge request GNOME/gnome-keyring!3
| * gitlab-ci: Switch to fedora:latest from fedora:rawhidewip/dueno/gitlab-ciDaiki Ueno2018-07-241-4/+4
|/
* Merge branch 'wip/dueno/openssh-parse' into 'master'Daiki Ueno2018-07-181-0/+15
|\ | | | | | | | | ssh-agent: Make public key parsing even robuster See merge request GNOME/gnome-keyring!2
| * ssh-agent: Make public key parsing even robusterwip/dueno/openssh-parseDaiki Ueno2018-07-141-0/+15
|/ | | | | | | This 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=795699
* Merge branch 'wip/dueno/gitlab-ci' into 'master'Daiki Ueno2018-06-122-2/+85
|\ | | | | | | | | build: Enable gitlab-ci See merge request GNOME/gnome-keyring!1
| * build: Enable gitlab-ciDaiki Ueno2018-06-121-0/+83
| |
| * pkcs11: Don't null terminate PKCS #11 string fieldsDaiki Ueno2018-06-121-2/+2
|/
* doap: add <description>Daiki Ueno2018-05-251-0/+10
|
* doap: add myself as maintainerDaiki Ueno2018-05-251-0/+8
|
* Revert "ssh-agent: Set may_block to TRUE while waiting for ssh-agent process"Daiki Ueno2018-05-131-1/+1
| | | | This reverts commit fb0d66553753bdc0d700cb5c0bb2803d0690e9ff.
* ssh-agent: Set may_block to TRUE while waiting for ssh-agent processDaiki Ueno2018-05-071-1/+1
| | | | | Potentially fix the busy loop reported in: https://bugzilla.gnome.org/show_bug.cgi?id=794848
* ssh-agent: Don't treat packet write error as fatalDaiki Ueno2018-05-071-2/+5
|
* ssh-agent: Make public key parsing robusterDaiki Ueno2018-05-073-11/+24
| | | | | | | | | | | | | | | | | Previously, _gkd_ssh_agent_parse_public_key() accepted OpenSSH v1 keys, because the second component of the key line looks like a valid base64 blob: 2048 65537 2444136... This patch checks that the component is really base64 encoded, by checking the length is a multiple of 4. Note that this solution is not perfect, as there could be a key with a public exponent whose decimal length is multiple of 4. More thorough approach would be to call ssh-keygen -l on each public key. https://bugzilla.gnome.org/show_bug.cgi?id=795699
* Update Romanian translationDaniel Șerbănescu2018-04-181-203/+202
| | | | (cherry picked from commit d8b6de0c65c4206bc47942963c285d4ee76cf0c6)
* Updated Slovenian translationMatej Urbančič2018-03-271-253/+241
|
* login: Use password from login keyring once for the same interactionDaiki Ueno2018-03-241-7/+13
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794631
* egg: Port cosmetic fixes to egg-secure-memory.c from libsecretDaiki Ueno2018-03-231-4/+4
|
* login: Use the same label as before when storing passwordDaiki Ueno2018-03-202-1/+6
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794500
* ssh-agent: Don't be too verbose on password promptDaiki Ueno2018-03-201-3/+1
| | | | | | | This partially reverts the change in 869b5c6d, so as not to display duplicate words on the password prompt. https://bugzilla.gnome.org/show_bug.cgi?id=794500
* build: Suppress compiler warnings with -Wdiscarded-qualifiersDaiki Ueno2018-03-201-2/+2
|
* ssh-agent: Make EOF handling robusterDaiki Ueno2018-03-193-5/+12
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794369
* ssh-agent: Allow opening multiple connections to inferior ssh-agentDaiki Ueno2018-03-196-46/+51
| | | | | | | | | Previously, it keeps only one connection to the inferior ssh-agent process. That prevented simultaneous access to gnome-keyring's ssh-agent service. With this patch, it always opens a new connection to the inferior ssh-agent process when a new client connects. https://bugzilla.gnome.org/show_bug.cgi?id=794369
* ssh-agent: Use the same parameters for accessing login keyringDaiki Ueno2018-03-191-2/+3
| | | | | | | | | | | | | When looking up a secret in the login keyring, do not supply any schema in the criteria, while using "org.freedesktop.Secret.Generic" as schema when storing it. This is for backward compatibility with gnome-keyring 2.29, which used "org.gnome.keyring.EncryptionKey" as schema. In addtion, use the same label for the newly stored passwords as before. https://bugzilla.gnome.org/show_bug.cgi?id=794368
* login: Allow different sets of secret attributes for lookup/storingDaiki Ueno2018-03-191-5/+23
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794368
* ssh-agent: Propagate stderr to journal when spawning ssh-addDaiki Ueno2018-03-194-3/+51
| | | | | | | | | | | ssh-add fails in certain occasions, such as when the file permissions of private key is not unsafe. To help diagnostics, propagate the stderr output from the command to journal. As the ssh commands send error message with trailing CR for each line, we need to scrub it so as not to confuse journald. https://bugzilla.gnome.org/show_bug.cgi?id=794361
* Release 3.28.0.13.28.0.1Daiki Ueno2018-03-132-1/+4
|
* build: Fix linking of test modules with "-z defs"Daiki Ueno2018-03-132-2/+2
| | | | | | Split out mock-interaction.c from libegg.la to libegg-test.la. https://bugzilla.gnome.org/show_bug.cgi?id=794274
* Release 3.28.03.28.0Daiki Ueno2018-03-122-1/+4
|
* build: Fix tap-driver to parse TAP directiveDaiki Ueno2018-03-051-2/+5
|
View Lorry Controller Status