From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) by sourceware.org (Postfix) with ESMTPS id 377833858416 for ; Fri, 29 Oct 2021 20:27:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 377833858416 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=peff.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=peff.net Received: (qmail 23713 invoked by uid 109); 29 Oct 2021 20:27:02 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Fri, 29 Oct 2021 20:27:02 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 22572 invoked by uid 111); 29 Oct 2021 20:27:02 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Fri, 29 Oct 2021 16:27:02 -0400 Authentication-Results: peff.net; auth=none Date: Fri, 29 Oct 2021 16:27:01 -0400 From: Jeff King To: "Alejandro Colomar (man-pages)" Cc: Libc-alpha , linux-man , git@vger.kernel.org, "tech@openbsd.org" Subject: Re: Is getpass(3) really obsolete? Message-ID: References: <73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <73ac38a2-c287-4cc1-4e9c-0f9766ac4c0c@gmail.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 20:27:04 -0000 On Fri, Oct 29, 2021 at 01:28:56PM +0200, Alejandro Colomar (man-pages) wrote: > > As a real example, git(1) uses getpass(3). > > 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 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 Signed-off-by: Junio C Hamano