Unable to disable autostart applications in fedora23

[jpouellet]

Qubes OS version (e.g., R3.1):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora-23

---

General notes:

I am trying to use the actual OpenSSH ssh-agent instead of gnome-keychain because it does not support ed25519 keys, and I use them.

According to the Qubes autostart readme and the xdg autostart spec, I should be able to set Hidden=true in /etc/qubes/autostart/whatever.d/xx_asdf.conf to prevent whatever from starting, however trying to do this for gnome-keyring-ssh.desktop does not prevent ghome-keyring from starting.

Steps to reproduce the behavior:

fedora-23$ cat <<EOF | sudo tee /etc/qubes/autostart/gnome-keyring-ssh.desktop.d/50_user.conf
[Desktop Entry]
Hidden=true

other-vm$ ls -al /etc/qubes/autostart/gnome-keyring-ssh.desktop.d
total 16
drwxr-xr-x  2 root root 4096 Oct  1 02:50 .
drwxr-xr-x 25 root root 4096 Aug  8 08:18 ..
-rw-r--r--  1 root root   42 Aug  7 23:39 30_qubes.conf
-rw-r--r--  1 root root   28 Oct  1 01:20 50_user.conf
other-vm$ cat 50_user.conf 
[Desktop Entry]
Hidden=true

Expected behavior:

ssh-agent should either not be started, or possibly be started from xinitrc-common due to:

if [ -z "$SSH_AGENT" ] && [ -z "$SSH_AGENT_PID" ] && [ -x /usr/bin/ssh-agent ]; then

I expect something possibly like this:

other-vm$ env | grep -i ssh
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass

Actual behavior:

Instead, I get the same thing as without any changes:

other-vm$ env | grep -i ssh
SSH_AGENT_PID=695
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass

This path is the unix domain socket set up by gnome-keychain. The auth sock path used by openssh ssh-agent (/usr/bin/ssh-agent) is something like:

SSH_AUTH_SOCK=/tmp/ssh-Hrano1NivB8R/agent.5361

[jpouellet]

Also, using OnlyShowIn= (empty value) instead of Hidden=true appears to have the same effect.

[marmarek]

Take a look here: https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/appvm-scripts/usrbin/qubes-session#L43-L45

It is done this way exactly to make SSH_AUTH_SOCK (and others) available in environment. So, for now the only way is to start ssh-agent later (manually?)...
Any better idea for propagation environment variables from autostart applications?

[jpouellet]

Ah yes. I was really confused as to how the env vars were being propagated.

You may want to consider propagating env vars from autostart scripts in a way like this jpouellet/qubes-gui-agent-linux@e0d8bf9 (untested - just to illustrate the idea) where the autostart.desktop Exec would actually point to a wrapper which extracts the desired var from the agent's stdout and qubes-session-export's it.

Although, upon looking into it I do not see why nm-applet actually needs gnome-keychain in qubes. It appears to only be used when the user wishes to only save a network credential for their own user (as opposed to system-wide, and having root put it in /etc/NetworkManager/system-connections), but in the case of a net-vm with passwordless sudo, these appear to me to have no meaningful difference at all. Am I missing something?

[marmarek]

Automated announcement from builder-github

The package qubes-gui-vm-3.2.8-1.fc23 has been pushed to the r3.2 testing repository for the Fedora fc23 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.2-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-gui-vm-3.2.8-1.fc24 has been pushed to the r3.2 testing repository for the Fedora fc24 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.2-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-gui-agent_3.2.8+deb8u1 has been pushed to the r3.2 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-gui-agent_3.2.8+deb9u1 has been pushed to the r3.2 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-gui-agent_3.2.8+deb8u1 has been pushed to the r3.2 stable repository for the Debian jessie template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-gui-vm-3.2.9-1.fc23 has been pushed to the r3.2 stable repository for the Fedora fc23 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-gui-vm-3.2.9-1.fc24 has been pushed to the r3.2 stable repository for the Fedora fc24 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-gui-agent_3.2.8+deb9u1 has been pushed to the r3.2 stable repository for the Debian stretch template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Related discussion: https://groups.google.com/d/msgid/qubes-devel/20161108233339.GS22572%40mail-itl

[ptitdoc]

Gnome keyring is apparently still installed and/or a dependency of the qubes-agent (at least in archlinux). Can we also clean this dependency up along with the qubes autostart dropin ?

Or should we keep it as a "default ssh agent" program until a qubes specific agent is used (such as a split ssh agent).

If the answer is "keep it for now", we should at least add a profile.d file with the following line so that the users benefits from the ssh agent that is installed and running:
export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

[jpouellet]

Idk about arch specifics, but can confirm that things are working fine without gnome-keyring on fedora templates (without no-ed25519 restriction for SSH, and without any collateral regressions observed over the past few months).

I'd say proceed with removing it as a dependency.

[jpouellet]

xref env var propagation: https://groups.google.com/d/topic/qubes-devel/gXj5KWSkPIM/discussion