gnome-keyring in VM

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Currently gnome-keyring (if installed) is started in every VM,
providing, among other things, SSH agent. There is no sane way to
disable it for the user[2].

Since the original reason why it is started this way is not true for a
long time, I think about disabling it[1]. The (side?) effect will be - no
longer gnome-keyring working as SSH agent, instead standard ssh-agent
will be pointed by SSH_AUTH_SOCK variable. For some this may be a
feature (as gnome-keyring do not support EC for example), but some may
see this as a bug - no longer keys loaded automatically with a nice GUI
prompt for a password (if set).

It is still possible to enable it back for example by adding it to
`~/.profile`. The tricky part is it can't be started just from
`/etc/xdg/autostart`, because it isn't possible to set $SSH_AUTH_SOCK
in shell environment from there (on real GNOME, some GNOME specific dbus
API is used for this).

So, now the questions:
1. Is this change in behavior ok?
2. If not, how to enable it by default, to make it easier to disable it
if someone want to?

[1] https://github.com/marmarek/qubes-gui-agent-linux/pull/21
[2] https://github.com/QubesOS/qubes-issues/issues/2351

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYImDTAAoJENuP0xzK19csP4EH/RR82r+omPLp8WG+4yw9e/jM
ymIVK4B11BYAo8mMXYZ8nt8Vy0amYK6SAjE8PerLkUgdMeR47/XVL90ICEvYsgst
UIbC2fXcaTaPMK4BKv8MAgzzmPdtRTgeu3OzJi8OmhNRA30b0lvKBMJuyzPuX1qw
SyNwo1xj90U+aVI5Zl8yKtYSuyLz7+WuCZ3U2fV2LJ9uzwJvx+KbmPMMboQeEnV5
Y2wWQgXvl0hnbToHRrZkMOif2TTy+E1R6+7gwHRSWJtjQzGZnYjufw/W6DtrJnVM
PPl/CJMqDgoCJcv7srmMQun3vH/6s8mKLbnHFx54ZjKpwJg87HC6+A0J3c28AIA=
=pDS4
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Tue, Nov 8, 2016 at 6:33 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> no longer keys loaded automatically with a nice GUI prompt for a password (if set).

This is not true.

OpenSSH's ssh-agent invoked with DISPLAY set and stdin not a tty will
invoke ssh-askpass with such a nice gui prompt for a password. This is
easy to accomplish if desired.

> It is still possible to enable it back for example by adding it to
> `~/.profile`. The tricky part is it can't be started just from
> `/etc/xdg/autostart`, because it isn't possible to set $SSH_AUTH_SOCK
> in shell environment from there (on real GNOME, some GNOME specific dbus
> API is used for this).

However, env vars can be made to be propagated from xdg-autostart via
/tmp/qubes-session-env[.tmp] with minimal changes to the startup
scripts. See https://groups.google.com/forum/#!topic/qubes-devel/lRwuYIF_hWE

> So, now the questions:
> 1. Is this change in behavior ok?

I have been running with essentially the change you describe for a few
weeks and have observed no regressions.

+1 for changing it

> 2. If not, how to enable it by default, to make it easier to disable it
> if someone want to?

Starting it via xdg-autostart and propagating env vars as described
above would accomplish this, but regardless I believe openssh's
ssh-agent is preferable to gnome-keychain.

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> Hi,
>
> Currently gnome-keyring (if installed) is started in every VM,
> providing, among other things, SSH agent. There is no sane way to
> disable it for the user[2].
>
> Since the original reason why it is started this way is not true for a
> long time, I think about disabling it[1]. The (side?) effect will be - no
> longer gnome-keyring working as SSH agent, instead standard ssh-agent
> will be pointed by SSH_AUTH_SOCK variable. For some this may be a
> feature (as gnome-keyring do not support EC for example), but some may
> see this as a bug - no longer keys loaded automatically with a nice GUI
> prompt for a password (if set).

FWIW I have disabled it manually for a long time. But I'm a bad
reference for user-friendly defaults.

> It is still possible to enable it back for example by adding it to
> `~/.profile`. The tricky part is it can't be started just from
> `/etc/xdg/autostart`, because it isn't possible to set $SSH_AUTH_SOCK
> in shell environment from there (on real GNOME, some GNOME specific dbus
> API is used for this).
>
> So, now the questions:
> 1. Is this change in behavior ok?
> 2. If not, how to enable it by default, to make it easier to disable it
> if someone want to?

I think it would be easy to check for /etc/qubes/no-gnome-keyring before
starting it. Or maybe use Qubes "services" (but IIRC setting defaults
for them is also not easy ...).

> [1] https://github.com/marmarek/qubes-gui-agent-linux/pull/21
> [2] https://github.com/QubesOS/qubes-issues/issues/2351

-----BEGIN PGP SIGNATURE-----

iQIsBAEBCgAWBQJYImypDxxodzQyQGlwc3Vtai5kZQAKCRDkrMknimRoFp3dD/wP
iXGDmZJ5WKzYobu8lKRs3+JwCkz476bit8XeU/TNuM6V9zqXJAXQDnak4TZMdH/L
8+MnmmqccypBIPJ0WgayIXhz3u5/2IMJc4M5PaWjXDhUTkj9L+YOSVTdOE6Nm6b9
yxszp4j+4m+n4sKwrUytiRXEQJr5nWon+OAJSYnjy4gKYy79czZGO+wgys2KIJGp
8kO2UerfrUtP9jSi8t2ldsOEzOq/N4ed4e3B4b1xS/1PnmYEjldWs7BQMw7fTO9+
UMxtdzAHlUOIt2x8oExyAw5R/9T5yRBkcAidfWaHPDP8JtzWAOI66F+5YkTf5h1a
DXrzblfjieYvKrXYW/gI+lPv5rq2BLWYUAQz4NytuLFxSTbUxhebLB/EK3jqjU/y
lCU/4xXADZ1FZBZeGrt2LMnoTt9Jz7GKI9FOV+eEjMm8vDnLWRXDK6xLo0Db7qFF
lHgECC9cWOSzkh2YsqN7gtK8P+3kOkRbiOw2AlaFHOWc9Bsn+FmCWALftxVHJSwJ
5D5iu2JHIhSXTpCBsp3mcU1vsUsegxtD4RI91OzF9GYMD6E6k3euKkVzny7tQRke
RY6ID3Hr6Noa7VKSX0MpL2t9ZTVAs4XqNDGzDb5tv3ZkSr70KV/T/UAbWR6xLOmw
lT/MyAYAWotHE0E5SvvrfCPm0L1/YOs+R9wOSMFqtA==
=awcC
-----END PGP SIGNATURE-----

[Unman]

On Wed, Nov 09, 2016 at 12:33:39AM +0100, Marek Marczykowski-Górecki wrote:
> Hi,
>
> Currently gnome-keyring (if installed) is started in every VM,
> providing, among other things, SSH agent. There is no sane way to
> disable it for the user[2].
>
> Since the original reason why it is started this way is not true for a
> long time, I think about disabling it[1]. The (side?) effect will be - no
> longer gnome-keyring working as SSH agent, instead standard ssh-agent
> will be pointed by SSH_AUTH_SOCK variable. For some this may be a
> feature (as gnome-keyring do not support EC for example), but some may
> see this as a bug - no longer keys loaded automatically with a nice GUI
> prompt for a password (if set).
>
> It is still possible to enable it back for example by adding it to
> `~/.profile`. The tricky part is it can't be started just from
> `/etc/xdg/autostart`, because it isn't possible to set $SSH_AUTH_SOCK
> in shell environment from there (on real GNOME, some GNOME specific dbus
> API is used for this).
>
> So, now the questions:
> 1. Is this change in behavior ok?
> 2. If not, how to enable it by default, to make it easier to disable it
> if someone want to?
>

1. Absolutely yes. The intrusion of the keyring in to SSH is
longstanding bug. Will be good to see it gone.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Nov 08, 2016 at 07:01:26PM -0500, Jean-Philippe Ouellet wrote:
> On Tue, Nov 8, 2016 at 6:33 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com> wrote:
> > no longer keys loaded automatically with a nice GUI prompt for a password (if set).
>
> This is not true.
>
> OpenSSH's ssh-agent invoked with DISPLAY set and stdin not a tty will
> invoke ssh-askpass with such a nice gui prompt for a password. This is
> easy to accomplish if desired.

But do not load keys automatically. This isn't a big problem, just some
difference.

> > It is still possible to enable it back for example by adding it to
> > `~/.profile`. The tricky part is it can't be started just from
> > `/etc/xdg/autostart`, because it isn't possible to set $SSH_AUTH_SOCK
> > in shell environment from there (on real GNOME, some GNOME specific dbus
> > API is used for this).
>
> However, env vars can be made to be propagated from xdg-autostart via
> /tmp/qubes-session-env[.tmp] with minimal changes to the startup
> scripts. See https://groups.google.com/forum/#!topic/qubes-devel/lRwuYIF_hWE

/tmp/qubes-session-env isn't sourced second time, at least in theory
(QUBES_ENV_SOURCED=1). How could it work? In older version (Qubes 3.0?)
it was indeed sourced at each shell startup.

> > So, now the questions:
> > 1. Is this change in behavior ok?
>
> I have been running with essentially the change you describe for a few
> weeks and have observed no regressions.
>
> +1 for changing it
>
> > 2. If not, how to enable it by default, to make it easier to disable it
> > if someone want to?
>
> Starting it via xdg-autostart and propagating env vars as described
> above would accomplish this, but regardless I believe openssh's
> ssh-agent is preferable to gnome-keychain.

Ok, so given the feedback, I believe the best option is to default to
openssh's ssh-agent, then document somewhere how to enable gnome-keyring
one.

> > [1] https://github.com/marmarek/qubes-gui-agent-linux/pull/21
> > [2] https://github.com/QubesOS/qubes-issues/issues/2351

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYI7TBAAoJENuP0xzK19cs4psH/jDe7Bp9MD9El7odXGguURDR
VmcdWcdhvi/a6O4YXzjRinmJoxKKax5tEJrmJhM7yKisW+0VG1k3cOUBd4MwgZ0e
47fmLLXl5DFGlWfCWzPIau6Yy/kEtds9qG5S7o5BbiKocM6XLbLL45cRL10OCQUV
uko7KBazCrdRJuvbJJPIu5F57eAsm+OZF5YUltdhSS1xd8lORXqEdIMrT/N3NMGR
cmN6hiujOB9NzCBg66PCT/AQynJaf8gLvVF9ACRaPqFmG4f1CGrvF4ppKWNCzoCz
3j5zcg6gVOtQriVEehfyYs0pXSAgvnVpUWJrrfAecRwiV1ZmJRRPCoSyTp2QlK8=
=3HZK
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Wed, Nov 9, 2016 at 6:44 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> /tmp/qubes-session-env isn't sourced second time, at least in theory
> (QUBES_ENV_SOURCED=1). How could it work? In older version (Qubes 3.0?)
> it was indeed sourced at each shell startup.

Ah, you are correct.

I had further modified my
gui-agent-linux/appvm-scripts/usrbin/qubes-session in ways which are
not suitable for upstream. My changes introduced an obvious race
condition in which it is possible for the qubes session env to be
"made ready" (mv /tmp/qubes-session-env.tmp ...env) before things
started from xdg wrote to the env.tmp, potentially leading to vars
from xdg failing to propagate. It always worked in practice, but that
does not make it ok.

One thing to clarify is what env var propagation dependency relations
we should allow:
- Should xdg-autostart be able to somehow propagate vars to other
xdg-autostart entries? (allowing gnome-keychain -> nm-applet case)
- only xdg-autostart -> qrexec-fork-server?
- something else?

[pixel fairy]

On Tuesday, November 8, 2016 at 6:33:47 PM UTC-5, Marek Marczykowski-Górecki wrote:

Currently gnome-keyring (if installed) is started in every VM,
providing, among other things, SSH agent. There is no sane way to
disable it for the user[2].

does anyone use for anything else? qubes already provides vault vms, and split-gpg so i dont think theres anything left but could be wrong. 

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Nov 10, 2016 at 01:59:20AM -0500, Jean-Philippe Ouellet wrote:
> On Wed, Nov 9, 2016 at 6:44 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com> wrote:
> > /tmp/qubes-session-env isn't sourced second time, at least in theory
> > (QUBES_ENV_SOURCED=1). How could it work? In older version (Qubes 3.0?)
> > it was indeed sourced at each shell startup.
>
> Ah, you are correct.
>
> I had further modified my
> gui-agent-linux/appvm-scripts/usrbin/qubes-session in ways which are
> not suitable for upstream. My changes introduced an obvious race
> condition in which it is possible for the qubes session env to be
> "made ready" (mv /tmp/qubes-session-env.tmp ...env) before things
> started from xdg wrote to the env.tmp, potentially leading to vars
> from xdg failing to propagate. It always worked in practice, but that
> does not make it ok.

I'm not sure how exactly it is done on non-Qubes systems, but looking at
org.gnome.Session dbus API, it looks like the same race is there -
registering env variables is allowed only during startup phase and I see
no way to make some action to be done specifically during that phase
(other than being fast enough).

> One thing to clarify is what env var propagation dependency relations
> we should allow:
> - Should xdg-autostart be able to somehow propagate vars to other
> xdg-autostart entries? (allowing gnome-keychain -> nm-applet case)
> - only xdg-autostart -> qrexec-fork-server?
> - something else?

Given the above, and lack of generic standard (am I missing anything?),
I see two options:

1. Implement subset of org.gnome.Session dbus API somewhere, to
allow env variables being registered and propagated to
qrexec-fork-server.

2. Ignore the problem and say: if you want to set env variable globally,
do it in /etc/X11/xinit/xinitrc.d or ~/.profile.

I tend to go with the second option.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYKNmfAAoJENuP0xzK19csmwUH/3quEI7ouhYc0OLQokm3Kz5u
zO/pmD92Qz5CsVV5nkwsNL1GUaXVw+5tqdvMoExvT5aELbKBd0pB9KiOj4tpwER1
PxwMxGG5e4CShLIDho/8Kb4rx5QRf2GMawLeK2fyRQwYGYPy0xPY7w+x20dEn+Fm
vbV705ognrdl4R1h/89pYPuI2ySQYeKPwhmf/zu3rqf29vLuQhecSXENaEwJKWgl
KpgpKeiOHePZ+4+C8Pe2bSZZiNtaBYSwgdZyKRZ4bs9LhFBdQj7XQYPrYPPeMHxD
Wx14T1snBs6s1HZyyDLsPLmz+EZrgI8t4Nmj6Y1ez5c5Psmbr3FPpGk4z90Svpg=
=NF5z
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Sun, Nov 13, 2016 at 4:22 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> Given the above, and lack of generic standard (am I missing anything?),
> I see two options:
>
> 1. Implement subset of org.gnome.Session dbus API somewhere, to
> allow env variables being registered and propagated to
> qrexec-fork-server.
>
> 2. Ignore the problem and say: if you want to set env variable globally,
> do it in /etc/X11/xinit/xinitrc.d or ~/.profile.
>
> I tend to go with the second option.

Agreed.

Simpler option is better (until we have real need for otherwise, which
may never happen)