enhancement ideas

[David A.]

On Sun, 23 Apr 2017 22:39:27 -0400, shawn wilson <ag4ve.us at gmail.com>
wrote:

>A few thoughts (about the code in general and my uses):
>
>1. You have a basic check of gpg using:
>which gpg2 &>/dev/null && GPG="gpg2"
>I think it would be better to use:
>command -v gpg >/dev/null 2>&1

I may be wrong but command -v doesn't ensure that the executable
exists.  If the name is an alias it will return the alias value.
[EDIT: this seems to only happen in interactive shells]  There may or
may not be an executable by the same name that pass can use.  One of
the "type" command options would be more suitable as it can do an
actual PATH search.  In both cases I'd want to know which version of
bash enabled those commands as you may be introducing a minimum
version requirement. The which command on the other hand has been
around forever, operates consistently, and should reliably be
available.  Not to say it's better, but it works.

I've actually read a number of very long discussions on how best to
determine if an executable exists from within a script and there are a
surprising number of conflicting answers.  Since pass is written in
bash we can at least rule out some of the more arcane compatibility
implications, which means your suggestion is well worth considering.


>Other commands should be checked for as well, such as: git, clip,
>find, tree, pwgen (others?)
>
>2. It should be possible to include schemas that pwgen allows when
>adding a new password w/in pass (so that I don't have to use pwgen
>directly and then manually create the pgp file/insert it - idr exactly
>how I did it last time some site limited my password complexity)

FYI, the latest version of pass eliminates pwgen and uses /dev/urandom
internally instead.  However, I agree that pass never exposed enough
of the pwgen command line options so I've always generated my
passwords outside of pass.


>3. Allow for a config file that is sourced so that I don't have to
>define sane defaults at cli (ie, I know I'm always going to want a 20
>char pass generated - and for the next idea)
>
>4. Some sites limit password length and complexity in certain ways,
>it'd be nice if we could generate/steal a list of these limitations
>(ie, Bank of America doesn't allow special characters and has a 25
>char limit IIRC). So it'd be nice if i could say, generate me a new
>password for that site, and it's done.

This is a good idea, but I don't think it's pass' problem to solve.  I
think this could ideally be solved with an extension that would
extract the complexity rules from a password-store entry and run the
appropriate pass generate (or other) command.  Password-store has
already stated that it does not intend to assume any particular data
structure beyond the password on the first line so I wouldn't expect
this to become a built-in.


>5. Automatic password resets - where possible, it'd be nice, using
>curl (or firefox/chrome where some extra - ie picture - verification
>is required), if we could say "update this password, using this
>username for this site" and pass could handle that for me.

Yeah, sure it would be nice.  But it's not at all feasible for lack of
standards.  It's also way outside the scope of what password-store is
trying to be. (IMO, I don't speak for Jason at all)

Even a standalone program that does this using pass or any other
password manager as a back-end would be quite a difficult project.
Sure would be handy though, then I could reasonably expect to change
all my passwords on a regular basis.


>6. It'd be nice if we had a way of writing out passwords in qrcodes
>(so that I can easily read it onto my phone). Right now, I do:

Already done in the latest release.


>ps -
>        local id_print="$(printf "%s, " "$@")"
>should be:
>printf -v id_print .......

Again, what version of bash did "printf -v" become available?  I
really don't know off hand but something tells me this was a somewhat
recent addition.