Re: Is getpass(3) really obsolete?

[Joseph Myers]

On Sat, 30 Oct 2021, Alejandro Colomar (man-pages) via Libc-alpha wrote:

> > See the discussion of deprecation starting with
> >  (C2X
> > has also deprecated those functions).  The comments in that thread
> > supported marking the functions deprecated, but it needs someone to send a
> > patch and I don't know what breakage might result in applications using
> > those functions.
> 
> Thanks.  The latest draft for C2x that I know of is N2596.  Is there any newer
> draft that I can consult for these things?  I see many proposals, but it's

The latest public draft is N2731, but there are still various accepted 
proposals not included in there, including N2566 (wording version 2) which 
I believe was accepted in October 2020 (I think issue 68 in the (private) 
C standard GitLab, for integrating that paper, has been incorrectly closed 
without integrating it).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Is getpass(3) really obsolete?

[Alejandro Colomar (man-pages)]

Hi Joseph,

On 10/29/21 18:31, Joseph Myers wrote:

On Fri, 29 Oct 2021, Alejandro Colomar (man-pages) via Libc-alpha wrote:


The broader context is that I was trying to make the deprecation notices more
consistent in the Linux manpages, by using the [[deprecated]] attribute where
appropriate.  While doing that, I found a few cases where the
deprecation/obsoletion is not so clear to me, such as this one
([as]ctime[_r](3) is another one, since it is deprecated by POSIX, but not by
the C standard, but I'll start a different thread with that; and isascii(3) is


See the discussion of deprecation starting with
 (C2X
has also deprecated those functions).  The comments in that thread
supported marking the functions deprecated, but it needs someone to send a
patch and I don't know what breakage might result in applications using
those functions.



Thanks.  The latest draft for C2x that I know of is N2596.  Is there any 
newer draft that I can consult for these things?  I see many proposals, 
but it's difficult to know which have been accepted and which not 
without an actual recent draft of the standard.


Cheers,

Alex


--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: Is getpass(3) really obsolete?

[Joseph Myers]

On Fri, 29 Oct 2021, Alejandro Colomar (man-pages) via Libc-alpha wrote:

> The broader context is that I was trying to make the deprecation notices more
> consistent in the Linux manpages, by using the [[deprecated]] attribute where
> appropriate.  While doing that, I found a few cases where the
> deprecation/obsoletion is not so clear to me, such as this one
> ([as]ctime[_r](3) is another one, since it is deprecated by POSIX, but not by
> the C standard, but I'll start a different thread with that; and isascii(3) is

See the discussion of deprecation starting with 
 (C2X 
has also deprecated those functions).  The comments in that thread 
supported marking the functions deprecated, but it needs someone to send a 
patch and I don't know what breakage might result in applications using 
those functions.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Is getpass(3) really obsolete?

[rsbecker]

On October 29, 2021 10:45 AM, Alejandro Colomar wrote:
> On 10/29/21 16:33, rsbec...@nexbridge.com wrote:
> > October 29, 2031 10:21 AM, Theo de Raadt will write:
> >>  wrote:
> >>
> > 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)
> 
> That seems a good reason to keep the "Do not use it." note in the manual page.
> I think I'll add a recommendation for readpassphrase(3bsd) for the moment
> which is the only alternative available in Linux.
> 
> 
>  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.
> I found readpassphrase(3) in FreeBSD and OpenBSD.
> It is also present in libbsd(7), which is available in most Linux 
> distributions.
> I also found it on a Mac that I have access.
> 
> NetBSD has getpass_r(3) instead.  It is not in any other system I have access.
> 
> 
> >>
> >> Of course moving forward takes a long time.  If a better API is supplied 
> >> then
> >> there is a choice in 10 years.  If a better API is not supplied, then 10 
> >> years
> from
> >> now this conversation can get a reply.
> >
> > I checked the API 10 years from now (check the above date) at it's still not
> there  In the meantime, compatibility is important. I checked the latest
> release (last week's) on my platform and readpassphrase() is not available. 
> Let's
> please put a compatibility layer in.
> >
> libbsd(7) is probably the compatibility layer that you're looking for.
> What system are you on?
> 
> 

I am on two variants (x86 and ia64) of HPE NonStop with current operating 
systems - and I do the build/test for git and OpenSSL. getpass() an alias to 
getpass2() but the other procs are not present. If this is going into git, I 
would suggest putting something into compat.c to abstract out the call. If it's 
there, we can handle it on a platform-by-platform basis.

Thanks,
Randall

Re: Is getpass(3) really obsolete?

[Zack Weinberg]

On Fri, Oct 29, 2021, at 9:55 AM, Theo de Raadt wrote:
>  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.
...
> 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

I was about to post exactly the same thing.  getpass(3) is not deprecated 
because there's a better replacement, it's deprecated because it's _unsafe_.  
The glibc implementation wraps getline(3) and therefore  doesn't truncate the 
passphrase or overflow a fixed-size buffer, no matter how long the input is, 
but portable code cannot rely on that.  And come to think of it, using 
getline(3) means that prefixes of the passphrase may be left lying around in 
malloc's free lists.

(getpass also cannot be made thread safe, due to recycling of a static buffer, 
but a program in which multiple threads are racing to prompt the user for 
passwords would be a UX disaster anyway, so I don't think that's a critical 
flaw the way it is for e.g. strtok(3).)

The Linux manpage project's documentation is, as I understand it, for Linux 
with glibc _first_, but not _only_; it should not describe this function as 
not-deprecated just because glibc has patched its worst problems and doesn't 
offer any better API.

> readpassphrase(3) has a few too many features/extensions for my taste, but
> at least it is harder to abuse.

I am inclined to agree that readpassphrase has too many knobs, and I can't 
think of any legitimate present-day use for several of them, which is not a 
good property for an API handling security-critical data.  Also, it relies on 
the caller to size the buffer for the passphrase, and therefore risks 
truncating people's passphrases.

With my libxcrypt hat on I've thought a bit about replacements for getpass.  
The conclusion I came to is that the easy changes are all putting lipstick on a 
pig, and if I was going to work on this at all I was going to design a 
privilege-separated authentication service that could be asked to take over a 
tty, read a passphrase, check it, and return just success or failure to the 
caller.  Neither the passphrase itself, nor any strings derived from it, would 
ever be in the caller's address space.  But this is obviously well out of scope 
for the C library.

zw

Re: Is getpass(3) really obsolete?

[Alejandro Colomar (man-pages)]

Hi Randall, Theo,

On 10/29/21 16:33, rsbec...@nexbridge.com wrote:

October 29, 2031 10:21 AM, Theo de Raadt will write:

 wrote:


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)


That seems a good reason to keep the "Do not use it." note in the manual 
page.  I think I'll add a recommendation for readpassphrase(3bsd) for 
the moment which is the only alternative available in Linux.




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.

I found readpassphrase(3) in FreeBSD and OpenBSD.
It is also present in libbsd(7), which is available in most Linux 
distributions.

I also found it on a Mac that I have access.

NetBSD has getpass_r(3) instead.  It is not in any other system I have 
access.





Of course moving forward takes a long time.  If a better API is supplied then
there is a choice in 10 years.  If a better API is not supplied, then 10 years 
from
now this conversation can get a reply.


I checked the API 10 years from now (check the above date) at it's still not 
there  In the meantime, compatibility is important. I checked the latest 
release (last week's) on my platform and readpassphrase() is not available. 
Let's please put a compatibility layer in.

libbsd(7) is probably the compatibility layer that you're looking for. 
What system are you on?




Cheers,

Alex


--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: Is getpass(3) really obsolete?

[rsbecker]

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

Re: Is getpass(3) really obsolete?

[Theo de Raadt]

 wrote:

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

Of course moving forward takes a long time.  If a better API is supplied
then there is a choice in 10 years.  If a better API is not supplied,
then 10 years from now this conversation can get a reply.

Re: Is getpass(3) really obsolete?

[Eugene Syromyatnikov]

On Fri, Oct 29, 2021 at 2:40 PM  wrote:
> 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.

POSIX.2 is not a newer POSIX version, but rather a book (“Shell and
utilities”) in pre-2001 standard revisions, and it has nothing to do
with the system interfaces (that is POSIX.1).
And the only mention of getpass() in POSIX (at least, since the 2001's
edition) indeed seems to be [1], in the list of functions that have
not been carried forward from XSH5, the 1997 revision of “System
Interfaces and Headers” (that is, SUSv2)[2], where it is inherited
from SUSv1[4] from XPG[5] and, as Alejandro already mentioned, marked
as obsolete, per XPG3 to XPG4 migration guide[6]; the previous, 1988,
version of POSIX[3] does not mention getpass() at all.

[1] https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap01.html
[2] https://pubs.opengroup.org/onlinepubs/7908799/xsh/getpass.html
[3] https://mirror.math.princeton.edu/pub/oldlinux/download/c953.pdf
[4] https://pubs.opengroup.org/onlinepubs/9695969499/toc.pdf
[5] 
https://bitsavers.computerhistory.org/pdf/xOpen/X_Open_Portability_Guide_1985/xpg_2_xopen_system_v_specification_2.pdf
[6] http://archive.opengroup.org/publications/archive/CDROM/g501.pdf

-- 
Eugene Syromyatnikov
mailto:evg...@gmail.com
xmpp:esyr@jabber.{ru|org}

Re: Is getpass(3) really obsolete?

[Theo de Raadt]

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

Re: Is getpass(3) really obsolete?

[rsbecker]

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

-Randall

Re: Is getpass(3) really obsolete?

[Alejandro Colomar (man-pages)]

Hi Ævar,

On 10/29/21 13:40, Ævar Arnfjörð Bjarmason wrote:


On Fri, Oct 29 2021, Alejandro Colomar (man-pages) wrote:


[Add a few CCs, since I mentioned them.]


[I'm not sure what the full context of this thread is, but just replying
from the POV of git@ being CC'd on this]


The first message on this thread was mine from '10/29/21 13:15', so 
you've read it all.


The broader context is that I was trying to make the deprecation notices 
more consistent in the Linux manpages, by using the [[deprecated]] 
attribute where appropriate.  While doing that, I found a few cases 
where the deprecation/obsoletion is not so clear to me, such as this one 
([as]ctime[_r](3) is another one, since it is deprecated by POSIX, but 
not by the C standard, but I'll start a different thread with that; and 
isascii(3) is another one, since the user of it should know if the 
character set he's using is compatible with ascii, and in that case it's 
perfectly valid, it's only a case of garbage in garbage out, IMO).





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

[...]

Cheers,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: Is getpass(3) really obsolete?

[Alejandro Colomar (man-pages)]

[Add a few CCs, since I mentioned them.]

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):


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


What are your thoughts?

Thanks,

Alex




--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/