[pass] [PATCH] show age of password

[Emil Lundberg]

> Actually git is keeping track of renamed files.

Git doesn't actually "keep track", but there are heuristics for figuring it
out after the fact. I don't expect git to ever keep metadata about renames
since Linus is firmly opposed the idea [1], but the existing heuristics are
enough to handle most common cases.

> does Git keeps track of modification
Yes.

> / access timestamps?
No.

> because I’m also interested in the point in time where I used (decrypted)
the password the last time.

Assuming gpg does save a timestamp in encrypted messages (and if not, I
guess you could also sign the file or something), one way to keep track of
this without introducing additional metadata (just repurposing some that's
already there) would be to just re-encrypt the password whenever you
decrypt it.

I subjectively think the feature might be a bit unwieldy to maintain, and
agree that additional metadata would be doomed to eventually go out of sync.

[1]: https://www.mail-archive.com/git@vger.kernel.org/msg03711.html

/Emil Lundberg

On Fri, 31 Jul 2015 00:09 Aleksei <lexa at cfotr.com> wrote:

> Hi.
>
> > Hi :-)
> >
> >>> You would also consider things such as renames.
> >
> > If I remember correctly, Git does not keep track of renamed files across
> revisions (yet?)
> >
> > There’s just a simple heuristic to detect renames which is based on the
> similarity of the files.
> > But maybe I’m wrong here. Are here some Git experts around?
> >
>
> Actually git is keeping track of renamed files. Look in man git log:
>
>        --follow
>            Continue listing the history of a file beyond renames (works
> only for a single file).
>
> Also you may play with -M or -C options for 'git blame' to detect renamed
> files.
>
> > I would simply rely on Git’s existing functionality (git blame).
> > This would allow us to keep the required code for password-store as
> small as possible.
> >
> > And as I said, I assume that 'git blame' does not support renamed files
> yet.
> > But this might come as a new Git feature in the future.
> >
> > By building this feature around ‚git blame‘ we could profit from this
> later on..
> >
>
>
>
> >>> I think that this isn’t a great feature because it is easy to
> misunderstand it. If you actually
> >>> want the time the password itself was created you would need more
> >>> metadata, for example `pass generate` could add a "Generated At"
> >>> property.
> >
> > As already pointed out: an additional tag must be kept in sync. We have
> a nice version control system which does exactly this for us :-)
> > Adding more stuff like tags, just adds complexity.
> > I like it the KISS style..
> >
> >>> But I think that assuming that the last time a file was
> >>> updated is equal to the last time a password was changed is a poor
> idea.
> >
> > It’s not the modification date of the file. We are talking about the
> modification date of the first line.
> >
> > To add some related thoughts:
> >
> > - is there a timestamp in the GPG metadata of the encrypted file?
> >
> > - does Git keeps track of modification / access timestamps? (I don’t
> think so)
> >
> > - because I’m also interested in the point in time where I used
> (decrypted) the password the last time.
> >
> > Cheers,
> >
> > Steffen
> >
> > —
> >
> > Steffen Vogel
> > Robensstraße 69
> > 52070 Aachen
> >
> > Mail: post at steffenvogel.de
> > Mobil: +49 1575 7180927
> > Web: http://www.steffenvogel.de
> > Jabber: steffen.vogel at jabber.rwth-aachen.de
> >
> > _______________________________________________
> > Password-Store mailing list
> > Password-Store at lists.zx2c4.com
> > http://lists.zx2c4.com/mailman/listinfo/password-store
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20150731/9802e8ed/attachment.html>