iTerm2 Secretive excessive notifications

[Mircea Staicu]

I've setup Secretive as per instructions, added my public keys to Github and enabled commit signing. There's one problem though, or at least I think it is a problem.

The moment I initialise a git project locally and I add a remote to that project, every command that I issue in my terminal emulation to my shell, be it a simple ls -al or a git command, or even clearing the terminal buffer, triggers a notification from Secretive.

Is this behavior expected?
Does this mean that there are processes that randomly have access to the private key store in the secure enclave?

❯ git remote -v

This doesn't trigger the below notification

❯ git remote -v
or	[e-mail]:stuff/dotfiles.git (fetch)
or	[e-mail]:stuff/dotfiles.git (push)

This does trigger the above notification

Environment:

macOS 14.3 (23D56)

❯ cat ~/.gitconfig
[user]
    signingkey = /Users/dodo/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/124.pub
[gpg]
    format = ssh
[commit]
    gpgsign = true

Debug

❯ ssh -tv [e-mail]
OpenSSH_9.4p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/dodo/.ssh/config
debug1: /Users/dodo/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to github.com port 22.
debug1: Connection established.
debug1: identity file /Users/dodo/.ssh/id_rsa type -1
debug1: identity file /Users/dodo/.ssh/id_rsa-cert type -1
debug1: identity file /Users/dodo/.ssh/id_ecdsa type -1
debug1: identity file /Users/dodo/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/dodo/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/dodo/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/dodo/.ssh/id_ed25519 type -1
debug1: identity file /Users/dodo/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/dodo/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/dodo/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/dodo/.ssh/id_xmss type -1
debug1: identity file /Users/dodo/.ssh/id_xmss-cert type -1
debug1: identity file /Users/dodo/.ssh/id_dsa type -1
debug1: identity file /Users/dodo/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.4
debug1: Remote protocol version 2.0, remote software version babeld-57ca1323
debug1: compat_banner: no match: babeld-57ca1323
debug1: Authenticating to github.com:22 as 'git'
debug1: load_hostkeys: fopen /Users/dodo/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [e-mail] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [e-mail] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
debug1: load_hostkeys: fopen /Users/dodo/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'github.com' is known and matches the ED25519 host key.
debug1: Found key in /Users/dodo/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: ecdsa-sha2-nistp256 ECDSA SHA256:frB6XFoPD0DXpGfAxoLnr90YemqvTGgGGeqq4Wx/R4g agent
debug1: Will attempt key: /Users/dodo/.ssh/id_rsa
debug1: Will attempt key: /Users/dodo/.ssh/id_ecdsa
debug1: Will attempt key: /Users/dodo/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/dodo/.ssh/id_ed25519
debug1: Will attempt key: /Users/dodo/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/dodo/.ssh/id_xmss
debug1: Will attempt key: /Users/dodo/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: ecdsa-sha2-nistp256 ECDSA SHA256:frB6XFoPD0DXpGfAxoLnr90YemqvTGgGGeqq4Wx/R4g agent
debug1: Server accepts key: ecdsa-sha2-nistp256 ECDSA SHA256:frB6XFoPD0DXpGfAxoLnr90YemqvTGgGGeqq4Wx/R4g agent
Authenticated to github.com ([140.82.121.4]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: client_input_global_request: rtype [e-mail] want_reply 0
debug1: client_input_hostkeys: searching /Users/dodo/.ssh/known_hosts for github.com / (none)
debug1: client_input_hostkeys: searching /Users/dodo/.ssh/known_hosts2 for github.com / (none)
debug1: client_input_hostkeys: hostkeys file /Users/dodo/.ssh/known_hosts2 does not exist
debug1: client_input_hostkeys: no new or deprecated keys from server
debug1: Sending environment.
debug1: channel 0: setting env LC_TERMINAL_VERSION = "3.4.23"
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: channel 0: setting env LC_TERMINAL = "iTerm2"
debug1: pledge: fork
PTY allocation request failed on channel 0

Is this similar to my issue? #400 #398 #389

[Mircea Staicu]

Weirdly, I've switched to Terminal.app to see if I can get a better understanding of this. It seems that the application top bar gives more info on what processes run during the TTY session

This is what happens when you clear the screen, nothing

This is what happens when you send an interrupt signal (SIGINT) to zsh, it runs ssh

Seems that even when doing a ls -a triggers a ssh process to run, when inside a git repository that has a ssh origin

Does this mean that this is the expected behavior?

[Rishav Kundu]

This is very likely something specific to your shell setup / prompt, which I’m guessing is pure from the screenshot.

pure has a feature called PURE_GIT_PULL which checks if the upstream branch is dirty, which would necessarily require a git remote operation (thereby invoking Secretive). Do you have that enabled by any chance?

[Max Goedjen]

@xrisk that was also my first reaction here – I'd suspect it's your shell prompt, not the terminal itself. I'd be curious to see if you can reproduce this in Terminal.app with the same shell setup.

[Mircea Staicu]

Sorry for the delay, it seems that setting PURE_GIT_PULL=0 does the trick, it no longer checks if the current Git remote has been updated, thus not invoking Secretive. Added it to my .zshenv and all works now. TIL!