Encryption not enabled warning when all the encrypted files are ignored.

[foobl42]

So, I make use of several encrypted files. But at different "stages" when initializing chezmoi, encryption may or may not be fully enabled at that point in time. So when it isn't yet enabled, I dynamically ignore (through .chezmoiignore) those encrypted files. However, even though I can see that those files are indeed ignored (I use "execute-template" on .chezmoiignore to verify), when I do a "chezmoi status", I get a warning that there is no encryption. I think it only complains on the first encrypted file it encounters, because it only lists one file in the warning message. Again, at this point in time, when it warns, that same file is also being ignored. So if it's ignored, then why the warning? Is there a way to suppress the warning?

Sorry, I've got a fairly "wacky" solution that inits and applies, building up the configs incrementally, until everything is complete. If you want to look at where I'm at, take a look at my dotfiles repo.

Anyway, any clarity would be appreciated.

[twpayne]

Can you share an example that reproduces the problem?

You should only get the "no encryption" warning when chezmoi tries to decrypt something (either an encrypted_ file or a call to the decrypt template function) and there is no encryption configured.

[foobl42]

I think that as you have clarified, I might look deeper into this. I did notice that when I do a "chezmoi ignored" at this stage, I don't see the file listed that should be listed. This file ".ssh/allowed_signers" is one of the files that is encrypted. So, maybe at this stage, the file isn't actually ignored, hence the complaint by chemzoi that encryption isn't enabled. So, my concern is that when I run the following "chezmoi execute-template -f .chezmoiignore" it actually does list the ".ssh/allowed_signers" file. But I get different results when running "chezmoi ignored". So I'm not sure why the difference.

[foobl42]

I figured it out. The logic found in my .chezmoiignore file was based on an included template that returned what I thought was a boolean (true or false). However, rather than returning an actual boolean (as verified by sprig's "kindOf" function), it was returning a string with the value of "true". So, my logic was based on obtaining a boolean from the template, but was getting a string. So, thus the logic to ignore encrypted files based on whether or not encryption is enabled was flawed, and the encrypted file was not ignored. Now, instead of checking for true (as a boolean), I'm checking whether the return is not empty (where empty means false).

I started another discussion item to ask about how to pass an actual boolean from a template, if that's possible. For this thread, I'm good to go. If you want to see my .chezmoiignore file, feel free to look at my dotfiles repo.

Thanks much.

[Lockszmith-GH]

If I understand correctly, you want to be able to skip encrypted content while you are initializing and later on have chezmoi deal with encryption after you have your encryption scaffolding ready.

If that is the case, you basically need a 2-step initialization solution.

The way I see it, there are two options:

1. use .gitignore .chezmoiignore with a condition based on whether a certain file or ENV var is available. You will initialize first without encrypted_... content, unlock your vault (1Password), and then run apply one more time, this time encryption is initialized and encrypted content is no longer ignored.
2. I have been successful with a multi tiered initialization process, I have my main/minimal initialization happen first, during this initialization I write a .chezmoiroot pointing to my full setup, and have the initialization scripts reinitialize chezmoi (on Windows I prompt a reminder that I need to run chezmoi init again, as I couldn't find an equivalent to exec) - I describe this in a bit more details in Bootstrap configuration - a temporary configuration for controlled pre-initialization #4415

[foobl42]

Did you mean .chezmoiignore?

Thanks for the link I'll take a look.

[Lockszmith-GH]

correct - sorry about that.