encrypt alternate names

[mfiano]

I gathered from this that symlinks would be created upon yadm decrypt:

If there are any files managed by yadm’s repository, or listed in $HOME/.yadm/encrypt, which match this naming convention, symbolic links will be created for the most appropriate version.

But appending ##Linux.host1 to my ~/.ssh keys and adding them to the ~/.yadm/encrypt file does nothing upon decrypting. What exactly does the above quote mean wrt to encrypt and symlinks?

[TheLocehiliosan]

Your interpretation is correct. This is a new feature beginning with version 1.07. However, I think I see a bug where "globs" are not expanded within the $HOME/.yadm/encrypt file.

Can you confirm that you are using wildcards inside your $HOME/.yadm/encrypt file?

As a temporary work-around, I think you should be able to specify each file individually within $HOME/.yadm/encrypt and the alternates will be linked correctly.

[mfiano]

@TheLocehiliosan I had originally tried specifying them individually, and that didn't work. I then tried with globs and that too didn't work. Encrypted files are always decrypted, despite the host, and are never symlinked, renamed, etc.

Edit: Correction. This indeed does appear to be a globbing issue. Specifying files verbatim in encrypt works and symlinks are created, but see below. Originally I was doing what you are doing with .ssh/*.{key,pub}, so I'm surprised you did not notice.

In thinking about this, I just realized that I do not think symlinks are correct for encrypted files anyway - if there is an encrypted file for the host, it should decrypt it as the name it would normally be symlinked to, and leave all other files that don't belong on that class/os/host/user still encrypted. This can be illustrated with a repository consisting of multiple machines' dot files, including their SSH private keys. Raw private keys should never find their way to another machine, so they remain encrypted unless the pattern matches and the machine has the proper GPG private key/password to decrypt it to the original filename without the ##suffix.

To repeat: I do not think symlinks should be created for encrypted files, because that implies the decrypted file for all patterns are available. Instead, only decrypt the files having patterns matching this machine/user/etc - all other files remain encrypted until decrypted on the correct machine/user/etc.

[TheLocehiliosan]

Specifying the files directly does currently work. I do believe the globbing issue needs to be fixed. Actually, I've already written a fix, but that fix uncovered another bug (#53), that globs for paths which contain spaces is not properly supported either.

The reason I haven't noticed this myself is that I do not actually use symlinked alternates for my keys, and my test cases did not use any wildcard globs.

I've read your suggestions about decrypting relevant files only on matching hosts, and then renaming instead of linking. I will think about these ideas some more, but initially I don't think that's the right direction for yadm. Most of my reservations come from the problems that arise during the encryption process itself. I strongly believe I should be able to decrypt an archive, update some of the data, and then encrypt the archive again—from any machine—just as I can change the unencrypted data from any machine. I'm not sure how to achieve that goal alongside your suggestion. If not all of the data is decrypted, how does a new archive get created? Again, I'll continue to think more about it.

If you can explain your use-case a bit more, I might be able to suggest an alternate way to handle your situation. For example, I have users who have more than one encrypted archive. You can override the what file is used as an archive with --yadm-archive. These users might have one private data set for work, and another for home. And then they specify the appropriate archive file when the encrypt/decrypt. You can even put logic in a bootstrap script which will programmatically determine which archive to decrypt for a given machine. Perhaps this type of strategy would be useful for you.

[mfiano]

You raise valid concerns with my idea. My use-case is simple. It is common security practice for private keys to belong only on the host they were created for. Decrypting all files would break this. This is the only reason I wanted the ability to never decrypt files that don't belong on a host. Perhaps an optional parameter to decrypt would suffice. I'll have to think some more.

[TheLocehiliosan]

If you intend on creating keys that only exist on a single host, my suggestion is leave them out of your dotfiles repo. It probably makes sense to add the public keys to .ssh/authorized_keys. If you need finer control over which public keys are allowed for particular hosts, you can create alternate links for the authorized_keys files.

[mfiano]

Ok, thanks for the ideas.