Announcing a new Browser addon: passB

[Lenz Weber]

>> 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/name at email.com
> 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.