secretspec check shows incorrect information after rename project name

[unkcpz]

I have two keys set for my project, here is my secretspec.toml:

[project]
name = "dev-environment"
revision = "1.0"

[profiles.default]
# DATABASE_URL = { description = "Database connection string", required = true }

[profiles.development]
EINFRACZ_API_KEY = { description = "API key for einfracz" }
OPENROUTER_API_KEY = { description = "API Key for openrounter.ai" }

after I rename the project name, I run secretspec check it shows ticks for both keys but they are empty inside the devenv shell.

I have my devenv.yaml as

secretspec:
  enable: true
  provider: keyring
  profile: development
inputs:
  nixpkgs:
...

If I change the project name back, the keys are available again. I believe the behavior is correct that after change the project name I need to reset the keys, but the states are wrongly shown. Let me know if more debug info needed.

Is the provider "keyring" using linux native keyring or it uses desktop keyring?

UPDATE: I can confirmed using seahorse that shows keyring stored using desktop keyring not kernel keyring, and the key name has the project name with it that's why after rename the project lead to key not available.

Thus there are three unsound behaviors when secretspec interops with devenv:

1. if no proper secret key which is set in the secrectspec.yaml found yet, the devenv command frozen.
2. ctrl+c not gracefully kill the process but frozen there.
3. After press enter in the frozen session after ctrl+c, the process end but an empty key is created in my keyring app.

[domenkozar]

Thanks for the detailed report! I've been investigating this and have a question - the behavior you describe is unexpected based on the code.

How the check command should work:

When secretspec check runs, it:

1. Reads the project name from secretspec.toml
2. Looks up each secret from keyring at path secretspec/{project}/{profile}/{key}
3. Since you changed the project name, the lookup should fail (secrets are stored under the old name)
4. Missing required secrets should show as ✗ not ✓

Could you help clarify:

1. When you say "shows ticks for both keys" - are these green checkmarks (✓) or yellow circles (○)? Yellow circles indicate the secret has a default value.

2. Can you run this after renaming the project and share the full output?

   secretspec check --profile development

   This should show something like:

   Checking secrets in NEW-PROJECT-NAME (profile: development)...
   
   ✓ EINFRACZ_API_KEY - ...
   

   (showing the project name and whether each secret is ✓, ○, or ✗)

3. Are you running secretspec check directly, or through devenv? If through devenv, what command?

Regarding desktop keyring vs kernel keyring:

Secretspec uses the keyring crate which on Linux defaults to the Secret Service API (D-Bus based) - this means GNOME Keyring, KDE Wallet, or similar desktop-integrated keyrings. This is expected behavior for a secrets manager (more secure than kernel keyring for user secrets).

Looking forward to the additional details to help track down this bug!

[unkcpz]

When you say "shows ticks for both keys" - are these green checkmarks (✓) or yellow circles (○)? Yellow circles indicate the secret has a default value.

It shows the green checkmarks.

secretspec check --profile development

this give the same result and I have in my devenv.yaml

secretspec:
  enable: true
  provider: keyring
  profile: development

Are you running secretspec check directly, or through devenv? If through devenv, what command?

I think this is the root of the problem, I can reproduce it by deleting the key from my keyring app and then wrong the devenv shell it correctly shows the cross ✗ mark. But the CLI stuck at there ("Building shell") without prompt for secret. I do ctrl+c to bail and I found two empty keys are added to the keyring. I guess maybe the building is running in another thread and prompt for secret not properly handled?

If you can help me to narrow down where the problem happens I am volunteer to open a PR with the solution, I program in rust and contributed and familiar with keyring-rs crate as well.

More updates on what I found:

• I use fish but it can be reproduced in bash

[unkcpz]

Tried with the main branch of devenv and the prompt appears as expected. I think it was fixed by cachix/devenv@d492c2c.