Add ShareConfig Functionality for Secure Configuration Sharing to Bitwarden Self-Hosted (Bash)

[fer]

Description

Introduces the shareconfig functionality to the Bitwarden self-hosted setup script, enabling administrators to securely share their Bitwarden configuration files. The shareconfig command sanitizes sensitive information by redacting values associated with passwords and secrets before compressing the configuration files into a tar.gz archive. This ensures that critical information remains secure when configuration files need to be shared for troubleshooting or auditing purposes.

Features

• Redacts sensitive information, including passwords and secret keys, in .conf, .env, .xml, and .yml files within the Bitwarden configuration directory.
• Maintains the original directory structure in the compressed archive.
• Generates a tar.gz archive of the sanitized configuration files, ready for secure sharing with support teams or for audit purposes.

Usage examples

To use this functionality, run the following command from the Bitwarden self-hosted script directory:

./bitwarden.sh shareconfig

This will generate a file named bitwarden-configs-redacted-<timestamp>.tar.gz in the current directory.

Testing

Please review this PR for inclusion in the next release of Bitwarden self-hosted. Your feedback and suggestions are welcome!

[bitwarden-bot]

Checkmarx One – Scan Summary & Details – fbd1c9d8-9789-48bc-b018-4e7878ecf47f

No New Or Fixed Issues Found

[vgrassia]

How do we make sure that secrets added to new and existing environment files are redacted?

[fer]

How do we make sure that secrets added to new and existing environment files are redacted?

Thank you for bring this up. To ensure the dynamic redaction of secrets from .env files and others, we could enhance the shareconfig function with a more comprehensive and adaptable regex pattern matching system.

\b(?:PASSWORD|SECRET|KEY|TOKEN)\s*=\s*.+
\b(?:PASSWORD|SECRET|KEY|TOKEN)\s*:\s*.+

But still these patterns would be to catch common ways, they wouldn't cover still new situations. Open to new suggestions to investigate.

[keithhubner]

As discussed, we should put a disclaimer on the script stating the files and values we have masked and that the user to verify there are no additional config files that container secrets. This ensures they are agreeing that there might be secrets that are still shared.

[CLAassistant]

All committers have signed the CLA.

[keithhubner]

AI code review:
Key Things to Check:

Sed Pattern Completeness & Correctness – The patterns are fragile:
Password=.*;\ only matches if a semicolon follows; standalone passwords in .env files without delimiters will be missed
Pattern is case-sensitive (Password= vs password=) – different file formats use different casing
No coverage for Base64-encoded secrets, encrypted values, or API keys beyond the explicit list
The warning message itself signals incomplete redaction—this is a security liability
Error Handling & Cleanup – No defensive measures:
Missing set -e or error checks on sed, tar, cp operations
No trap to clean up $TEMP_DIR if the script fails mid-execution
Temp directory leaks if the function exits early
File Permissions – Output tar.gz created in current directory with default umask; should explicit chmod 600 to prevent accidental exposure during troubleshooting workflows

Format-Specific Parsing – Single sed approach won't reliably handle XML values (...) or YAML quoted strings; consider format-aware redaction (e.g., separate handlers per file type)