[tech-security added to the list to get some attention from there]

On Sat, Jun 23, 2007 at 03:25:38PM +0000, Christos Zoulas wrote:
> In article <20070623080627.GA18016@arresum.veego.de>,
> Bernd Ernesti  <tech-userlevel@netbsd.org> wrote:
> >On Sat, Jun 23, 2007 at 08:45:07AM +0100, David Laight wrote:
> >> On Sat, Jun 23, 2007 at 09:05:11AM +0200, Alan Barrett wrote:
> >> > On Fri, 22 Jun 2007, Brian Ginsbach wrote:
> >> > > The long options are set so that both "color" and "colour" would
> >> > > be supported and both return the same value when parsed.  There
> >> > > are no other long options that start with "col".
> >> > > 
> >> > > A command is passed the option --col.  The current version of NetBSD
> >> > > getopt_long(3) treats this as an ambiguous argument.  This was the
> >> > > behavior of GNU getopt_long(3) for GNU C library 2.1.3.  Later
> >> > > versions of the GNU C library doesn't treat this as ambiguous.
> >> > 
> >> > Thank you.  So the fix is something like "if it looks like an ambiguous
> >> > abbreviation of two or more long options, but all the possible
> >> > interpretations would return the same value, then just return that value
> >> > without complaining that it's ambiguous."  This seems sensible.
> >> 
> >> Actually it is a stupid idea!
> >> Or rather allowing partial matches is what is stupid.
> >> It is all very well when the commands are typed at the keryboard,
> >> but the shortened forms will end up in shell scripts.
> >> Then, another option will get added that has the same initial part
> >> and the scripts suddenly starts failing after the program gets updated.
> >
> >What happens when I accidentally mistype a char and so this 'feature'
> >use a different function, which does the opposite of what I wanted, because
> >the different char now case a match for the other function instead of
> >failing?
> >
> >Or am I missing something here what you plan to change?
> >
> >In short: I don't like this intelligent way to decide which option
> >should be used,
> >it should always fail if the option is ambiguous.
> >
> 
> As with most things in life there are pros and cons making this change.
> In this case, I feel that we should make the proposed change (accept
> ambiguous arguments) because this is what the gnu getopt_long() does
> and most 3rd party programs expect the gnu behavior.

This is like how some shells suddenly change your command to another
if it can't find the program or alias. One may argue about this behavior,
but it is a rare one and not the default for our shells.

Which programs do really need this broken behavior and is it really a
good idea from a security point of view?

I can live with returning an error and displaying the ambiguous options
then, but not silently changing them.

> Let's face it, we wrote getopt_long() in the first place not only
> because we needed the additional functionality, but also because
> we wanted 3rd party programs to link without needing extra files.

They do link, but supporting a broken behavior is another thing.

Right now I don't know which part we want to change and I would
like to get this discussed (may it be here or even further up to
core) before changing the code.

Bernd