[Assword] Proposal for an extensible command line syntax

[Daniel Kahn Gillmor]

Hi Oliver--

On 10/24/2013 05:28 PM, Olivier Guerrier wrote:
> For sure nothing. If the plan it to keep the software as it is, then
> there is nothing to gain. This is why I did not send a patch for it.
> It is not available anyway, but the goal would be to commit such
> reorganization only a few seconds before the first feature that will
> extend it.

I quite like some of the changes you've proposed, but they don't seem
dependent on this command line syntax overhaul to me.  we do want
assword to grow and change, but there are some features that i suspect
we do *not* want (e.g. the "feature" post your decrypted db to a public
pastebin :P)

so let's talk features, and when implementing a feature seems to require
a restructuring of the command line syntax, then we can work on the
restructuring.

> The truth is there are almost as much use cases as there are users. You
> like environnement vars, I never use them, and tend to use --longarg
> only ...
> 
> Someone else might want to use configuration file ...

sure, which is why dickering over new command line syntax seems fruitless.

> The first idea is to define something homogeneous, so all coming
> features will be available from all interfaces. In a consistent way.

i'm all for consistency in UI and code -- remember that there is an
assword.py python module as well, which provides programmatic access.
how should that programmatic access implement this consistency?

> Correct. I'm using assword since 6 months on a regular basis, with
> several patches of my own that came along the way, but without the
> above'organization'. Now I plan to spend time to rework this in a better
> way that should make sense upstream.

i'm glad it's working for you!

> What you get today with 'assword gui' would be achieved tomorrow with
> either:
> $ assword --ui=gtk paste
> or
> $ ASSWORD_UI=gtk assword paste


semantically, "paste" doesn't make a lot of sense to me as a replacement
for "gui".  the current "assword gui" lets me not only (a) paste
existing passwords, but also (b) enter new passwords (and paste them)
and (c) browse my list of contexts without pasting or creating.

> Create a new random password:
> $ assword --pwlen=16 --input=random add <context>

this is currently:

 ASSWORD_PASSWORD=16 assword add <context>

> Import a list of passwords from a text file:
> $ cat pw.txt | while read AC PW; do echo $PW | assword --input=stdin add
> $AC; done

This one is not yet done, for sure, and the implementation above would
break on passwords beginning with a - (and would leak passwords to the
system's process table when executed on shells without a builtin echo).

But it could be done with a minor tweak to enable
ASSWORD_PASSWORD=stdin.  A patch to enable that would be great!

> Update manually a password:
> $ assword edit <context>
> (add and edit are very close, except add is not supposed to overwrite an
> existing context)

"edit" also implies that you will see the old passphrase while changing
it; assword strives to avoid displaying the passwords, ever.

What about a new subcommand "assword replace <context>" ?  I would
welcome a patch for that, even though it could be implemented pretty
simply already with "assword remove $context; assword add $context".

> I also plan to add a 'paste' field into each record. This field would be
> optionnal (so we keep a full backward compatibility, if not specified,
> assword use the env/config/cmdline <method>.
> 
> So for example we can tell one context is meant to be use only though
> xclip:
> $ assword --pwpaste=xclip --input=random add <context>
> $ assword --pwpaste=xclip edit <context>
> ('pwpaste' is not the same as 'paste' as we don't want to create all
> records with the value put in ASSWORD_PASTE)

This idea is awesome.  Since passwords tend to be used in a particular
application, it makes a lot of sense to have the default output method
stored with the password if the user wants it.

It would also be nice to have a graphical indicator in the gui that
would show you what mechanism is going to be used (and to have a way to
override it if you're using the password in an unusual context).

we'd need to think about how to let the user modify these stored
per-password defaults.

> Another feature I have in mind is to have some automatic grouping of
> contexts, to manage more complex cases:
> $ assword --pwpaste=xdo add mybank/myusername
> $ assword --pwpaste=popup add mybank/mypin
> 
> For example my bank use a 'virtual' keyboard I have to click to ...
> and here I can just call:
> $ assword --ui=gtk dump mybank
> and I will get both the username typed though xdo _and_ the pin
> displayed on screen ...

hm, grouping has two parts: showing "grouped" contexts, and actually
triggering all passwords associated with a "group".

for displaying the group, that can currently be done when browsing by
just ensuring that the same keyword is in both contexts, and then
entering that keyword in the search box.

triggering multiple passwords concurrently seems problematic to me.
What's wrong with setting the focus you need for one password, invoking
assword, then setting the next focus and invoking it again?  assword
only knows where to inject a single password, so asking it for more than
one kind of breaks some fundamental assumptions unless you do have this
"popup" thing, but...

> And yes I plan to add a paste method to display a popup, it is not fully
> clear what is the best way to implement it, but let's call it 'popup'
> for now.

I'm really uncomfortable with the idea that assword would ever display
the password on the screen.  i'd like to avoid that for the sake of the
inevitable shoulder-surfing casualties alone.

What do you think?

any chance you could send patches for:

 * ASSWORD_PASSWORD=stdin
 * assword replace <context>
 * per-password default ASSWORD_XPASTE mechanisms?

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <https://lists.mayfirst.org/mailman/private/assword/attachments/20131024/aa4051a2/attachment.pgp>