git-maintenance doesn't work with git-credential-manager & pass

nedsociety commented 9 months ago

[x] I was not able to find an open or closed issue matching what I'm seeing, including in the git-for-windows/git tracker.

Setup

Which version of microsoft/git are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.43.0.vfs.0.0
cpu: x86_64
built from commit: b7a6ed788a205fb2c0013111d277b4c9d6ab35bd
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh

Are you using Scalar or VFS for Git?

Yes (scalar)

Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Nope, it's Ubuntu 22.04 jammy.

Any other interesting things about your environment that might be related to the issue you're seeing?

$ git-credential-manager --version
2.4.1
$ pass --version
============================================
= pass: the standard unix password manager =
=                                          =
=                  v1.7.4                  =
=                                          =
=             Jason A. Donenfeld           =
=               Jason@zx2c4.com            =
=                                          =
=      http://www.passwordstore.org/       =
============================================

Details

What commands did you run to trigger this issue? If you can provide a Minimal, Complete, and Verifiable example this will help us understand the issue.

$ sudo apt install pass

# Follow https://github.com/git-ecosystem/git-credential-manager/blob/release/docs/install.md#install-2

$ git config --global credential.credentialStore gpg # make gcm use pass as its credstore

# try cloning a private repo

$ pass list

# confirm that the auth data is listed correctly

$ scalar register path/to/private/repo
$ systemctl --user start git-maintenance@hourly.service || systemctl --user status git-maintenance@hourly.service

What did you expect to occur after running these commands?

The command succeeds.

What actually happened instead?

@ systemctl --user daemon-reload && systemctl --user start git-maintenance@hourly.service; systemctl --user status git-maintenance@hourly.service
Job for git-maintenance@hourly.service failed because the control process exited with error code.
See "systemctl --user status git-maintenance@hourly.service" and "journalctl --user -xeu git-maintenance@hourly.service" for details.
× git-maintenance@hourly.service - Optimize Git repositories data
     Loaded: loaded (/home/ned/.config/systemd/user/git-maintenance@.service; static)
     Active: failed (Result: exit-code) since Wed 2024-02-07 17:32:01 KST; 8ms ago
TriggeredBy: ● git-maintenance@hourly.timer
    Process: 4051421 ExecStart=/usr/local/lib/git-core/git --exec-path=/usr/local/lib/git-core -c credential.interactive=false -c core.askPass=true for-each-repo --config=maintenance.repo maintenance run >
   Main PID: 4051421 (code=exited, status=1/FAILURE)
        CPU: 31ms

Feb 07 17:32:01 xxx systemd[1292]: Starting Optimize Git repositories data...
Feb 07 17:32:01 xxx git[4051425]: fatal: unable to get password from user
Feb 07 17:32:01 xxx git[4051422]: error: failed to prefetch remotes
Feb 07 17:32:01 xxx git[4051422]: error: task 'prefetch' failed
Feb 07 17:32:01 xxx systemd[1292]: git-maintenance@hourly.service: Main process exited, code=exited, status=1/FAILURE
Feb 07 17:32:01 xxx systemd[1292]: git-maintenance@hourly.service: Failed with result 'exit-code'.
Feb 07 17:32:01 xxx systemd[1292]: Failed to start Optimize Git repositories data.

If the problem was occurring with a specific repository, can you specify the repository?

I believe this is repo-agnostic

Additional info

Similar to #604 I've found that the problem resolves when I try to comment out two lines from ~/.config/systemd/user/git-maintenance@.service:

# This file was created and is maintained by Git.
# Any edits made in this file might be replaced in the future
# by a Git command.

[Unit]
Description=Optimize Git repositories data

[Service]
Type=oneshot
ExecStart="/usr/local/lib/git-core/git" --exec-path="/usr/local/lib/git-core" -c credential.interactive=false -c core.askPass=true  for-each-repo --config=maintenance.repo maintenance run --schedule=%i
LockPersonality=yes
# MemoryDenyWriteExecute=yes              #  <----------
NoNewPrivileges=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_VSOCK
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
# SystemCallFilter=@system-service               #  <----------

The second comment-out enables pass to work. Otherwise changing ExecStart to bash -c 'pass list' shows as if pass has an empty password store. I have no clue what syscalls other than @system-service is needed for pass to work.
The first one enables git-credential-manager to run. Otherwise changing ExecStart to bash -c '(echo ...) | git-credential-manager get' segfaults. For this one though I understand why MemoryDenyWriteExecute is needed since gcm is a dotnet application which may use JIT.

I didn't check if the upstream git has the same problem (it probably has), but since git-maintenance is probably mostly used by scalar I felt this issue is to be reported here.

X-post (gcm): https://github.com/git-ecosystem/git-credential-manager/issues/1521

derrickstolee commented 9 months ago

Since this issue happens when using the systemd scheduler, could you run git maintenance start --scheduler=crontab to check if the problem repeats when using cron? If that works, then it would be a valuable workaround.

nedsociety commented 9 months ago

Since this issue happens when using the systemd scheduler, could you run git maintenance start --scheduler=crontab to check if the problem repeats when using cron? If that works, then it would be a valuable workaround.

I currently don't have access to the machine for a while, may be able to report in 5~6 days. Though in terms of workaround I'm not sure if switching to crond is a better way against just removing those two lines.

nedsociety commented 9 months ago

git maintenance start --scheduler=crontab returned immediately with no output (exitcode was zero). Nothing had been registered to any of /etc/crontab, /etc/cron.*/*.

EDIT: Okay /var/spool/cron/crontabs has the configuration. I'm not sure how to trigger them manually though. I also noted that the systemd timers were gone.

nedsociety commented 9 months ago

Update: the cron scheduler succeeded for both hourly and daily runs :+1:

microsoft / git