[pass] [PATCH] Added 'rename' command

[Tobias V. Langhoff]

On Thu, Apr 17, 2014 at 9:05 PM, Brian Shore <brian at networkredux.com> wrote:
> On Thu, Apr 17, 2014 at 11:24 AM, Matthieu Weber <mweber at free.fr> wrote:
>> On Thu 17.04.2014 at 08:34:05AM -0700, Brian Shore wrote:
>>> On Thu, Apr 17, 2014 at 6:27 AM, Matthieu Weber <mweber at free.fr> wrote:
>>> > pass mv is not about managing files, it is about changing the
>>> > meta-information of the password, namely its identifier. The fact that
>>> > it boils down to renaming a file is just a technicality. You can ditch
>>> > the "pass mv" shortcut if you want and provide only "pass rename" and
>>> > then it's not anymore about moving files, but about managing passwords.
>>> > That's exactly what pass is for. Maybe we can rename "pass mv" into
>>> > "pass rn" so that it doesn't sound like the shell's mv command?
>>>
>>> I think we could avoid some of the file manager difficulties by
>>> letting pass tell us something about its configuration.
>>
>> Is exposing the internals of a software any better than making said
>> software do more than the most fundamental operations? (this is not only
>> trolling, it is also a philosophical question).
>
> That depends.  Exposing something in a controlled and consistent way
> is useful.  This is why accessor and mutator methods for changing an
> object's internal state is preferred over direct access to member
> fields.  We let the object directly manage the internal state, we let
> pass directly manage its guts too.  But pass isn't prohibited from
> telling us where are passwords are stored.
>
> As far as exceeding the most fundamental operations, this is a
> continuum.  Useful tools often do more than the most fundamental
> operations, they often also do composite operations that are difficult
> to do right (e.g. if a series of operations must be performed in a
> specific order), operations that are very frequently used (but
> trivially composed of fundamental operations), etc.  We just need to
> find a balance between minimalism and efficient usability.
>
>>> For example, if pass will tell us the prefix, we can easily stuff that
>>> into calls to the standard file tools:
>>>
>>>   # change `pass show foo/bar/baz`  to `pass show foo/moo/goo`
>>>   /bin/mv -v  $(pass --printconfig prefix)/foo/bar/baz $(pass
>>> --printconfig prefix)/foo/moo/goo
>>
>> But as Jason pointed out, if the target directory has a different key
>> ID, then reencrypting the file is necessary. What about something like
>>
>>    pass foo/bar |pass insert -m baz/quux && pass rm foo/bar
>
> Works for me.
>
>> What about
>>
>>   pass git archive -o pass.backup.$(date +Y%m%dT%H%M%S).tar.gz master
>>
>> Again, this doesn't expose pass's internals too much, but I'm still a
>> bit wary about exposing the git repo. "pass git" is very useful for
>> hacking, but it feels dirty.
>>
>>> Thoughts?
>>
>> Well, none of this works if you don't use git. Is anyone using pass
>> without git?
>
> I'm not currently using git to back pass.  I do think using `pass git`
> to update or search the filesystem feels very dirty.  I think git
> belongs in the background; even if I were using git with pass, I
> wouldn't want to use pass to manage the git repo.  In contrast, I
> think using git(1) directly to manage the repo holding the password
> store is fine (although slightly inconvenient if you have to lookup
> the prefix or something).

Interesting, that's completely opposite of how I use pass and git. OK,
not completely; I agree that using `pass git to update and search
feels dirty, and I think git belongs in the background. For that
reason, I prefer using pass directly to manage the git repo, among
other things to make the commit history consistent. Using git(1)
directly on the password store feels inherently dirty to me -- the git
repo is an extension of the password store, not the other way around.
This has little practical bearing, only philosophical, of course, but
one time I added a password I actually didn't want stored, I did `pass
git reset --hard HEAD~1` and had to take a shower afterwards.

-- 
Tobias V. Langhoff