Harden ~/.flowise/encryption.key file permissions to 0o600

[JAE0Y2N]

What

Pass { mode: 0o600 } to fs.promises.writeFile when persisting ~/.flowise/encryption.key, so the master encryption key is created with owner-only-read permissions (-rw-------) instead of the umask-default 0o644 (-rw-r--r--).

Why

The encryption key wraps every credential stored in the Flowise database. On a stock Linux / macOS install (umask 022), the key file currently lands at 0o644 — readable by any other UID on the host. On multi-user systems (shared CI runners, multi-tenant servers, containers that mount the host's ~/.flowise), that's a credential-store exposure.

Node's fs.promises.writeFile does not chmod by default — passing mode is the standard way to set the on-creation permission. The same pattern is used across the Node ecosystem for secret files (e.g., npm's ~/.npmrc once it contains a token, GitHub CLI's hosts.yml, etc.).

This is a one-line defensive change with no API or behavioral impact: existing keys are not touched, only newly-created keys get the tighter mode.

How to verify

rm -f ~/.flowise/encryption.key   # so the next start regenerates
npm start                          # or however you boot Flowise
stat -f '%Sp' ~/.flowise/encryption.key   # expect: -rw-------

Before this PR: -rw-r--r--. After this PR: -rw-------.

[gemini-code-assist]

Code Review

This pull request enhances security by setting restrictive file permissions (0o600) when writing the encryption key to disk. The review feedback suggests further hardening the implementation by ensuring the parent directory exists before writing and explicitly applying permissions via chmod to handle cases where the file already exists, as the mode option in writeFile only applies to new file creation.

[gemini-code-assist]

While adding { mode: 0o600 } is a good security practice, there are two additional improvements for robustness and complete hardening:

1. Directory Creation: fs.promises.writeFile will throw an error if the parent directory (e.g., ~/.flowise) does not exist. This is likely to happen on fresh installations. Using fs.promises.mkdir with { recursive: true } ensures the directory exists before writing.
2. Existing Files: The mode option in writeFile only applies when a new file is created. If the file already exists (e.g., if it was corrupted or empty, causing the initial readFile to fail), its permissions will not be updated. Adding an explicit fs.promises.chmod call ensures the file is hardened regardless of whether it was created or overwritten.

Additionally, consider applying similar hardening to other sensitive files, such as those handled in getOrCreateStoredSecret (line 1735).

        await fs.promises.mkdir(path.dirname(defaultLocation), { recursive: true })
        await fs.promises.writeFile(defaultLocation, encryptKey, { mode: 0o600 })
        await fs.promises.chmod(defaultLocation, 0o600)

[JAE0Y2N]

Thanks for the review! Just pushed 7ffd756 addressing the chmod-after-write concern. The existing-file mode-downgrade case is real (writeFile's mode option only applies on file creation per Node.js docs), so I added an explicit fs.promises.chmod(defaultLocation, 0o600) after the write, wrapped in try/catch to no-op gracefully on non-POSIX filesystems where chmod is meaningless. The parent-directory existence concern is moot in this code path since the .flowise directory is created earlier in initialization (see utils/index.ts near mkdir(getUserHome() + '/.flowise', { recursive: true })) — but I'll add a safety mkdir if maintainers want it.