Secret Renaming 2nd Parameter Does not Recognize Fully Qualified Paths

[CMCDragonkai]

Describe the bug

The polykey secrets rename command fails when the second argument (<newSecretName>) is provided as a fully qualified path (e.g., VaultName:/NewSecretName). It incorrectly interprets the source path in the underlying operation, leading to an ENOENT: no such file or directory error wrapped within ErrorEncryptedFSError and ErrorPolykeyRemote. The command succeeds if <newSecretName> is provided as just the base name (e.g., NewSecretName). The first argument (<secretPath>) correctly requires the fully qualified path (VaultName:/SecretName).

To Reproduce

Steps to reproduce the behavior:

1. Ensure a vault and secret exist:

   # Example: Create a vault named 'TestVault' if it doesn't exist
   # polykey vaults create TestVault
   
   # Create a secret named 'OldSecret' within 'TestVault'
   echo "secret data" | polykey secrets write TestVault:/OldSecret

2. List secrets to confirm existence:

   polykey secrets ls TestVault
   # Expected output should include OldSecret

3. Attempt rename using fully qualified path for the new name (This triggers the bug):

   polykey secrets rename TestVault:/OldSecret TestVault:/NewSecret

4. Observe the error: The command fails with an ErrorPolykeyRemote detailing ErrorEncryptedFSError: ENOENT: no such file or directory, referencing an incorrect source path like /OldSecret and the target TestVault:/NewSecret. See the provided log in the Screenshots section for the exact error structure.

5. Attempt rename using only the base name for the new name (This works correctly):

   polykey secrets rename TestVault:/OldSecret NewSecret

6. Observe success: The command completes without error.

7. List secrets to confirm rename:

   polykey secrets ls TestVault
   # Expected output should now include NewSecret instead of OldSecret

Expected behavior

The polykey secrets rename <secretPath> <newSecretName> command should successfully rename the secret specified by <secretPath> (which must be fully qualified as Vault:/SecretName) to the name specified by <newSecretName>. The command should accept <newSecretName> in either the fully qualified format (Vault:/NewSecretName) or the base name format (NewSecretName). Both formats for the second argument should result in the secret being renamed within the vault context implied by the first argument, without generating an ENOENT or ErrorEncryptedFSError. The underlying file system operation should correctly reference the source and destination paths within the encrypted vault structure.

Screenshots

»» ~
♜ polykey secrets ls Orchestrator                  ⚡(master) pts/5 12:49:50
ORCHESTRATOR_MAINNET_PGDATABASE
ORCHESTRATOR_MAINNET_PGUSER
»» ~
♖ polykey secrets rename Orchestrator:/ORCHESTRATOR_MAINNET_PGDATABASE Orchestrator:/ORCHESTRATOR_MAINNET_PGHOST
ErrorPolykeyRemote: Remote error from RPC call
localHost ::1
localPort 55238
remoteHost ::1
remotePort 35397
command vaultsSecretsRename
timestamp Wed Apr 23 2025 12:50:24 GMT+1000 (Australian Eastern Standard Time)
cause: ErrorPolykeyUnexpected: An error originating outside Polykey was thrown - Unexpected error occurred: ErrorEncryptedFSError
cause: {"type":"ErrorEncryptedFSError","data":{"message":"ENOENT: no such file or directory, /ORCHESTRATOR_MAINNET_PGDATABASE -> Orchestrator:/ORCHESTRATOR_MAINNET_PGHOST","timestamp":"2025-04-21T06:26:00.811Z","data":{},"stack":"ErrorEncryptedFSError: ENOENT: no such file or directory, /ORCHESTRATOR_MAINNET_PGDATABASE -> Orchestrator:/ORCHESTRATOR_MAINNET_PGHOST\n    at /nix/store/aa7gpb3kinsvqbhrh8rd2507bppnf48g-polykey-cli-0.17.3/lib/node_modules/polykey-cli/dist/polykey.js:2158:122405\n    at async Object.maybeCallback (/nix/store/aa7gpb3kinsvqbhrh8rd2507bppnf48g-polykey-cli-0.17.3/lib/node_modules/polykey-cli/dist/polykey.js:2155:21076)\n    at async /nix/store/aa7gpb3kinsvqbhrh8rd2507bppnf48g-polykey-cli-0.17.3/lib/node_modules/polykey-cli/dist/polykey.js:2283:135351\n    at async /nix/store/aa7gpb3kinsvqbhrh8rd2507bppnf48g-polykey-cli-0.17.3/lib/node_modules/polykey-cli/dist/polykey.js:2246:9517\n    at async withF (/nix/store/aa7gpb3kinsvqbhrh8rd2507bppnf48g-polykey-cli-0.17.3/lib/node_modules/polykey-cli/dist/polykey.js:7:9819)","_errno":34,"_code":"ENOENT","_description":"no such file or directory","_syscall":"rename"}}
»» ~
♜ polykey secrets                                  ⚡(master) pts/5 12:50:24
Usage: polykey secrets [options] [command]
# ... (help text omitted for brevity) ...
»» ~
♖ polykey secrets rename Orchestrator:/ORCHESTRATOR_MAINNET_PGDATABASE ORCHESTRATOR_MAINNET_PGHOST
»» ~
# Success (no output indicates success for this command)
»» ~
♖ polykey secrets ls Orchestrator                  ⚡(master) pts/5 12:50:58
ORCHESTRATOR_MAINNET_PGHOST
ORCHESTRATOR_MAINNET_PGUSER

Platform

• Version: ["0.17.3","1.21.4","1","1"]

Additional context

• The error payload (ErrorEncryptedFSError) indicates the issue occurs deep within the encrypted file system layer, specifically during a rename syscall attempt.
• The specific message "ENOENT: no such file or directory, /ORCHESTRATOR_MAINNET_PGDATABASE -> Orchestrator:/ORCHESTRATOR_MAINNET_PGHOST" is crucial. It shows that the source path (/ORCHESTRATOR_MAINNET_PGDATABASE) is being incorrectly interpreted as an absolute path relative to the file system root (or an internal root) instead of being correctly resolved within the vault's context (Orchestrator:/ORCHESTRATOR_MAINNET_PGDATABASE). The target path (Orchestrator:/ORCHESTRATOR_MAINNET_PGHOST) appears correctly formed in the error message but the operation fails because the source is wrong.
• The issue seems localized to the parsing or handling of the second argument (<newSecretName>) of the secrets rename command when processed via the RPC call (vaultsSecretsRename) executed by the Polykey agent/daemon.
• The workaround is to provide only the base name of the secret as the second argument.

Notify maintainers

@aryanjassal @tegefaulkes

[linear]

ENG-587

[aryanjassal]

The reason behind this error is that the secrets rename command requires the first argument to be the full secret path including the vault name and the second argument as just the new name, and not the full path. Regardless, the error could have been more descriptive.

This issue would probably be fixed by the implementation of the mv command as that would operate more according to how its users expect it to work.

[CMCDragonkai]

Well it should support this too. It just doesn't work like how mv should work.

[CMCDragonkai]

We need secrets mv to work in an obvious way and secrets rename to work like the unix rename command:

Usage:
 rename [options] <expression> <replacement> <file>...

Rename files.

Options:
 -v, --verbose       explain what is being done
 -s, --symlink       act on the target of symlinks
 -n, --no-act        do not make any changes
 -a, --all           replace all occurrences
 -l, --last          replace only the last occurrence
 -o, --no-overwrite  don't overwrite existing files
 -i, --interactive   prompt before overwrite

 -h, --help          display this help
 -V, --version       display version

For more details see rename(1).

No need for all the options - just the default behaviour is good first.

[CMCDragonkai]

It works quite differently:

»» ~
 ♖ rename testing what testingbashfile                                                                                                                                          pts/1 14:56:43
`testingbashfile' -> `whatbashfile'

So you can see that expression and replacement and then the actual files.

Globbing in the future needs to smartly predict whether we are referring to within-vault globs or outside vault globbing. I remember that this was based on first... always assuming that we are talking about the local filesystem, and then only with explicit vault:... to indicate vault.

Actually confirm if this is true per our original specification for cp and related commands. I don't remember precisely now how we decided.