All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: rsbecker@nexbridge.com, 'Theo de Raadt' <deraadt@openbsd.org>
Cc: 'Libc-alpha' <libc-alpha@sourceware.org>,
	'linux-man' <linux-man@vger.kernel.org>,
	git@vger.kernel.org, tech@openbsd.org
Subject: Re: Is getpass(3) really obsolete?
Date: Fri, 29 Oct 2021 16:44:50 +0200	[thread overview]
Message-ID: <326e75f9-f732-a7a8-22dc-5fc304601b39@gmail.com> (raw)
In-Reply-To: <00e701d7ccd2$058b9070$10a2b150$@nexbridge.com>

Hi Randall, Theo,

On 10/29/21 16:33, rsbecker@nexbridge.com wrote:
> October 29, 2031 10:21 AM, Theo de Raadt will write:
>> <rsbecker@nexbridge.com> 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?

<https://libbsd.freedesktop.org/wiki/>

Cheers,

Alex


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

  reply	other threads:[~2021-10-29 14:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29 11:15 Is getpass(3) really obsolete? Alejandro Colomar
2021-10-29 11:28 ` Alejandro Colomar (man-pages)
2021-10-29 11:40   ` Ævar Arnfjörð Bjarmason
2021-10-29 12:11     ` Alejandro Colomar (man-pages)
2021-10-29 16:31       ` Joseph Myers
2021-10-30 12:24         ` Alejandro Colomar (man-pages)
2021-11-01 21:31           ` Joseph Myers
2021-10-29 12:10   ` rsbecker
2021-10-29 13:55     ` Eugene Syromyatnikov
2021-10-29 13:55     ` Theo de Raadt
2021-10-29 14:18       ` rsbecker
2021-10-29 14:21         ` Theo de Raadt
2021-10-29 14:33           ` rsbecker
2021-10-29 14:44             ` Alejandro Colomar (man-pages) [this message]
2021-10-29 15:00               ` rsbecker
2021-10-29 14:53       ` Zack Weinberg
2022-09-27 19:19         ` readpassphrase(3) in glibc, and agetpass() (Was: Is getpass(3) really obsolete?) Alejandro Colomar
2022-09-27 19:33           ` Alex Colomar
2022-09-27 20:30           ` Sam James
2022-09-27 20:52           ` readpassphrase(3) in glibc, and agetpass() Junio C Hamano
2021-10-29 15:27   ` [PATCH] getpass.3: SYNOPSIS: Mark getpass() as [[deprecated]] Alejandro Colomar
2021-10-29 20:27   ` Is getpass(3) really obsolete? Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=326e75f9-f732-a7a8-22dc-5fc304601b39@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=deraadt@openbsd.org \
    --cc=git@vger.kernel.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=rsbecker@nexbridge.com \
    --cc=tech@openbsd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.