RE: Is getpass(3) really obsolete?

[<rsbecker@nexbridge.com>]

On October 29, 2021 9:56 AM, Theo de Raadt wrote:
> Subject: Re: Is getpass(3) really obsolete?
> <rsbecker@nexbridge.com> wrote:
> 
> > On October 29, 2021 7:29 AM, Alejandro Colomar wrote:
> > > On 10/29/21 13:15, Alejandro Colomar wrote:
> > > > Hi,
> > > >
> > > > As the manual pages says, SUSv2 marked it as LEGACY, and POSIX
> > > > doesn't have it at all.  The manual page goes further and says
> > > > "This function is obsolete. Do not use it." in its first lines.
> > > >
> > > > But, glibc doesn't seem to have deprecated this function at all.
> > > > And it seems to be the most portable way to get a password, even
> > > > if it's not in POSIX.
> > > >
> > > > BSDs have readpassphrase(3), but glibc doesn't, so unless you
> > > > recommend
> > >
> > > OpenBSD also marks getpass(3) as obsolete and recommends
> > > readpassphrase(3):
> > > <https://man.openbsd.org/getpass>
> > >
> > > > using readpassphrase(3) from libbsd, or plan to add it to glibc, I
> > > > think
> > > > getpass(3) should be the recommended function in Linux, and
> > > > therefore we should remove the hard words against it.
> > > >
> > > > As a real example, git(1) uses getpass(3).
> > > > <https://github.com/git/git/blob/master/compat/terminal.c>
> > > >
> > > > What are your thoughts?
> >
> > getpass() is obsolete in POSIX.2. However, some platforms still are on
POSIX.1,
> so replacing it instead of providing a configure detection/switch for it
might
> cause issues.
> 
> 
> The community finally had the balls to get rid of gets(3).
> 
> getpass(3) shares the same flaw, that the buffer size isn't passed.
> This has been an issue in the past, and incorrectly led to
readpassphrase(3)
> 
> readpassphrase(3) has a few too many features/extensions for my taste, but
at
> least it is harder to abuse.

readpassphrase is not generally supported. This will break builds on many
platforms.