There were several issues in `secret_tool_action_lock()`:
- `g_autolist (GList)` isn't a correct type, as the list elements are
`SecretCollection`s, not `GList`s
- Separately from that, the list didn't take ownership of the elements
either in all cases
- We were leaking the `locked` and `context` variables
This commits just does away with all the g_auto* usage as it's the only
place in the code we're using it anyway, and just does all the freeing
at the end of the function.
Fixes: 015ea119 ("secret-tool: Add locking capabilities to secret tool")
Fixes: https://gitlab.gnome.org/GNOME/libsecret/-/issues/89
Context, secret tool currently does not have the capability to lock
keyring.
This capability was requested for specific use cases.
Updates have been made to the secret tool to lock keyrings.
Closes https://gitlab.gnome.org/GNOME/libsecret/-/issues/28
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.
* It's clearer what happens here: we try to remove as many matching
passwords as possible.
* Also rename secret_service_remove() to secret_service_clear()
* Rename secret_password_clear() which used to wipe password memory
to secret_password_wipe().
* The SecretService methods aren't used as frequently as the
password methods, and it's not really necessary to have a whole
bunch of extra varargs functions.
* Add varargs functions for building a GHashTable of attributes
