[PATCH] Don’t reencrypt data not managed by pass.

[Sebastian Reuße]

Kjetil Torgrim Homme <kjetil.homme at redpill-linpro.com> writes:

> Den 25. jan. 2017 09:14, Sebastian Reuße skreiv:

>> When keeping the password-store under git, it can make sense using a
>> git extension such as git-annex instead of the native git object
>> store to store the encrypted files. Inter alia, this allows one to
>> selectively expire old copies of the encrypted data, while otherwise,
>> one would need to recreate the complete repository when a key should
>> no longer have access to some of the data.
>
> if someone had access in the past, they had access to make a clear
> text copy of everything if they wanted to. if you worry about this,
> you need to change all passwords, and who cares if they still have
> access to outdated passwords through old revisions of the repository.
> I don't think makes much sense to rewrite history.

In the case I was thinking of, you are not removing access from another
person’s key, but from your own key that you’re using on a different
machine. You’re not expiring the data because you fear that the key was
compromised, but because your trust in some machine is reduced (maybe
you’re traveling more, or you give the spouse access to the machine, you
simply don’t need the data there anymore, etc).

git-annex will allow you to abstain from rewriting history, because the
encrypted data was managed by git-annex and never committed to git (only
as a symlink). You then drop the copies of the .gpg file from the
machine and you’re good.

>> Since using the git-annex object store means that *.gpg files (and
>> directories named *.gpg) are kept under .git/… (non-writable), the
>> reencryption logic used by pass currently fails. To remedy this, we now
>> ignore everything kept under .git when looking for files to reencrypt or
>> when grepping.
>
> I see no reason to look inside .git/ anyway, so by all means :)

Yeah. My other motivation for using git-annex in my pass repo was
performance when storing larger blobs, anyway.

Kind regards,

--
Sebastian Reuße