Re: Test "t0300-credentials" is failing on Arch/Artix: asks to enter the Username/Password in an infinite loop

From: Jeff King <peff@peff.net>
Date: Mar 6, 2026, 04:38 UTC
Message-ID: <20260306043821.GA3465674@coredump.intra.peff.net>
In-Reply-To: <CAAaskFC0WETe7NaEfznW-h53Huee2sLLAQYWBA3moLpeULhtcA@mail.gmail.com>

On Fri, Mar 06, 2026 at 05:14:12AM +0300, Ivan Ivanov wrote:

Show 11 quoted lines

> Brian, thank you very much for checking my logs: indeed, unfortunately
> my system is Arch-based so we can't compare it directly with
> Debian/rules. Thank you for an idea about /dev/shm , although I would
> like to clarify that while it *might* be what is failing this
> particular test - the causes of failure at .out files are different as
> we could see by the prior 0300/0301/0302 and some future tests (could
> share more logs if needed). But the external appearance of these
> errors (Username/Password prompts) is similar to a user and that may
> indicate some common pattern between the problems, i.e. maybe there is
> some extra shell precaution needed on some systems (although I'm a bit
> puzzled why my distro's packager seemingly didn't have such an issue).

The inability to exec scripts in the test directory is the cause of all of the username/password prompts. What's supposed to happen is:

  1. The test script creates a script called "askpass" in the temporary
     test directory, and sets its executable bit. That script just
     returns a dummy response on its stdout.

  2. It then sets the GIT_ASKPASS variable to point to that askpass
     script.

  3. When Git needs a username/password, it tries (and this is in the
     git_prompt() function prompt.c):

       a. It runs the askpass program specified by $GIT_ASKPASS.

       b. If that doesn't return a password, it prompts on the terminal
	  using either getpass() or by opening /dev/tty directly
	  (depending on your platform).

Since we've set $GIT_ASKPASS, we expect it to stop at 3a, returning that value.

But on your system, running askpass doesn't work (I agree with brian's guess that it is probably because /dev/shm is mounted with noexec). And so we jump to 3b, prompting on the terminal. If you just hit enter, then it will not get the expected value; while it may keep running, it's not going to work. If you manually typed the same response there that askpass would have provided, the test would probably succeed.

But of course that's silly. The right solution is to use a temporary directory that allows execution of scripts. And I would expect there to be a ton of other test failures, too, as many of the tests write helper scripts and such.

The culprit is the use of --root=/dev/shm here in the package config:

  https://gitlab.archlinux.org/archlinux/packaging/packages/git/-/blob/main/PKGBUILD?ref_type=heads#L71

It's reasonable to point it at a RAM disk (Git's test suite does a lot of file I/O that gets thrown away, so running on a RAM disk can be much faster). But it has to be a fully capable filesystem, not one mounted with noexec. You might want to alert the package maintainer.

-Peff

PS There's one other related tidbit I noticed. These days we have a
   $GIT_TERMINAL_PROMPT variable that tells Git not to access the
   terminal at all. If that were set to "0" then the broken tests would
   not prompt you at all. They'd still be _broken_, because askpass
   would not give the result they expected, but at least they wouldn't
   spam your terminal with prompts.

   It might be worth putting GIT_TERMINAL_PROMPT=0 in test-lib.sh, just
   to prevent accidental breakage from becoming too annoying. We didn't
   do it when t0300 and friends were written because GIT_TERMINAL_PROMPT
   didn't exist back then.