Why is the .agebox file deleted on decrypt?

[Mayeu]

Hello 👋

I am playing around with agebox to track secrets in a git repository, and I am surprised by the fact that the .agebox file is deleted on decrypt.

Used in git, this means that if I decrypt the file to feed it to my tool, I'm then going to need to git restore it each time before committing. Encrypting the file again is not really an option either since that's going to change the file even if there are no changes.

There is the cat command, but in various situations it's cumbersome to have to deal with stdout for secret import, where having them in a file is straightforward (one can redirect cat to a file, but that’s again some unneeded ceremony from my point of view).

Am I using agebox wrong in some way? 🤔

I think having an option to keep the .agebox files on decrypting would make sense, with maybe an additional command that delete any unencrypted tracked secret file as a simple and VCS agnostic way of preventing those from lying around.

[slok]

Hi @Mayeu

This was intended. That was made to force the user, so we avoid some human common errors related to encrypting files.

Why you may ask, to avoid inconsistencies as much as possible:

• People tend to change decrypted files and forget to encrypt again after the changes (if there isn't an agebox file, and you validate it will fail).
• If there is an encrypted file and a decrypted file, what should the app do?
  • Decrypt and Override the non-encrypted file: you may lose changed stuff.
  • Not decrypt: You may be working over a non up to date file.

Why encrypting again is not an option? it's because git repo space? if is about the diffs, if you make diffs on decrypted files you will not see any change

[Mayeu]

Thank you for your answer 🙂

People tend to change decrypted files and forget to encrypt again after the changes

Agree here, but I'm not fully convinced that the current behaviour will help with that. It introduced the risk of removing the file from the repo by mistake (no data loss, of course, since the file is tracked).

Moreover, I feel like the current behaviour don't really match the "No side effects like VCS commands" features, since it actually change what the VCS is tracking (but maybe I'm nitpicking a bit here 😅 ).

(if there isn't an agebox file, and you validate it will fail).

But wouldn't that be a good situation? If validate fails then the user has to make a decision, checking the data and either just deleting the file or encrypting it again because secrets have been changed.

If there is an encrypted file and a decrypted file, what should the app do?

Ask the human what to do I guess. Git secret does that, if one decrypt a file which is already decrypted it asks if it should be overwritten (it could even check the data and only ask that when there is a difference).

Why encrypting again is not an option? it's because git repo space? if is about the diffs, if you make diffs on decrypted files you will not see any change

It's mainly about the noise in the commit history. If I see that the encrypted file as changed in a commit, I expect the underlying data to have changed (or that a new user has been added), but not only the container of the data.

Taking the example of git-secret again, it has some nice encryption options, where it first check if the file has changed and only update the encrypted data if it did, and delete the unencrypted data afterward (git-secret hide -md).

[slok]

Agree here, but I'm not fully convinced that the current behavior will help with that. It introduced the risk of removing the file from the repo by mistake (no data loss, of course, since the file is tracked).

You answered yourself :D

Moreover, I feel like the current behavior doesn't really match the "No side effects like VCS commands" features, since it actually changes what the VCS is tracking (but maybe I'm nitpicking a bit here sweat_smile ).

Agebox doesn't execute any VCS commands (unlike tools like blackbox that commits things).

But wouldn't that be a good situation? If validation fails then the user has to make a decision, checking the data and either just deleting the file or encrypting it again because secrets have been changed.

Correct, that's why it removes the file.

Ask the human what to do I guess. Git secret does that, if one decrypts a file that is already decrypted it asks if it should be overwritten (it could even check the data and only ask that when there is a difference).

That's why is done like that, avoid asking humans things that can be avoided by designing user path interactions (like this one we are discussing), it's about UX.

Anyhow, for now, users didn't complain about this behavior (this project was born 1 year ago). If more users think that this is a problem, we can iterate over this for sure.

In the meantime, if this "noise in the commit history" big tradeoff doesn't work for you, maybe Agebox isn't the right tool for you and its something more like git-secret :)

[Mayeu]

Hey,

Thank you for the additional details. I guess we could continue to argue about this but we are coming from two different places, wanting to optimise for two different things :)

One small thing:

"No side effects like VCS commands"

I guess the "like" in this sentence may have been what confused me. I understood this as: "VCS commands are just one of the side-effect agebox avoids” thus my surprised when I saw that there was the side effect of changing the tracked data. Maybe “No VCS commands are run” would match the behaviour better?

I'll close this as I got my answer from my initial question, and as you say agebox does not match the workflow I want to achieve currently :)

Thank you very much for your time 🙏