wallet: Wallet name validation does not reject filesystem-invalid/reserved/directory characters #35907

Problem

Wallet names that eventually may act as directory names have a somewhat lenient validation ("", "..", "./"). This may seem to be a minor issue, arguably, cause it somehow works out, but it may probably lead to inconsistencies (loosely speaking) when a reserved character is mistakenly used. It may really help to add a pattern check against reserved/invalid directory names when creating a wallet just to prevent such situations. I created a PR for only a single pattern #35768 (all spaces). But seems there are more such patterns currently being accepted.

Demonstrations

Nested wallets

These are wallet names that contain a /

ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ ./bitcoin-cli createwallet "tests/wallets/wallet1"
{
  "name": "tests/wallets/wallet1"
}
ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ tree ~/.bitcoin/regtest/wallets/
/home/ratedg/.bitcoin/regtest/wallets/
└── tests
    └── wallets
        └── wallet1
            ├── wallet.dat
            └── wallet.dat-journal

4 directories, 2 files
ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$

Empty wallet names

These are wallets with no other characters but spaces

ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ ./bitcoin-cli createwallet " " &&  ./bitcoin-cli createwallet "  " && ./bitcoin-cli createwallet "   "
{
  "name": " "
}
{
  "name": "  "
}
{
  "name": "   "
}
ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ tree ~/.bitcoin/regtest/wallets/
/home/ratedg/.bitcoin/regtest/wallets/
├──  
│   ├── wallet.dat
│   └── wallet.dat-journal
├──   
│   ├── wallet.dat
│   └── wallet.dat-journal
└──    
    ├── wallet.dat
    └── wallet.dat-journal

4 directories, 6 files

UI display

<img width="877" height="278" alt="Image" src="https://github.com/user-attachments/assets/ad2c1220-c9e3-4500-9194-05b89b339517" />

Hidden folder names

These are wallet names beginning with a .

ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ ./bitcoin-cli createwallet ".testwallet"
{
  "name": ".testwallet"
}
ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ tree ~/.bitcoin/regtest/wallets/
/home/ratedg/.bitcoin/regtest/wallets/

0 directories, 0 files
ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ tree -a ~/.bitcoin/regtest/wallets/
/home/ratedg/.bitcoin/regtest/wallets/
└── .testwallet
    ├── wallet.dat
    └── wallet.dat-journal

2 directories, 2 files
ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ 

Windows path separator

These are wallet names that contain a \

ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ ./bitcoin-cli createwallet "\\\\"
{
  "name": "\\\\"
}
ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$ tree ~/.bitcoin/regtest/wallets/
/home/ratedg/.bitcoin/regtest/wallets/
└── \\
    ├── wallet.dat
    └── wallet.dat-journal

2 directories, 2 files
ratedg@0xratedg:~/projects/contributions/bitcoin/build/bin$

Probably this change may not be urgent, but it might be necessary

Proposed solution

Validate wallet names against an agreed pattern. Following maflcko's comment, only the create path should be validated for now.

Conclusion

If this is expected behavior or not considered worth addressing, please feel free to close this issue. I wanted to raise the observation in case it is useful or was previously overlooked.

I reviewed the wallet creation path in the current tree against the behavior described in this issue.

The issue appears to originate from the fact that wallet_name is subsequently interpreted as a filesystem path. CreateWallet() currently rejects an empty name, but names containing path separators, whitespace-only names, and other filesystem-significant forms can proceed to GetWalletPath() and ultimately influence the directory structure.

In particular, this permits cases such as:

"tests/wallets/wallet1" " " " " ".testwallet"

which can result in nested, whitespace-only, or hidden wallet directories.

I think the appropriate fix is to introduce validation specifically at the new-wallet creation boundary, rather than tightening GetWalletPath() itself. The latter is used for existing wallet/path handling, so applying stricter validation there could create a backward-compatibility problem for wallets that already exist.

The proposed change would therefore be:

createwallet ↓ validate new wallet name ↓ GetWalletPath() ↓ create wallet

rather than:

createwallet ↓ GetWalletPath() ↓ filesystem path interpretation

I would also add regression coverage for the cases demonstrated in this issue, including path separators, whitespace-only names, and hidden names, and verify that rejected names do not result in filesystem objects being created.

The exact accepted wallet-name grammar should probably be agreed upon before choosing a validation implementation. In particular, I would avoid introducing an arbitrary regex without first establishing whether the intended contract is "single filesystem component" or a more restrictive platform-independent wallet-name character set.

This keeps the proposed change narrowly scoped to wallet creation, preserves existing-wallet compatibility, and gives us explicit regression coverage for the observed behavior.

If there is agreement on the intended wallet-name semantics, I can prepare the corresponding focused patch and tests.

The wallet name validation leniency is a filesystem-safety bug, not just a UX issue. If wallet names are later used as directory components (e.g. wallets/<name>/), accepting .., spaces, or platform-specific reserved names (CON, NUL on Windows) allows path-traversal or directory-creation failures on cross-platform deployments.

Two fixes worth tracking:

1. Reject names that contain path separators, ., .., or any character that is invalid in the target OS directory name.
2. Normalize the wallet name through a whitelist ([a-zA-Z0-9_-]) before creating the directory.

HeartFlow angle: this is a boundary-violation pattern — user-controlled input is passed to filesystem APIs without canonicalization, and the validation only blocks the most obvious cases. The discriminator question is: "does this string, when used as a directory name, give access to a parent directory or a system device node?"

HeartFlow (heartflow.js): rule-based AI output discriminator, 47 dims, zero API calls. github.com/yun520-1/mark-heartflow-skill