Encrypt filename.

[memchr]

Is your feature request related to a problem? Please describe.

Currently, chezmoi only encrypt content of files but not filenames, which may contain sensitive or exploitable data. It would be great if chezmoi cloud encrypt them.

Describe the solution you'd like

Solution # 1

Encrypt the filename of encrypted file and store it in as ASCII-only "armored" encoding.

e.g. Instead of plain text filename:

private_world_domination/encrypted_antimatter_bomb_schema.json.age

Use

private_world_domination/encrypted_YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0IFgyNTUxOSA.age

name of directory can also be encrypted. Instead of:

private_overthrow_galactic_empire/plan_of_republic.md

use

encrypted_private_YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0I/encrypted_YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0IFgyNTUxOSBP.age

Solution # 2

Use salted hash as name for encrypted file and folder. And store hash to filename table in a separated encrypted database.

e.g. For file to be encrypted: private_world_domination/antimatter_bomb_schema.json

• f8b1e5a20f9f74cfc234967a944e991562394e7acd7117d4b5ea93431bf0157a is hash of world_domaination + Yw2dlLx+1/fe (salt)
• 8c76e35b69ff41c8c12937a8fa13d225abff83e0e2ef0bc5a0bfd9afcee771b0 is hash of antimatter_bomb_schema.json + V1Z0INLxmmNx (salt)

Content of hash to filename table filenames.json:

{
  "f8b1e5a20f9f74cfc234967a944e991562394e7acd7117d4b5ea93431bf0157a": "world_domination",
  "8c76e35b69ff41c8c12937a8fa13d225abff83e0e2ef0bc5a0bfd9afcee771b0": "antimatter_bomb_schema.json"
}

Encrypt antimatter_bomb_schema.json and store it in encrypted_f8b1e5a20f9f74cfc234967a944e991562394e7acd7117d4b5ea93431bf0157a/encrypted_8c76e35b69ff41c8c12937a8fa13d225abff83e0e2ef0bc5a0bfd9afcee771b0.age

Encrypt filenames.json and store in filename.json.age

[twpayne]

Thank you for this enhancement proposal!

tl;dr I think this is possible, but I am not sure. Work in progress PR in #2572.

In this issue I'll talk about work-arounds. Let's discuss fixes in #2572.

In the short term, with the current version of chezmoi, there are a few immediate work-arounds for keeping your filenames private:

• Make your dotfiles repo private.
• Use an encrypted external (it's not documented, but .chezmoiexternal archives and files support the encrypted flag; if this is true then the external archive/file is decrypted with your configured encryption before being read, i.e. you can post encrypted archives and files anywhere and have chezmoi include them in your dotfiles).
• Use a private git submodule for the relevant directory (not recommended).

[twpayne]

For what it's worth, solution 2 is currently a no-go (and I'm sure that you know this) because it breaks the strict one-to-one mapping between files in the source directory and target files, as described in chezmoi's FAQ: https://www.chezmoi.io/user-guide/frequently-asked-questions/design/#why-does-chezmoi-use-weird-filenames

[halostatue]

This might be interesting, but I’m having a hard time seeing a real-world application of this where simply having a filename of dot_config/encrypted_nuclear_secrets.json.age would be in and of itself a security risk for a dotfiles manager. The only time that I think that this might be desirable is if the filename itself contains PII (e.g., an email address) or a part of the "secret" that would be managed, and I can’t think of any common configuration files — or even licence files — that would do that.

I think that the suggestion of using an encrypted external archive is probably the best choice, but even in the example given, that would have to include at least the world_domination folder as the write location for chezmoi.

On a practical level, this would also introduce some difficulty with editing the files if you do so within the chezmoi source directory (as I usually do, although I now split between that and chezmoi merge-all). As such, if this is implemented, I think that there should probably be an additional flag used for this, say masked:

masked_private_YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0I/masked_encrypted_YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0IFgyNTUxOSBP.age

The masking would use the same encryption as encrypted does, but would be used on an opt-in basis. It’s no more of a risk than the presence of an encrypted file-name, but doesn’t directly overload encryption with filename management.

[twpayne]

I think this is not possible due to OS limitations on file length. See the discussion in #2572.

[twpayne]

Closing as, sadly, encrypted filenames are not feasible given the combination of file name length limitations and asymmetric cryptography, solution 2 breaks the 1:1 mapping between filenames, and the work-around of encrypted archives already exists. Please re-open if needed.