editing encrypted text files

[jonas-frey]

I don't know where to ask this question ...

I want to have a shell command in linux that asks for a password and then opens an encrypted textfile in micro. Ctrl+S should save the file with the same password, without asking again. Can something like this be done?

Currently I'm using emacs and a gpg file (for which emacs has built-in support), but I'm trying to get away from emacs, and also emacs asks for the password (twice) on each save, which I don't want.

[zyedidia]

I wrote a tool called crypt that might be useful for this. It lets you encrypt a file with crypt lock file.txt. This will create a file called file.txt.crypt (and then you can remove file.txt if you want). Then you can operate on the encrypted file, for example with micro, by running crypt op file.txt.crypt micro file.txt. This will temporarily decrypt the file (when you provide the password) and once micro has closed it will be re-encrypted and saved. You will only need to enter the password once.

[jonas-frey]

I only plan to use it on a personal computer, but I do not always carefully vet the software I install (going as far as downloading binaries from random github repositories). So I guess theoretically somebody could get access through a backdoor. That being said, it's probably not less safe than the chrome password manager?

[zyedidia]

I just pushed a commit to crypt that adds a -pipe option to the op command. So you can run crypt file.txt.crypt op micro and it will pipe the contents of the decrypted file.txt.crypt into micro and write the output back to the encrypted file (since micro supports pipe chains -- it will read from stdin and write the buffer to stdout). This only works for single-file crypts but is convenient and more secure than the /tmp file system because the decrypted data is only ever in the memory of crypt and the op process (micro in this example). I'll probably clean it up a bit tomorrow (add info to the readme and make a release).

[jonas-frey]

Hi again! Sorry for the very late reaction.

Using crypt op -pipe file.crypt micro (version 1.2) I observe a strange, unexpected behavior: i get a password prompt as expected, and the file opens in micro as expected. So far so good. However, when I tried to save a change, micro asked for a filename, which is not what I want. I want micro to save back into the same file. So I aborted and closed the file, but when I opened it again, it turned out that it had saved the change! In fact, all changes seem to get saved, even w/o any ctrl+s, and when exiting the usual save? (y/n) doesn't appear, even if the file has been modified.

Is that the intended behavior?

[dmaluka]

Let me answer for @zyedidia. Yes, I believe it is the intended behavior. The crypt process reads the encrypted file, decrypts its contents and pipes the decrypted contents into the micro process. micro receives this decrypted contents on its stdin, it has no idea what is the original file, so it doesn't know which file to save it to. Actually, micro is not supposed to need to know that, instead it is supposed to write the edited file contents to its stdout when it exits. The crypt process reads micro's stdout, encrypts it and writes the encrypted contents back to the original file.

In short, this means that you don't need to save the changes explicitly, you just edit the file and it will be saved automatically when you exit micro. This also means that this solution is not what you need if you want to be able to choose whether to save the changes or not.

[dmaluka]

A potential solution could be to add a possibility to exit micro with a non-zero exit code (this feature was already requested in the past in #1647), so that crypt can distinguish whether it should save the data to the original file or not.