>> As for OTP: yes that is a planned feature and from the passB side, it's >> quite easy to integrate for example with tadfisher/pass-otp. The only >> problem is that it's currently not really possible to detect which files >> contain OTP tokens, so all I could currently do is offer the "generate >> OTP" menu option for every entry, or decrypt every single entry when >> passB scans for pass entries. Both of those are not really solutions I >> would enjoy doing. >> So either I'm gonna add an extension for passB that maybe offers otp for >> all entries that follow a naming convention of .otp - which would be >> kind of a hack, or I'll wait for tadfisher to implement some sort of >> `pass otp ls` command that somehow caches that information - which I >> currently would prefer most. > > From my understanding there is some semi-standard way to store metadata, > as long as the password is on the first line. Subsequent lines can have the > OTP: qualifier, or something similar.
When I have an already decrypted entry, locating the OTP metadata is no real problem (I can simply look for the line starting with "otpauth://"). My point is that in the context of the addon, you have a tree of entries and every tree node has associated actions like "show password" and "fill password". Of course, I could also always offer "show OTP" for every entry, but if I would want to offer that action in a context-sensitive only on entries that really contain "otpauth://", I have to decrypt all of those before rendering the tree. (Or do a `pass grep "otpauth://" which would essentially do the same) Not only is this a lot of unnecessary decrypting, it also takes quite long. I have around 600 entries and am using a smartcard, so I have to wait like five minutes to get a result. That just takes too long to be of any use. So I'm hoping for tadfisher to add a `pass otp ls` command with some kind of metadata cache. > > Personally what I am currently doing is storing the otp string separately, and > I have to revert back to using the Pass CLI whenever I want to use it. > So for example I would have: > > acount/[email protected] > account/otp > Yes, that would be the naming approach, which would be easier to implement. But as I said, I also think it's a bit of a hack. _______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
