{"thread":{"id":"56805","subject":"Re: Is getpass(3) really obsolete?","startedAt":"2021-10-29T11:29:01Z","lastAt":"2022-09-27T20:32:12Z","messageCount":20,"participants":["Alejandro Colomar (man-pages)","Ævar Arnfjörð Bjarmason","rsbecker@nexbridge.com","Eugene Syromyatnikov","Theo de Raadt","Zack Weinberg","Alejandro Colomar","Joseph Myers","Jeff King","Alex Colomar","Sam James"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"439995","messageId":"73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com","threadId":"56805","inReplyTo":"a0371f24-d8d3-07d9-83a3-00a4bf22c0f5@gmail.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Alejandro Colomar (man-pages)","fromEmail":"alx.manpages@gmail.com","sentAt":"2021-10-29T11:28:56Z","receivedAt":"2021-10-29T11:29:01Z","isPatch":false,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"[Add a few CCs, since I mentioned them.]\n\nOn 10/29/21 13:15, Alejandro Colomar wrote:\n> Hi,\n> \n> As the manual pages says, SUSv2 marked it as LEGACY, and POSIX doesn't \n> have it at all.  The manual page goes further and says \"This function is \n> obsolete. Do not use it.\" in its first lines.\n> \n> But, glibc doesn't seem to have deprecated this function at all.  And it \n> seems to be the most portable way to get a password, even if it's not in \n> POSIX.\n> \n> BSDs have readpassphrase(3), but glibc doesn't, so unless you recommend \n\nOpenBSD also marks getpass(3) as obsolete and recommends readpassphrase(3):\n\n\n> using readpassphrase(3) from libbsd, or plan to add it to glibc, I think \n> getpass(3) should be the recommended function in Linux, and therefore we \n> should remove the hard words against it.\n> \n> As a real example, git(1) uses getpass(3).\n> \n> \n> What are your thoughts?\n> \n> Thanks,\n> \n> Alex\n> \n> \n\n-- \nAlejandro Colomar\nLinux man-pages comaintainer; https://www.kernel.org/doc/man-pages/\nhttp://www.alejandro-colomar.es/\n"},{"id":"439997","messageId":"211029.86r1c43uwj.gmgdl@evledraar.gmail.com","threadId":"56805","inReplyTo":"73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-10-29T11:40:36Z","receivedAt":"2021-10-29T11:58:10Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Oct 29 2021, Alejandro Colomar (man-pages) wrote:\n\n> [Add a few CCs, since I mentioned them.]\n\n[I'm not sure what the full context of this thread is, but just replying\nfrom the POV of git@ being CC'd on this]\n\n> On 10/29/21 13:15, Alejandro Colomar wrote:\n>> Hi,\n>> As the manual pages says, SUSv2 marked it as LEGACY, and POSIX\n>> doesn't have it at all.  The manual page goes further and says \"This\n>> function is obsolete. Do not use it.\" in its first lines.\n>> But, glibc doesn't seem to have deprecated this function at all. \n>> And it seems to be the most portable way to get a password, even if\n>> it's not in POSIX.\n>> BSDs have readpassphrase(3), but glibc doesn't, so unless you\n>> recommend \n>\n> OpenBSD also marks getpass(3) as obsolete and recommends readpassphrase(3):\n> \n\nSimply not being familiar with that case: Is that suggestive of\ngetpass(3) being bad to use in general, or a case where OpenBSD's\ndeprecation of it makes sense holistically on that OS, but not\nnecessarily elsewhere?\n\nJust skimming the linked man pages it looks like OpenBSD might have\ndeprecated it at least partly due to getpass() accepting a password on\nstdin.\n\nEven within OpenBSD I wonder what that case means for software such as\ngit. I.e. is it better to be portable and accept the same behavior on\nOpenBSD as elsewhere, or conform more closely to platform-specific\nconventions.\n\nI haven't looked closely out our getpass() integration, maybe that's a\nmoot point either way.\n\n>> using readpassphrase(3) from libbsd, or plan to add it to glibc, I\n>> think getpass(3) should be the recommended function in Linux, and\n>> therefore we should remove the hard words against it.\n>> As a real example, git(1) uses getpass(3).\n>> \n>> What are your thoughts?\n>> Thanks,\n>> Alex\n>> \n\nJust while we've got some OpenBSD people CC'd (added the devel/git\nmaintainers). I occasionally test git on OpenBSD myself (on the GCC\nfarm), and we've got a few broken tests on the platform.\n\nLooking at the ports source there's at least a couple of OpenBSD\nportability patches in there that would make sense to\nupstream.\n\nSo if that's easy for you or you're willing to submit them upstream we'd\nbe happy to take them. Usually the only reason we haven't fixed things\nlike that already is because nobody told us, and we're not actively\nlooking into the local patches local packagers apply.\n"},{"id":"439998","messageId":"00d501d7ccbe$0169c340$043d49c0$@nexbridge.com","threadId":"56805","inReplyTo":"73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com","subject":"RE: Is getpass(3) really obsolete?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-10-29T12:10:41Z","receivedAt":"2021-10-29T12:11:07Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 29, 2021 7:29 AM, Alejandro Colomar wrote:\n> On 10/29/21 13:15, Alejandro Colomar wrote:\n> > Hi,\n> >\n> > As the manual pages says, SUSv2 marked it as LEGACY, and POSIX doesn't\n> > have it at all. The manual page goes further and says \"This function\n> > is obsolete. Do not use it.\" in its first lines.\n> >\n> > But, glibc doesn't seem to have deprecated this function at all. And\n> > it seems to be the most portable way to get a password, even if it's\n> > not in POSIX.\n> >\n> > BSDs have readpassphrase(3), but glibc doesn't, so unless you\n> > recommend\n> \n> OpenBSD also marks getpass(3) as obsolete and recommends\n> readpassphrase(3):\n> \n> \n> > using readpassphrase(3) from libbsd, or plan to add it to glibc, I\n> > think\n> > getpass(3) should be the recommended function in Linux, and therefore\n> > we should remove the hard words against it.\n> >\n> > As a real example, git(1) uses getpass(3).\n> > \n> >\n> > What are your thoughts?\n\ngetpass() 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.\n\n-Randall\n\n"},{"id":"439999","messageId":"865e5899-b991-918d-8bc6-ced65a67a566@gmail.com","threadId":"56805","inReplyTo":"211029.86r1c43uwj.gmgdl@evledraar.gmail.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Alejandro Colomar (man-pages)","fromEmail":"alx.manpages@gmail.com","sentAt":"2021-10-29T12:11:33Z","receivedAt":"2021-10-29T12:11:38Z","isPatch":false,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"Hi Ævar,\n\nOn 10/29/21 13:40, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Fri, Oct 29 2021, Alejandro Colomar (man-pages) wrote:\n> \n>> [Add a few CCs, since I mentioned them.]\n> \n> [I'm not sure what the full context of this thread is, but just replying\n> from the POV of git@ being CC'd on this]\n\nThe first message on this thread was mine from '10/29/21 13:15', so \nyou've read it all.\n\nThe broader context is that I was trying to make the deprecation notices \nmore consistent in the Linux manpages, by using the [[deprecated]] \nattribute where appropriate. While doing that, I found a few cases \nwhere the deprecation/obsoletion is not so clear to me, such as this one \n([as]ctime[_r](3) is another one, since it is deprecated by POSIX, but \nnot by the C standard, but I'll start a different thread with that; and \nisascii(3) is another one, since the user of it should know if the \ncharacter set he's using is compatible with ascii, and in that case it's \nperfectly valid, it's only a case of garbage in garbage out, IMO).\n\n> \n>> On 10/29/21 13:15, Alejandro Colomar wrote:\n>>> Hi,\n>>> As the manual pages says, SUSv2 marked it as LEGACY, and POSIX\n>>> doesn't have it at all.  The manual page goes further and says \"This\n>>> function is obsolete. Do not use it.\" in its first lines.\n>>> But, glibc doesn't seem to have deprecated this function at all.\n>>> And it seems to be the most portable way to get a password, even if\n>>> it's not in POSIX.\n>>> BSDs have readpassphrase(3), but glibc doesn't, so unless you\n>>> recommend\n[...]\n\nCheers,\n\nAlex\n\n-- \nAlejandro Colomar\nLinux man-pages comaintainer; https://www.kernel.org/doc/man-pages/\nhttp://www.alejandro-colomar.es/\n"},{"id":"440008","messageId":"CACGkJdsdK_mgEH_v73NnVwQ2RA6cHtuyP4p1nvKveTEYnRhSBw@mail.gmail.com","threadId":"56805","inReplyTo":"00d501d7ccbe$0169c340$043d49c0$@nexbridge.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Eugene Syromyatnikov","fromEmail":"evgsyr@gmail.com","sentAt":"2021-10-29T13:55:07Z","receivedAt":"2021-10-29T13:55:27Z","isPatch":false,"sender":{"key":"evgsyr@gmail.com","avatar":null},"body":"On Fri, Oct 29, 2021 at 2:40 PM wrote:\n> 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.\n\nPOSIX.2 is not a newer POSIX version, but rather a book (“Shell and\nutilities”) in pre-2001 standard revisions, and it has nothing to do\nwith the system interfaces (that is POSIX.1).\nAnd the only mention of getpass() in POSIX (at least, since the 2001's\nedition) indeed seems to be [1], in the list of functions that have\nnot been carried forward from XSH5, the 1997 revision of “System\nInterfaces and Headers” (that is, SUSv2)[2], where it is inherited\nfrom SUSv1[4] from XPG[5] and, as Alejandro already mentioned, marked\nas obsolete, per XPG3 to XPG4 migration guide[6]; the previous, 1988,\nversion of POSIX[3] does not mention getpass() at all.\n\n[1] https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap01.html\n[2] https://pubs.opengroup.org/onlinepubs/7908799/xsh/getpass.html\n[3] https://mirror.math.princeton.edu/pub/oldlinux/download/c953.pdf\n[4] https://pubs.opengroup.org/onlinepubs/9695969499/toc.pdf\n[5] https://bitsavers.computerhistory.org/pdf/xOpen/X_Open_Portability_Guide_1985/xpg_2_xopen_system_v_specification_2.pdf\n[6] http://archive.opengroup.org/publications/archive/CDROM/g501.pdf\n\n-- \nEugene Syromyatnikov\nmailto:evgsyr@gmail.com\nxmpp:esyr@jabber.{ru|org}\n"},{"id":"440018","messageId":"63238.1635515736@cvs.openbsd.org","threadId":"56805","inReplyTo":"00d501d7ccbe$0169c340$043d49c0$@nexbridge.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Theo de Raadt","fromEmail":"deraadt@openbsd.org","sentAt":"2021-10-29T13:55:36Z","receivedAt":"2021-10-29T14:02:41Z","isPatch":false,"sender":{"key":"deraadt@openbsd.org","avatar":null},"body":" wrote:\n\n> On October 29, 2021 7:29 AM, Alejandro Colomar wrote:\n> > On 10/29/21 13:15, Alejandro Colomar wrote:\n> > > Hi,\n> > >\n> > > As the manual pages says, SUSv2 marked it as LEGACY, and POSIX doesn't\n> > > have it at all. The manual page goes further and says \"This function\n> > > is obsolete. Do not use it.\" in its first lines.\n> > >\n> > > But, glibc doesn't seem to have deprecated this function at all. And\n> > > it seems to be the most portable way to get a password, even if it's\n> > > not in POSIX.\n> > >\n> > > BSDs have readpassphrase(3), but glibc doesn't, so unless you\n> > > recommend\n> > \n> > OpenBSD also marks getpass(3) as obsolete and recommends\n> > readpassphrase(3):\n> > \n> > \n> > > using readpassphrase(3) from libbsd, or plan to add it to glibc, I\n> > > think\n> > > getpass(3) should be the recommended function in Linux, and therefore\n> > > we should remove the hard words against it.\n> > >\n> > > As a real example, git(1) uses getpass(3).\n> > > \n> > >\n> > > What are your thoughts?\n> \n> 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.\n\n\nThe community finally had the balls to get rid of gets(3).\n\ngetpass(3) shares the same flaw, that the buffer size isn't passed.\nThis has been an issue in the past, and incorrectly led to readpassphrase(3)\n\nreadpassphrase(3) has a few too many features/extensions for my taste, but\nat least it is harder to abuse.\n"},{"id":"440019","messageId":"00e401d7cccf$ccde0d40$669a27c0$@nexbridge.com","threadId":"56805","inReplyTo":"63238.1635515736@cvs.openbsd.org","subject":"RE: Is getpass(3) really obsolete?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-10-29T14:18:04Z","receivedAt":"2021-10-29T14:18:19Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 29, 2021 9:56 AM, Theo de Raadt wrote:\n> Subject: Re: Is getpass(3) really obsolete?\n> wrote:\n> \n> > On October 29, 2021 7:29 AM, Alejandro Colomar wrote:\n> > > On 10/29/21 13:15, Alejandro Colomar wrote:\n> > > > Hi,\n> > > >\n> > > > As the manual pages says, SUSv2 marked it as LEGACY, and POSIX\n> > > > doesn't have it at all. The manual page goes further and says\n> > > > \"This function is obsolete. Do not use it.\" in its first lines.\n> > > >\n> > > > But, glibc doesn't seem to have deprecated this function at all.\n> > > > And it seems to be the most portable way to get a password, even\n> > > > if it's not in POSIX.\n> > > >\n> > > > BSDs have readpassphrase(3), but glibc doesn't, so unless you\n> > > > recommend\n> > >\n> > > OpenBSD also marks getpass(3) as obsolete and recommends\n> > > readpassphrase(3):\n> > > \n> > >\n> > > > using readpassphrase(3) from libbsd, or plan to add it to glibc, I\n> > > > think\n> > > > getpass(3) should be the recommended function in Linux, and\n> > > > therefore we should remove the hard words against it.\n> > > >\n> > > > As a real example, git(1) uses getpass(3).\n> > > > \n> > > >\n> > > > What are your thoughts?\n> >\n> > getpass() is obsolete in POSIX.2. However, some platforms still are on\nPOSIX.1,\n> so replacing it instead of providing a configure detection/switch for it\nmight\n> cause issues.\n> \n> \n> The community finally had the balls to get rid of gets(3).\n> \n> getpass(3) shares the same flaw, that the buffer size isn't passed.\n> This has been an issue in the past, and incorrectly led to\nreadpassphrase(3)\n> \n> readpassphrase(3) has a few too many features/extensions for my taste, but\nat\n> least it is harder to abuse.\n\nreadpassphrase is not generally supported. This will break builds on many\nplatforms.\n\n"},{"id":"440020","messageId":"73029.1635517278@cvs.openbsd.org","threadId":"56805","inReplyTo":"00e401d7cccf$ccde0d40$669a27c0$@nexbridge.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Theo de Raadt","fromEmail":"deraadt@openbsd.org","sentAt":"2021-10-29T14:21:18Z","receivedAt":"2021-10-29T14:21:20Z","isPatch":false,"sender":{"key":"deraadt@openbsd.org","avatar":null},"body":" wrote:\n\n> > > getpass() is obsolete in POSIX.2. However, some platforms still are on\n> POSIX.1,\n> > so replacing it instead of providing a configure detection/switch for it\n> might\n> > cause issues.\n> > \n> > \n> > The community finally had the balls to get rid of gets(3).\n> > \n> > getpass(3) shares the same flaw, that the buffer size isn't passed.\n> > This has been an issue in the past, and incorrectly led to\n> readpassphrase(3)\n> > \n> > readpassphrase(3) has a few too many features/extensions for my taste, but\n> at\n> > least it is harder to abuse.\n> \n> readpassphrase is not generally supported. This will break builds on many\n> platforms.\n\nOf course moving forward takes a long time. If a better API is supplied\nthen there is a choice in 10 years. If a better API is not supplied,\nthen 10 years from now this conversation can get a reply.\n\n\n\n"},{"id":"440021","messageId":"00e701d7ccd2$058b9070$10a2b150$@nexbridge.com","threadId":"56805","inReplyTo":"73029.1635517278@cvs.openbsd.org","subject":"RE: Is getpass(3) really obsolete?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-10-29T14:33:58Z","receivedAt":"2021-10-29T14:34:12Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"October 29, 2031 10:21 AM, Theo de Raadt will write:\n> wrote:\n> \n> > > > getpass() is obsolete in POSIX.2. However, some platforms still\n> > > > are on\n> > POSIX.1,\n> > > so replacing it instead of providing a configure detection/switch\n> > > for it\n> > might\n> > > cause issues.\n> > >\n> > >\n> > > The community finally had the balls to get rid of gets(3).\n> > >\n> > > getpass(3) shares the same flaw, that the buffer size isn't passed.\n> > > This has been an issue in the past, and incorrectly led to\n> > readpassphrase(3)\n> > >\n> > > readpassphrase(3) has a few too many features/extensions for my\n> > > taste, but\n> > at\n> > > least it is harder to abuse.\n> >\n> > readpassphrase is not generally supported. This will break builds on\n> > many platforms.\n> \n> Of course moving forward takes a long time. If a better API is supplied then\n> there is a choice in 10 years. If a better API is not supplied, then 10 years from\n> now this conversation can get a reply.\n\nI 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.\n\n"},{"id":"440022","messageId":"326e75f9-f732-a7a8-22dc-5fc304601b39@gmail.com","threadId":"56805","inReplyTo":"00e701d7ccd2$058b9070$10a2b150$@nexbridge.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Alejandro Colomar (man-pages)","fromEmail":"alx.manpages@gmail.com","sentAt":"2021-10-29T14:44:50Z","receivedAt":"2021-10-29T14:44:55Z","isPatch":false,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"Hi Randall, Theo,\n\nOn 10/29/21 16:33, rsbecker@nexbridge.com wrote:\n> October 29, 2031 10:21 AM, Theo de Raadt will write:\n>> wrote:\n>>\n>>>>> getpass() is obsolete in POSIX.2. However, some platforms still\n>>>>> are on\n>>> POSIX.1,\n>>>> so replacing it instead of providing a configure detection/switch\n>>>> for it\n>>> might\n>>>> cause issues.\n>>>>\n>>>>\n>>>> The community finally had the balls to get rid of gets(3).\n>>>>\n>>>> getpass(3) shares the same flaw, that the buffer size isn't passed.\n>>>> This has been an issue in the past, and incorrectly led to\n>>> readpassphrase(3)\n\nThat seems a good reason to keep the \"Do not use it.\" note in the manual \npage. I think I'll add a recommendation for readpassphrase(3bsd) for \nthe moment which is the only alternative available in Linux.\n\n>>>>\n>>>> readpassphrase(3) has a few too many features/extensions for my\n>>>> taste, but\n>>> at\n>>>> least it is harder to abuse.\n>>>\n>>> readpassphrase is not generally supported. This will break builds on\n>>> many platforms.\nI found readpassphrase(3) in FreeBSD and OpenBSD.\nIt is also present in libbsd(7), which is available in most Linux \ndistributions.\nI also found it on a Mac that I have access.\n\nNetBSD has getpass_r(3) instead. It is not in any other system I have \naccess.\n\n\n>>\n>> Of course moving forward takes a long time. If a better API is supplied then\n>> there is a choice in 10 years. If a better API is not supplied, then 10 years from\n>> now this conversation can get a reply.\n> \n> 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.\n> \nlibbsd(7) is probably the compatibility layer that you're looking for. \nWhat system are you on?\n\n\n\nCheers,\n\nAlex\n\n\n-- \nAlejandro Colomar\nLinux man-pages comaintainer; https://www.kernel.org/doc/man-pages/\nhttp://www.alejandro-colomar.es/\n"},{"id":"440023","messageId":"6d8642e9-71f7-4a83-9791-880d04f67d17@www.fastmail.com","threadId":"56805","inReplyTo":"63238.1635515736@cvs.openbsd.org","subject":"Re: Is getpass(3) really obsolete?","fromName":"Zack Weinberg","fromEmail":"zack@owlfolio.org","sentAt":"2021-10-29T14:53:53Z","receivedAt":"2021-10-29T14:54:32Z","isPatch":false,"sender":{"key":"zack@owlfolio.org","avatar":null},"body":"On Fri, Oct 29, 2021, at 9:55 AM, Theo de Raadt wrote:\n> wrote:\n>> On October 29, 2021 7:29 AM, Alejandro Colomar wrote:\n>> > On 10/29/21 13:15, Alejandro Colomar wrote:\n>> > > Hi,\n>> > >\n>> > > As the manual pages says, SUSv2 marked it as LEGACY, and POSIX doesn't\n>> > > have it at all. The manual page goes further and says \"This function\n>> > > is obsolete. Do not use it.\" in its first lines.\n...\n> The community finally had the balls to get rid of gets(3).\n>\n> getpass(3) shares the same flaw, that the buffer size isn't passed.\n> This has been an issue in the past\n\nI 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.\n\n(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).)\n\nThe 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.\n\n> readpassphrase(3) has a few too many features/extensions for my taste, but\n> at least it is harder to abuse.\n\nI 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.\n\nWith 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.\n\nzw\n"},{"id":"440024","messageId":"00f001d7ccd5$bf25e0f0$3d71a2d0$@nexbridge.com","threadId":"56805","inReplyTo":"326e75f9-f732-a7a8-22dc-5fc304601b39@gmail.com","subject":"RE: Is getpass(3) really obsolete?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-10-29T15:00:38Z","receivedAt":"2021-10-29T15:00:52Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 29, 2021 10:45 AM, Alejandro Colomar wrote:\n> On 10/29/21 16:33, rsbecker@nexbridge.com wrote:\n> > October 29, 2031 10:21 AM, Theo de Raadt will write:\n> >> wrote:\n> >>\n> >>>>> getpass() is obsolete in POSIX.2. However, some platforms still\n> >>>>> are on\n> >>> POSIX.1,\n> >>>> so replacing it instead of providing a configure detection/switch\n> >>>> for it\n> >>> might\n> >>>> cause issues.\n> >>>>\n> >>>>\n> >>>> The community finally had the balls to get rid of gets(3).\n> >>>>\n> >>>> getpass(3) shares the same flaw, that the buffer size isn't passed.\n> >>>> This has been an issue in the past, and incorrectly led to\n> >>> readpassphrase(3)\n> \n> That seems a good reason to keep the \"Do not use it.\" note in the manual page.\n> I think I'll add a recommendation for readpassphrase(3bsd) for the moment\n> which is the only alternative available in Linux.\n> \n> >>>>\n> >>>> readpassphrase(3) has a few too many features/extensions for my\n> >>>> taste, but\n> >>> at\n> >>>> least it is harder to abuse.\n> >>>\n> >>> readpassphrase is not generally supported. This will break builds on\n> >>> many platforms.\n> I found readpassphrase(3) in FreeBSD and OpenBSD.\n> It is also present in libbsd(7), which is available in most Linux distributions.\n> I also found it on a Mac that I have access.\n> \n> NetBSD has getpass_r(3) instead. It is not in any other system I have access.\n> \n> \n> >>\n> >> Of course moving forward takes a long time. If a better API is supplied then\n> >> there is a choice in 10 years. If a better API is not supplied, then 10 years\n> from\n> >> now this conversation can get a reply.\n> >\n> > I checked the API 10 years from now (check the above date) at it's still not\n> there 😉 In the meantime, compatibility is important. I checked the latest\n> release (last week's) on my platform and readpassphrase() is not available. Let's\n> please put a compatibility layer in.\n> >\n> libbsd(7) is probably the compatibility layer that you're looking for.\n> What system are you on?\n> \n> \n\nI 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.\n\nThanks,\nRandall\n\n"},{"id":"440025","messageId":"20211029152728.42938-1-alx.manpages@gmail.com","threadId":"56805","inReplyTo":"73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com","subject":"[PATCH] getpass.3: SYNOPSIS: Mark getpass() as [[deprecated]]","fromName":"Alejandro Colomar","fromEmail":"alx.manpages@gmail.com","sentAt":"2021-10-29T15:27:29Z","receivedAt":"2021-10-29T15:29:25Z","isPatch":true,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"Suggest readpassphrase(3bsd) as an alternative.\n\nSee the long discussion in the mailing list for more details (link\nat the bottom of this commit message). I'll quote some relevant\nparts here:\n\nEugene Syromyatnikov :\n{\n\tAnd the only mention of getpass() in POSIX (at least,\n\tsince the 2001's edition) indeed seems to be [1], in the\n\tlist of functions that have not been carried forward from\n\tXSH5, the 1997 revision of “System Interfaces and Headers”\n\t(that is, SUSv2)[2], where it is inherited from SUSv1[4]\n\tfrom XPG[5] and, as Alejandro already mentioned, marked as\n\tobsolete, per XPG3 to XPG4 migration guide[6]; the\n\tprevious, 1988, version of POSIX[3] does not mention\n\tgetpass() at all.\n\n\t[1] https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap01.html\n\t[2] https://pubs.opengroup.org/onlinepubs/7908799/xsh/getpass.html\n\t[3] https://mirror.math.princeton.edu/pub/oldlinux/download/c953.pdf\n\t[4] https://pubs.opengroup.org/onlinepubs/9695969499/toc.pdf\n\t[5] https://bitsavers.computerhistory.org/pdf/xOpen/X_Open_Portability_Guide_1985/xpg_2_xopen_system_v_specification_2.pdf\n\t[6] http://archive.opengroup.org/publications/archive/CDROM/g501.pdf\n}\n\nTheo de Raadt :\n{\n\tThe community finally had the balls to get rid of gets(3).\n\n\tgetpass(3) shares the same flaw, that the buffer size\n\tisn't passed. This has been an issue in the past, and\n\tincorrectly led to readpassphrase(3).\n\n\treadpassphrase(3) has a few too many features/extensions\n\tfor my taste, but at least it is harder to abuse.\n}\n\nAlejandro Colomar :\n{\n\tI found readpassphrase(3) in FreeBSD and OpenBSD. It is\n\talso present in libbsd(7), which is available in most\n\tLinux distributions. I also found it on a Mac that I have\n\taccess.\n\n\tNetBSD has getpass_r(3) instead. It is not in any other\n\tsystem I have access.\n}\n\nZack Weinberg :\n{\n\tI was about to post exactly the same thing. getpass(3)\n\tis not deprecated because there's a better replacement,\n\tit's deprecated because it's _unsafe_. The glibc\n\timplementation wraps getline(3) and therefore doesn't\n\ttruncate the passphrase or overflow a fixed-size buffer,\n\tno matter how long the input is, but portable code cannot\n\trely on that. And come to think of it, using getline(3)\n\tmeans that prefixes of the passphrase may be left lying\n\taround in malloc's free lists.\n\n\t(getpass also cannot be made thread safe, due to recycling\n\tof a static buffer, but a program in which multiple\n\tthreads are racing to prompt the user for passwords would\n\tbe a UX disaster anyway, so I don't think that's a\n\tcritical flaw the way it is for e.g. strtok(3).)\n\n\tThe Linux manpage project's documentation is, as I\n\tunderstand it, for Linux with glibc _first_, but not\n\t_only_; it should not describe this function as\n\tnot-deprecated just because glibc has patched its worst\n\tproblems and doesn't offer any better API.\n}\n\nList: linux-man \nSigned-off-by: Alejandro Colomar \nCc: Git \nCc: Glibc \nCc: OpenBSD \nCc: Ævar Arnfjörð Bjarmason \nCc: Benoit Lecocq \nCc: Klemens Nanni \nCc: Randall \nCc: Eugene Syromyatnikov \nCc: Theo de Raadt \nCc: Zack Weinberg \nCc: Florian Weimer \n---\n man3/getpass.3 | 9 +++++++--\n 1 file changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/man3/getpass.3 b/man3/getpass.3\nindex fa2031544..7d6da07fa 100644\n--- a/man3/getpass.3\n+++ b/man3/getpass.3\n@@ -28,7 +28,7 @@ getpass \\- get a password\n .nf\n .B #include \n .PP\n-.BI \"char *getpass(const char *\" prompt );\n+.BI \"[[deprecated]] char *getpass(const char *\" prompt );\n .fi\n .PP\n .RS -4\n@@ -48,6 +48,7 @@ Feature Test Macro Requirements for glibc (see\n .SH DESCRIPTION\n This function is obsolete.\n Do not use it.\n+See NOTES.\n If you want to read input without terminal echoing enabled,\n see the description of the\n .I ECHO\n@@ -126,7 +127,11 @@ Removed in POSIX.1-2001.\n .\\\" are transmitted as part of the password.\n .\\\" Since libc 5.4.19 also line editing is disabled, so that also\n .\\\" backspace and the like will be seen as part of the password.\n-.\n+You should use instead\n+.BR readpassphrase (3bsd),\n+provided by\n+.IR libbsd .\n+.PP\n In the GNU C library implementation, if\n .I /dev/tty\n cannot be opened, the prompt is written to\n-- \n2.33.1\n\n"},{"id":"440026","messageId":"alpine.DEB.2.22.394.2110291627330.1788146@digraph.polyomino.org.uk","threadId":"56805","inReplyTo":"865e5899-b991-918d-8bc6-ced65a67a566@gmail.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Joseph Myers","fromEmail":"joseph@codesourcery.com","sentAt":"2021-10-29T16:31:23Z","receivedAt":"2021-10-29T16:31:31Z","isPatch":false,"sender":{"key":"joseph@codesourcery.com","avatar":null},"body":"On Fri, 29 Oct 2021, Alejandro Colomar (man-pages) via Libc-alpha wrote:\n\n> The broader context is that I was trying to make the deprecation notices more\n> consistent in the Linux manpages, by using the [[deprecated]] attribute where\n> appropriate. While doing that, I found a few cases where the\n> deprecation/obsoletion is not so clear to me, such as this one\n> ([as]ctime[_r](3) is another one, since it is deprecated by POSIX, but not by\n> the C standard, but I'll start a different thread with that; and isascii(3) is\n\nSee the discussion of deprecation starting with \n (C2X \nhas also deprecated those functions). The comments in that thread \nsupported marking the functions deprecated, but it needs someone to send a \npatch and I don't know what breakage might result in applications using \nthose functions.\n\n-- \nJoseph S. Myers\njoseph@codesourcery.com\n"},{"id":"440059","messageId":"YXxZFaqHq9/aEQCO@coredump.intra.peff.net","threadId":"56805","inReplyTo":"73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-10-29T20:27:01Z","receivedAt":"2021-10-29T20:27:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 29, 2021 at 01:28:56PM +0200, Alejandro Colomar (man-pages) wrote:\n\n> > As a real example, git(1) uses getpass(3).\n> > \n\nSort of. It is the compile-time fallback of last resort. Most builds\nwould use either termios with /dev/tty or a Windows-native equivalent.\n\nYou can see all the reasons we stopped using getpass() in the commit\nbelow.\n\n-- >8 --\ncommit 21aeafceda2382d26bfa73a98ba45a937d65d77a\nAuthor: Jeff King \nDate: Sat Dec 10 05:41:01 2011 -0500\n\n add generic terminal prompt function\n \n When we need to prompt the user for input interactively, we\n want to access their terminal directly. We can't rely on\n stdio because it may be connected to pipes or files, rather\n than the terminal. Instead, we use \"getpass()\", because it\n abstracts the idea of prompting and reading from the\n terminal. However, it has some problems:\n \n 1. It never echoes the typed characters, which makes it OK\n for passwords but annoying for other input (like usernames).\n \n 2. Some implementations of getpass() have an extremely\n small input buffer (e.g., Solaris 8 is reported to\n support only 8 characters).\n \n 3. Some implementations of getpass() will fall back to\n reading from stdin (e.g., glibc). We explicitly don't\n want this, because our stdin may be connected to a pipe\n speaking a particular protocol, and reading will\n disrupt the protocol flow (e.g., the remote-curl\n helper).\n \n 4. Some implementations of getpass() turn off signals, so\n that hitting \"^C\" on the terminal does not break out of\n the password prompt. This can be a mild annoyance.\n \n Instead, let's provide an abstract \"git_terminal_prompt\"\n function that addresses these concerns. This patch includes\n an implementation based on /dev/tty, enabled by setting\n HAVE_DEV_TTY. The fallback is to use getpass() as before.\n \n Signed-off-by: Jeff King \n Signed-off-by: Junio C Hamano \n"},{"id":"440121","messageId":"fd78c241-c51e-03c6-1e6b-641536245fbd@gmail.com","threadId":"56805","inReplyTo":"alpine.DEB.2.22.394.2110291627330.1788146@digraph.polyomino.org.uk","subject":"Re: Is getpass(3) really obsolete?","fromName":"Alejandro Colomar (man-pages)","fromEmail":"alx.manpages@gmail.com","sentAt":"2021-10-30T12:24:55Z","receivedAt":"2021-10-30T12:25:01Z","isPatch":false,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"Hi Joseph,\n\nOn 10/29/21 18:31, Joseph Myers wrote:\n> On Fri, 29 Oct 2021, Alejandro Colomar (man-pages) via Libc-alpha wrote:\n> \n>> The broader context is that I was trying to make the deprecation notices more\n>> consistent in the Linux manpages, by using the [[deprecated]] attribute where\n>> appropriate. While doing that, I found a few cases where the\n>> deprecation/obsoletion is not so clear to me, such as this one\n>> ([as]ctime[_r](3) is another one, since it is deprecated by POSIX, but not by\n>> the C standard, but I'll start a different thread with that; and isascii(3) is\n> \n> See the discussion of deprecation starting with\n> (C2X\n> has also deprecated those functions). The comments in that thread\n> supported marking the functions deprecated, but it needs someone to send a\n> patch and I don't know what breakage might result in applications using\n> those functions.\n> \n\nThanks. The latest draft for C2x that I know of is N2596. Is there any \nnewer draft that I can consult for these things? I see many proposals, \nbut it's difficult to know which have been accepted and which not \nwithout an actual recent draft of the standard.\n\nCheers,\n\nAlex\n\n\n-- \nAlejandro Colomar\nLinux man-pages comaintainer; https://www.kernel.org/doc/man-pages/\nhttp://www.alejandro-colomar.es/\n"},{"id":"440277","messageId":"alpine.DEB.2.22.394.2111012124460.1978253@digraph.polyomino.org.uk","threadId":"56805","inReplyTo":"fd78c241-c51e-03c6-1e6b-641536245fbd@gmail.com","subject":"Re: Is getpass(3) really obsolete?","fromName":"Joseph Myers","fromEmail":"joseph@codesourcery.com","sentAt":"2021-11-01T21:31:31Z","receivedAt":"2021-11-01T21:31:44Z","isPatch":false,"sender":{"key":"joseph@codesourcery.com","avatar":null},"body":"On Sat, 30 Oct 2021, Alejandro Colomar (man-pages) via Libc-alpha wrote:\n\n> > See the discussion of deprecation starting with\n> > (C2X\n> > has also deprecated those functions). The comments in that thread\n> > supported marking the functions deprecated, but it needs someone to send a\n> > patch and I don't know what breakage might result in applications using\n> > those functions.\n> \n> Thanks. The latest draft for C2x that I know of is N2596. Is there any newer\n> draft that I can consult for these things? I see many proposals, but it's\n\nThe latest public draft is N2731, but there are still various accepted \nproposals not included in there, including N2566 (wording version 2) which \nI believe was accepted in October 2020 (I think issue 68 in the (private) \nC standard GitLab, for integrating that paper, has been incorrectly closed \nwithout integrating it).\n\n-- \nJoseph S. Myers\njoseph@codesourcery.com\n"},{"id":"463753","messageId":"c8287618-30c4-f14b-8ad7-898fee99d944@gmail.com","threadId":"56805","inReplyTo":"6d8642e9-71f7-4a83-9791-880d04f67d17@www.fastmail.com","subject":"readpassphrase(3) in glibc, and agetpass() (Was: Is getpass(3) really obsolete?)","fromName":"Alejandro Colomar","fromEmail":"alx.manpages@gmail.com","sentAt":"2022-09-27T19:19:06Z","receivedAt":"2022-09-27T19:19:16Z","isPatch":false,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"Hi Zack,\n\nOn 10/29/21 16:53, Zack Weinberg via Libc-alpha wrote:\n> On Fri, Oct 29, 2021, at 9:55 AM, Theo de Raadt wrote:\n>> wrote:\n>>> On October 29, 2021 7:29 AM, Alejandro Colomar wrote:\n>>>> On 10/29/21 13:15, Alejandro Colomar wrote:\n>>>>> Hi,\n>>>>>\n>>>>> As the manual pages says, SUSv2 marked it as LEGACY, and POSIX doesn't\n>>>>> have it at all. The manual page goes further and says \"This function\n>>>>> is obsolete. Do not use it.\" in its first lines.\n> ...\n>> The community finally had the balls to get rid of gets(3).\n>>\n>> getpass(3) shares the same flaw, that the buffer size isn't passed.\n>> This has been an issue in the past\n> \n> 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.\n> \n> (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).)\n> \n> 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.\n> \n>> readpassphrase(3) has a few too many features/extensions for my taste, but\n>> at least it is harder to abuse.\n> \n> 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.\n> \n> 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.\n> \n> zw\n\nI happen to be working on replacing getpass(3) in shadow-utils. As \nthere is no replacement in glibc, I'm making the code depend on libbsd \non GNU systems.\n\nI developed a function similar to getpass(3), but which allocates a \nbuffer (similar to asprintf(3)). I only allocate once, and bail out if \nthe password exceeds PASS_MAX, so no leaks in allocated memory (modulo \nbugs that I may have not noticed).\n\nI also enforce both clearing and freeing the memory, by requiring a \nspecific clean-up function.\n\nThe prototypes for the function and the clean-up are:\n\n```\nvoid erase_pass(char *p);\n[[gnu::malloc(erase_pass)]] char *shdw_getpass(const char *prompt);\n\n```\n\nAnd the implementation is:\n\n```\n#include \"prototypes.h\"\n\n#include \n#include \n#include \n#include \n\n\n#if !defined(PASS_MAX)\n#define PASS_MAX BUFSIZ\n#endif\n\n\nchar *\nagetpass(const char *prompt)\n{\n\tchar *p;\n\tsize_t len;\n\n\tp = malloc(PASS_MAX);\n\tif (p == NULL)\n\t\treturn NULL;\n\n\tif (readpassphrase(prompt, p, PASS_MAX, 0) == NULL)\n\t\tgoto fail;\n\n\tlen = strlen(p);\n\n\tif (len == 0)\n\t\treturn p;\n\n\tif (p[len - 1] != '\\n')\n\t\tgoto truncated;\n\n\tp[len - 1] = '\\0';\n\n\treturn p;\n\ntruncated:\n\tmemzero(p, PASS_MAX);\nfail:\n\tfree(p);\n\treturn NULL;\n}\n\n\nvoid\nerase_pass(char *p)\n{\n\tif (p != NULL)\n\t\tmemzero(p, PASS_MAX);\n\tfree(p);\n}\n```\n\n\nWould you mind implementing readpassphrase(3) in glibc so that it's \neasier to use something safe and portable without resorting to \ncompatibility libraries? Also, I'd like some review of this function, \nif you think the API could be improved. Maybe agetpass() would be a \nsimple almost-drop-in replacement for getpass(3), so if you like it for \nglibc, let's discuss it.\n\nI chose a predefined buffer size to not have to pass a buffer size all \nthe time, which could be error-prone. I also allocated the buffer \ninternally, to make it easier to replace getpass(3). It may be \ndesirable to use existing buffers, and pass them through a pointer, but \nfor shadow-utils, it was simpler to keep the getpass(3) API.\n\nI don't know what was the practice with PASS_MAX regarding the NUL byte, \nbut to avoid creating a buffer of a power of two plus one, I decided \nthat the NUL byte would be within PASS_MAX. Another solution would be \nto declare PASS_MAX to be something like BUFSIZ-1, and then use \nPASS_MAX+1, but I opted for simplicity.\n\nWhat are your thoughts?\n\nCheers,\n\nAlex\n"},{"id":"463755","messageId":"242f444d-9846-1a13-d901-9ad503dce605@gmail.com","threadId":"56805","inReplyTo":"c8287618-30c4-f14b-8ad7-898fee99d944@gmail.com","subject":"Re: readpassphrase(3) in glibc, and agetpass() (Was: Is getpass(3) really obsolete?)","fromName":"Alex Colomar","fromEmail":"alx.manpages@gmail.com","sentAt":"2022-09-27T19:33:05Z","receivedAt":"2022-09-27T19:33:21Z","isPatch":false,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"On 9/27/22 21:19, Alejandro Colomar wrote:\n...\n> \n> The prototypes for the function and the clean-up are:\n> \n> ```\n> void erase_pass(char *p);\n> [[gnu::malloc(erase_pass)]] char *shdw_getpass(const char *prompt);\n\nI edited the function name for the email, and forgot to fix it here :)\n\ns/shdw_/a/\n\nCheers,\n\nAlex\n\n\n-- \n\n\n"},{"id":"463759","messageId":"180409CA-768D-44E5-A15D-91F66F8EC0C2@gentoo.org","threadId":"56805","inReplyTo":"c8287618-30c4-f14b-8ad7-898fee99d944@gmail.com","subject":"Re: readpassphrase(3) in glibc, and agetpass() (Was: Is getpass(3) really obsolete?)","fromName":"Sam James","fromEmail":"sam@gentoo.org","sentAt":"2022-09-27T20:30:12Z","receivedAt":"2022-09-27T20:32:12Z","isPatch":false,"sender":{"key":"sam@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/11667869?v=4"},"body":"\n\n> On 27 Sep 2022, at 20:19, Alejandro Colomar via Libc-alpha wrote:\n> \n> Hi Zack,\n> \n> On 10/29/21 16:53, Zack Weinberg via Libc-alpha wrote:\n>> On Fri, Oct 29, 2021, at 9:55 AM, Theo de Raadt wrote:\n>>> wrote:\n>>>> On October 29, 2021 7:29 AM, Alejandro Colomar wrote:\n>>>>> On 10/29/21 13:15, Alejandro Colomar wrote:\n>>>>>> Hi,\n>>>>>> \n>>>>>> As the manual pages says, SUSv2 marked it as LEGACY, and POSIX doesn't\n>>>>>> have it at all. The manual page goes further and says \"This function\n>>>>>> is obsolete. Do not use it.\" in its first lines.\n>> ...\n>>> The community finally had the balls to get rid of gets(3).\n>>> \n>>> getpass(3) shares the same flaw, that the buffer size isn't passed.\n>>> This has been an issue in the past\n>> 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.\n>> (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).)\n>> 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.\n>>> readpassphrase(3) has a few too many features/extensions for my taste, but\n>>> at least it is harder to abuse.\n>> 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.\n>> 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.\n>> zw\n> \n> I happen to be working on replacing getpass(3) in shadow-utils. As there is no replacement in glibc, I'm making the code depend on libbsd on GNU systems.\n> \n> I developed a function similar to getpass(3), but which allocates a buffer (similar to asprintf(3)). I only allocate once, and bail out if the password exceeds PASS_MAX, so no leaks in allocated memory (modulo bugs that I may have not noticed).\n> \n> I also enforce both clearing and freeing the memory, by requiring a specific clean-up function.\n> \n> The prototypes for the function and the clean-up are:\n> \n> [snip]\n> Would you mind implementing readpassphrase(3) in glibc so that it's easier to use something safe and portable without resorting to compatibility libraries? Also, I'd like some review of this function, if you think the API could be improved. Maybe agetpass() would be a simple almost-drop-in replacement for getpass(3), so if you like it for glibc, let's discuss it.\n> \nI assume it'd be libxcrypt instead?\n\nBest,\nsam\n"}]}