Re: Is getpass(3) really obsolete?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



<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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux