[Assword] [ASSWORD] keymap issue + notify + mailing list ?

[Olivier Guerrier]

On 01/06/2013 19:33, Jameson Graef Rollins wrote:
> On Tue, May 28 2013, Olivier Guerrier <olivier at guerrier.com> wrote:
>> 0001-allow-empty-password-when-ASSWORD_PASSWORD-prompt.patch

Empty password does not really make sense, This may be changed to 
display a nice message instead of the previous python exception when 
password is empty (when you press enter twice in PROMPT case) but 
storing empty password is useless.

>> 0002-add-a-new-optional-comment-field.patch

No more needed, see below.

>> 2/ notify feature.
>> I want assword to be able to display a "comment" using the desktop
>> notifications system.

Still needed, but not with the current implementation, see below.

> Can you be a bit more specific about what exactly you're wanting to be
> notified with?  Is it just the entry contexts?  The full entry contexts
> are displayed in the drop-down menu in the gui.  Is that not sufficient
> for some reason?
>>
>> No it is not sufficient. Here are 2 use real use case:
>>
>> 1 - https://mobile.free.fr/moncompte/
>> You have a password, and you have a ID that need to be entered through
>> the mouse. So here I can use assword to fill the password field, and
>> display the id (which is given on bill anyway) on the screen so I can
>> click it).
>
> So it sounds like the usage here is that you want to store a specific
> user id along with a password for a given context.  I think that's
> reasonable.  I think it makes more sense to support that directly,
> though, rather than with the more generic "comment" field.
>
> For instance, maybe we could have assword fill in user id fields, then
> hit 'TAB' to move to a password field to enter the password.  That seems
> like a fairly common use case.

The special case of username+password is already managed by the current 
implementation of assword, as you can type a tab between username and 
password, and xdo will gladly simulate it as well.

>> 2 - I store a few pincodes in assword as well (credit card for example).
>> In this case I store an empty password, and only a comment that is
>> displayed (instead of dumping the password on the command line for example)
>
> In my mind pin codes are actually just a different form of password.  I

Yes you are right, it is a different password, and therefore may need a 
different rendering method.

> would say they should just be stored in the password field of a
> different entry.  For instance, I have contexts like this:
>
> "jrollins at mybank.com"
> "jrollins at mybank.com (pin)"
>
> That seems to handle those use cases for me, without the need for
> separate fields.  Do you think something similar would work for you?

Yes, but I don't want the pin code to be typed

> In general, I would like to avoid tying into the notification system if
> we can help it.

I think you're right, my approach was not the good one, and too 
specific. Here is another approach, more versatile, and (less?) intrusive.

First I think my initial need can be express as follow: "I need to store 
several secrets, but not all secrets need to be restituted the same way."

password are to be typed (xdo) or filled in the copy paste buffer.
other secret (like pin) can be used in other ways. So here is my proposal:

- no more "comment" field in the database
- a new optional "method" field is added to new records
   - this method can be one of:
     - xdo
     - clipboard
     - cmd
   (and can be extended later if needed)

So each secret can be associated with a different method

about the command associated with the cmd case, I'm thinking about 
storing something like "cmd:///some/command -somearg '%s'"

What do you think ?

-- 
Olivier Guerrier