On October 29, 2021 9:56 AM, Theo de Raadt wrote: > Subject: Re: Is getpass(3) really obsolete? > <rsbecker@xxxxxxxxxxxxx> 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.
