public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
Cc: Libc-alpha <libc-alpha@sourceware.org>,
	linux-man <linux-man@vger.kernel.org>,
	git@vger.kernel.org, "tech@openbsd.org" <tech@openbsd.org>
Subject: Re: Is getpass(3) really obsolete?
Date: Fri, 29 Oct 2021 16:27:01 -0400	[thread overview]
Message-ID: <YXxZFaqHq9/aEQCO@coredump.intra.peff.net> (raw)
In-Reply-To: <73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com>

On Fri, Oct 29, 2021 at 01:28:56PM +0200, Alejandro Colomar (man-pages) wrote:

> > As a real example, git(1) uses getpass(3).
> > <https://github.com/git/git/blob/master/compat/terminal.c>

Sort of. It is the compile-time fallback of last resort. Most builds
would use either termios with /dev/tty or a Windows-native equivalent.

You can see all the reasons we stopped using getpass() in the commit
below.

-- >8 --
commit 21aeafceda2382d26bfa73a98ba45a937d65d77a
Author: Jeff King <peff@peff.net>
Date:   Sat Dec 10 05:41:01 2011 -0500

    add generic terminal prompt function
    
    When we need to prompt the user for input interactively, we
    want to access their terminal directly. We can't rely on
    stdio because it may be connected to pipes or files, rather
    than the terminal. Instead, we use "getpass()", because it
    abstracts the idea of prompting and reading from the
    terminal.  However, it has some problems:
    
      1. It never echoes the typed characters, which makes it OK
         for passwords but annoying for other input (like usernames).
    
      2. Some implementations of getpass() have an extremely
         small input buffer (e.g., Solaris 8 is reported to
         support only 8 characters).
    
      3. Some implementations of getpass() will fall back to
         reading from stdin (e.g., glibc). We explicitly don't
         want this, because our stdin may be connected to a pipe
         speaking a particular protocol, and reading will
         disrupt the protocol flow (e.g., the remote-curl
         helper).
    
      4. Some implementations of getpass() turn off signals, so
         that hitting "^C" on the terminal does not break out of
         the password prompt. This can be a mild annoyance.
    
    Instead, let's provide an abstract "git_terminal_prompt"
    function that addresses these concerns. This patch includes
    an implementation based on /dev/tty, enabled by setting
    HAVE_DEV_TTY. The fallback is to use getpass() as before.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

      parent reply	other threads:[~2021-10-29 20:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29 11:15 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           ` 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   ` Jeff King [this message]

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=YXxZFaqHq9/aEQCO@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=alx.manpages@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --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 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).