Re: [Otpasswd-talk] Some questions

[Hannes Beinert]

On Mon, Jan 4, 2010 at 14:29, Tomasz bla Fortuna <address@hidden> wrote:
> Dnia Mon, 4 Jan 2010 03:27:08 +0100
> Tomasz bla Fortuna <address@hidden> napisał(a):
>
>> > 8. I think that the --flag interface on otpasswd probably should
>> > accept key-value pairs.  I think that would give added flexibility,
>> > and probably clean the interface a little.  So, for example,
>> >
>> >      $ otpasswd -f codelength:4
>> >      $ otpasswd --flag=codelength:8
>> >      $ otpasswd --flag=alphabet-size:43,codelength:5
>> I like the idea of ':' really. This can even be switched to '='. But
>> your third example is hard to code without major rewrite (getopt won't
>> like it). Still I can easily get something like this:
>>       $ otpasswd -f codelength=4
>>       $ otpasswd --flag codelength=8
>>       $ otpasswd --flag alphabet=3 -f codelength=5
>>       $ otpasswd --flag alphabet=list
>> (As the alphabet is precised by ID currently not by length).
>>
>> What do you think?
>
> I'll try implementing this like this for now:
>
> Configuration:
>  -f, --flag <arg>
>           Manages various settings:
>           list          print current state and configuration.
>           show=<on|off> configure visibility of passcode during
>                         authentication.
>           alphabet=<ID|list>
>                         select passcode alphabet. Use 'list' argument
>                         to get IDs of available alphabets.
>           codelenght=<length>
>                         select passcode length.
>
>           contact=X     Set contact info (e.g. phone number) with
>                         which to receive a passcode during
>           authentication. Details depends configuration. Use "" to
>           disable. label=X       Set a caption to use on generated
>           passcards. Use "" to set default (hostname)
>
>           salt=<on|off>
>                         Meaningful only during key generation.
>                         Enable/disable salting of a passcode counter.
>                         Disabling this option will make program
>                         compatible with PPPv3.1 and will increase
>                         available passcard number at the cost of
>                         (theoretically) less security.
>
> What do you think? Any ideas of improving this approach? Is for sure
> better that previous.

You're not going to like this...  :-/

I can see what you're trying to do...  essentially, instead of
"--flag" being used to just set the FLAGs in the user state, you want
to create a single option which will change almost all fields in the
user state record.  Okay, I can see that.  But then, I don't think
that the name "--flag" applies anymore.  I would love to suggest
"--state", which would work, but "-s" is already taken.  Or, how about
"--config" and "-c"?

The --flag option just seems counter-intuitive to me that "contact" or
"label" data values.

I also think that "--flag list" is counter intuitive, since "list" is
an action rather than a flag.  "--config list" would be better, IMO,
although I would still prefer, I think, to see the "list"
functionality as a primary option, such as "-l" or "-i".  Perhaps, if
you use "--config"/"-c", then just putting "-c" on a command-line
without arguments could, by default, list the user state?  That would
seem reasonably intuitive to me.

So, what about something like this:

-c, --config [<parameter>]
       show=on/off
       alphabet=ID/list
       codelength=<len>
       contact=<info>
       salt=on/off
       list

where if "-c" is supplied without a parameter, the (list) user state is printed?

Also, another thing that I could envision might be handy, especially
for scripting, is that if the /value/ portion of the <parameter> isn't
provided, otpasswd just prints the value of that specific key.  IOW,

     -c show

would print the value of the current "show" flag.  Or,

     -c contact

would print the value of the current "contact" information.

Just my thoughts, Tomasz.  Don't throw knives.  ;-)

Hannes.