Do not report secrets in public issues. Send sensitive reports through a private channel to the maintainers.

open-backup has no encryption capability. policy.encryption is typed as the single value none, any other configured value is coerced back to none, and there is no flag, key management, or passphrase option. Every archive is a plain tgz written unencrypted and unsigned to a local, S3, or SFTP destination.

All protection at rest therefore comes from the destination, and it protects against a narrower set of threats than "encrypted" suggests:

• bucket-level SSE (SSE-S3 or SSE-KMS) and versioning protect against media theft and accidental overwrite or deletion
• they do not protect against any principal that can read the objects: anyone holding s3:GetObject on the prefix, filesystem read access to a local destination, or the SFTP account can read every archive in plaintext

Do not describe these archives as encrypted. Restrict read access at the destination, prefer SSE-KMS with a restricted key policy when key control matters (backup aws s3-audit reports bucket posture), and use inventory-only mode for sources whose contents must not be copied at all.

open-backup is conservative by default:

• prune --apply has no default home: it refuses unless a home was named, and refuses a named live home unless a confirmation carries that exact path — so a caller that fails to set HASNA_BACKUP_HOME cannot silently destroy live backups. It echoes the resolved home and object count before deleting. Read-only commands are unaffected
• restore execution is not implemented in the MVP
• secret-like paths are excluded from archive mode by default
• inventory-only mode can track that a sensitive source exists without archiving values
• AWS audits use explicit named profiles and do not store cloud credentials

Never include API keys, tokens, private keys, .env contents, .connect token stores, or .secrets values in bug reports.