I don't know if gpg stores any kind of date as part of the metadata of the encrypted content but encrypting a timestamp seems like the only resiliant approach. Any external mean is likely to fail in some situation.
The timestamp could be as simple as a date 20-05-2016. Unless having hour or even minute resolution is a requirement. The only possible issue is that given some of the content being encrypted is known, I don't know if that makes the encryption less secure. In modern cryptography it shouldn't but I'm not an expert. Renato -------- Original Message -------- From:Grégoire Détrez <[email protected]> Sent:Fri, 20 May 2016 12:10:18 +0200 To:Evgenii Sovetkin <[email protected]> Cc:password-store <[email protected]> Subject:Re: [pass] list of passwords with its age >On Fri, May 20, 2016 at 11:46:08AM +0200, Evgenii Sovetkin wrote: >> On 2016-05-20 11:33 AM, Grégoire Détrez wrote: >> > On Fri, May 20, 2016 at 10:45:46AM +0200, Evgenii Sovetkin wrote: >> > > I want to obtain a sorted list of my passwords together with its age >> > > (number of days since the last change). >> > > >> > > With git it seems the following loop will do part of the job: >> > > >> > > git ls-tree -r --name-only HEAD | while read filename >> > > do >> > > echo "$(git log -1 --format="%ad" --date=relative -- $filename) >> > > $filename" >> > > done >> > > >> > > Unfortunately, if I rename a password (or even rerun git init) then it >> > > would seem that I have changed the passwords, though I have not... >> > > >> > > Is there a neater solution one have in mind? Is there a way in git to >> > > show time passed from the *significant* content change, not simply the >> > > latest commit? >> > >> > You could use use git-blame to get the last commit that changed the >> > first line of each file, something like: >> > >> > git blame -L 1,1 $filename --porcelain | sed -n 's/^committer-time //p' >> > >> > >> > /ǵ >> >> Thanks for the suggestion! It solves the problem with the renamed >> passwords, but it doesn't really work, with the reencrypted passwords >> (I rerun git-init recently). > >I guess you mean pass-init? I far as I understood, as long as you can >still decrypt the files, git-blame should be robust to re-encrypting >password. You need to properly setup the git attributes to compute >clear-text diff (it seems that the latest versions of pass do that >automatically otherwise I described how configure it manually in an >older thread on this list). > > >/ǵ > >_______________________________________________ >Password-Store mailing list >[email protected] >http://lists.zx2c4.com/mailman/listinfo/password-store
_______________________________________________ Password-Store mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/password-store
