public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: Zack Weinberg <zack@owlfolio.org>,
	 Theo de Raadt <deraadt@openbsd.org>,
	rsbecker@nexbridge.com,  'linux-man' <linux-man@vger.kernel.org>,
	tech@openbsd.org,  Florian Weimer <libc-alpha@sourceware.org>
Subject: Re: readpassphrase(3) in glibc, and agetpass()
Date: Tue, 27 Sep 2022 13:52:02 -0700	[thread overview]
Message-ID: <xmqqedvw35hp.fsf@gitster.g> (raw)
In-Reply-To: <c8287618-30c4-f14b-8ad7-898fee99d944@gmail.com> (Alejandro Colomar's message of "Tue, 27 Sep 2022 21:19:06 +0200")

Alejandro Colomar <alx.manpages@gmail.com> writes:

> 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.
> ...
> 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.
>
> I chose a predefined buffer size to not have to pass a buffer size all
> the time, which could be error-prone.  I also allocated the buffer
> internally, to make it easier to replace getpass(3).  It may be
> desirable to use existing buffers, and pass them through a pointer,
> but for shadow-utils, it was simpler to keep the getpass(3) API.
>
> I don't know what was the practice with PASS_MAX regarding the NUL
> byte, but to avoid creating a buffer of a power of two plus one, I
> decided that the NUL byte would be within PASS_MAX.  Another solution
> would be to declare PASS_MAX to be something like BUFSIZ-1, and then
> use PASS_MAX+1, but I opted for simplicity.

I understand that in an old thread last fall we were CC'ed only
because we are one of the users of getpass(3), but could you take us
out of the CC list, please?  We'd migrate, if getpass() starts being
unusable for us, away from it and choose an alternative, but until
then git@vger.kernel.org is a good place to discuss this.

Thanks.

  parent reply	other threads:[~2022-09-27 20:52 UTC|newest]

Thread overview: 24+ 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)
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 21:00             ` Zack Weinberg
2022-09-27 22:41               ` Alejandro Colomar
2022-09-27 20:52           ` Junio C Hamano [this message]
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=xmqqedvw35hp.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=alx.manpages@gmail.com \
    --cc=deraadt@openbsd.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=rsbecker@nexbridge.com \
    --cc=tech@openbsd.org \
    --cc=zack@owlfolio.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).