Is encrypt list automatically ignored?

[marcopolo4k]

Are encrypt list files automatically yadm-git-ignored? If not, why not? Seems like that would prevent accidental uploading of intentionally encrypted files.

[TheLocehiliosan]

They are not automatically ignored. As far as I'm aware, Git only allows for a single core.excludesFile. I don't think there is a way to activate excludes through something like an environment variable either. There are users who already use $GIT_DIR/info/exclude or core.excludesFile for their own purposes, so hooking into that would be a bit disruptive.

I'll think about it some more. Perhaps I'll think of a suitable way.

[malikoth]

What about appending the contents of .yadm/encrypt to $GIT_DIR/info/exclude with a header like, ### This section is auto-generated, modify this through .yadm/encrypt. Having a section be automatically managed shouldn't affect whatever else someone is using the exclude file for. Then you could just wipe the file from the header to the EOF, and append the new contents again whenever there's a change to .yadm/encrypt. Maybe?

[abathur]

I got a good noob-run through using yadm to preserve config before wiping a system last night, and I had to double-check myself each time I saw one of the files I needed to encrypt in yadm status -u. I thought of a few things that might've made it a little less stressful:

More explicit reporting of the status of encrypted files

I think it'd help to have either a separate command (yadm status-encrypted) or overlay a flag on yadm status (yadm status --encrypted) that collects a modular set of smaller reports that convey as much as possible about the exact status of every file that is in the current blob or matches encrypt. This can require the decryption password; but if decryption time is too tedious for some uses, a separate encrypted file could just store metadata about the paths in the blob. (While thinking about how to generate this, I wondered if the encrypted blob could be/hold its own .git repo, though that might make older copies of sensitive information too durable.)

This information would be most useful appended/inlined for relevant git commands:

• append a small report on encrypt paths that are either out of sync with or will be updated by the current encrypted blob toyadm status, and one on paths that are safely up-to-date in the committed encryption blob and paths that still need action to yadm status -u.
• filter output from some git commands (particularly yadm status -u) to wrap encrypt paths with new colors or typographic indications of their status.

Backstops for things that are easy to miss

It's probably more frustrating to try and satisfy a git hook than to be able to see relevant status information before commit, but I think a good pre-commit hook that objects if a commit includes files matching encrypt would go a long way towards preventing hard-to-fix accidents. It might also lay a foundation for more pre-commit sanity checks that improve UX around less-serious consistency issues (like objecting if encrypt files don't match what's in the encrypted blob when the blob is committed).

[abathur]

I'm repeating this process again as I clean up to prepare to replace my laptop. A few stray thoughts...

It's fairly obvious, but I've found some grep oneliners useful for sorting this out. I've been using yadm status -u | grep -f .yadm/encrypt -v to filter the status down to uncommitted files that don't match the patterns in the encrypt file, and yadm status -u | grep -f .yadm/encrypt to see anything that does match. I guess you could also use yadm list | grep -f .yadm/encrypt as a double-check to make sure you haven't committed one. This probably depends on how you've formatted your encrypt file. I had to remove a blank line from mine, for example.

WRT to eventual code changes here, I wondered if there's an existing list (or if it would be worth maintaining one) of well-known dotfiles and flagging files that shouldn't be included, or should only be included if encrypted, etc.

This could power some nice UX improvements like:

• a safety net if the user tries to add well-known files that should be encrypted
• a command that can highlight uncommitted files that are good candidates for inclusion
• command that can search repo history for traces of a file that should be encrypted

[TheLocehiliosan]

Automatic ignoring of patterns found in .config/yadm/encrypt has been added to the develop branch. There are some other good ideas for features in this issue, so I'll leave it open for now until I move them over to their own issues.

[seankhl]

I agree that smarter handling of encrypted files would be nice. What about something like yadm add --encrypt [file] which would add the file as an encrypted one and (possibly) encrypt it into files.gpg and stage files.gpg. This way adding an encrypted file would follow the same flow as any other version-controlled file, you just yadm add --encrypt it and it would work as expected. One possible stumbling block for this would be adding only that one file to the encrypted files.gpg without adding others that have changed but not been manually added themselves, though I guess it should certainly be possible. Extending yadm status to show the state of encrypted files is a big +1 from me. Even extending yadm diff and yadm diff --staged would be cool, not showing a full diff necessarily but just that it has changed, or even showing the diff with a password prompt. I agree that it's not clear exactly what set of improvements is best, but I figured I'd throw in my two cents.

[TheLocehiliosan]

I've created a new issue, #386 from a non-addressed idea in this issue.