cargo-credential-libsecret: load libsecret only once

[biglben]

Previously, libsecret was repeatedly loaded and unloaded—at least twice during cargo login (once for action get and once for action login). This caused issues where calls could hang indefinitely due to glib failing to clean up properly (some threads still running after unloading) and generating numerous error messages:

cargo login --registry ownreg
    Updating `ownreg` index
please paste the token for ownreg below


(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot register existing type 'SecretService'

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot add private field to invalid (non-instantiatable) type '<invalid>'

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot register existing type 'SecretBackend'

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:100727): GLib-CRITICAL **: 08:59:54.568: g_once_init_leave_pointer: assertion 'result != 0' failed

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

Now, libsecret is stored in a OnceLock, ensuring it is only loaded once, preventing unnecessary unload/reload cycles.

Fixes #15603

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

The main thing I'm wondering is if this is the right layer of caching.

Alternatively, we could lazy load these fields in LibSecretCredential and use a OnceLock on that in the cargo side of the code. Or we could skip OnceLock and have a cache on GlobalContext which would give users control over lifetimes.

A potential way to side step any of that is for us to not load the library multiple times. It looks like during login() we call registry() to get Registry::new_handle() so we can call registry.host() . We might be able to split registry() into registry() and registry_cfg() and use the latter in login(), avoiding looking up the token just to throw it away.

[biglben]

Thanks for your feedback.

The main thing I'm wondering is if this is the right layer of caching.

Alternatively, we could lazy load these fields in LibSecretCredential and use a OnceLock on that in the cargo side of the code. Or we could skip OnceLock and have a cache on GlobalContext which would give users control over lifetimes.

I will check GlobalContext.
Could you clarify your approach to lazy loading these fields in LibSecretCredential? Are you suggesting storing Library in LibSecretCredential and using a OnceLock<LibSecretCredential> in credential_action, in the auth module itself or somewhere else?

A potential way to side step any of that is for us to not load the library multiple times. It looks like during login() we call registry() to get Registry::new_handle() so we can call registry.host() . We might be able to split registry() into registry() and registry_cfg() and use the latter in login(), avoiding looking up the token just to throw it away.

This would be a good optimization, but it wouldn't fully resolve the issue. I discovered that libsecret is also loaded multiple times when multiple registries are present.

By the way, should i open a issue too?

[epage]

Let's keep things simple for the first pass and put the OnceLock inside of cargo-the-lib. The GlobalContext change can come later.

[weihanglo]

@rustbot author

Let us know if you have any question!

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[biglben]

@rustbot ready

Sorry for the delay, I was busy with a lot of other stuff and forgot about this.

[epage]

nit: its a big help for reviewers to split up commits. In this case, I'd do

• Version bump
• Switch to LibSecretCredential owning libsecret
• Add the OnceLock

I mention this more for future reference to the point that I wasn't going to mention it if there wasn't other feedback to avoid you doing extra churn on this without a reason.