You are not logged in.

#1 2016-01-28 08:52:43

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,789
Website

initializing gnome-keyring-daemon in autostart

History: Crunchbang Waldorf does this in openbox/autostart:

eval $(gnome-keyring-daemon -s --components=pkcs11,secrets,ssh,gpg) &

but recently Head_on_a_Stick has pointed out that the Arch Wiki advocates exporting SSH_AUTH_SOCK. (I seem to remember reading elsewhere that 'export GPG_AGENT_INFO' was also needed for some purposes.)

On my Waldorf system SSH_AUTH_SOCK is already being set somewhere, without having to export it from autostart, but it does seem to be necessary on Debian Jessie systems. (The path held in that variable is totally different too.)

Another issue: that ampersand at the end of the line. Surely, if the command is forked into a subshell then the eval command will only set the variables in the subshell, not its parent? Exporting from that subshell would also fail to affect any other children of the parent shell, right? A bit of testing seems to confirm it:

john@raffles4:~$ output='var="some value"'
john@raffles4:~$ echo "$output"
var="some value"
john@raffles4:~$ echo "$var"

john@raffles4:~$ eval $output
john@raffles4:~$ echo "$var"
some value
john@raffles4:~$ unset var
john@raffles4:~$ echo "$var"

john@raffles4:~$ eval $output & # eval is forked
[1] 19204
[1]+  Done                    eval $output
john@raffles4:~$ echo "$var"

john@raffles4:~$ # var has not been set

That Arch page also suggests that LightDM will do all the starting of gnome-keyring-daemon that's needed, but htop shows this command

/usr/bin/gnome-keyring-daemon --daemonize --login

is running, and the Gnome Wiki says

When run with the --login option, gnome-keyring-daemon does not fully initialize. It expects to be initialized later by calling another gnome-keyring-daemon with the --start option.

That call would come from the files in /etc/xdg/autostart

john@bunsen:~$ grep -r 'Exec=/usr/bin/gnome-keyring-daemon' /etc/xdg/autostart/
/etc/xdg/autostart/gnome-keyring-secrets.desktop:Exec=/usr/bin/gnome-keyring-daemon --start --components=secrets
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop:Exec=/usr/bin/gnome-keyring-daemon --start --components=pkcs11
/etc/xdg/autostart/gnome-keyring-gpg.desktop:Exec=/usr/bin/gnome-keyring-daemon --start --components=gpg
/etc/xdg/autostart/gnome-keyring-ssh.desktop:Exec=/usr/bin/gnome-keyring-daemon --start --components=ssh

but they are all restricted to GNOME, Unity or MATE:

john@bunsen:~$ grep -r 'Show' /etc/xdg/autostart/gnome-keyring-*
/etc/xdg/autostart/gnome-keyring-gpg.desktop:OnlyShowIn=GNOME;Unity;MATE;
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop:OnlyShowIn=GNOME;Unity;MATE;
/etc/xdg/autostart/gnome-keyring-secrets.desktop:OnlyShowIn=GNOME;Unity;MATE;
/etc/xdg/autostart/gnome-keyring-ssh.desktop:OnlyShowIn=GNOME;Unity;MATE;

so we need to do it ourselves in openbox/autostart after all.

At the moment I'm thinking of this:

## SESSION CONFIGURATION

## GNOME PolicyKit and Keyring
eval $(gnome-keyring-daemon -s --components=pkcs11,secrets,ssh,gpg)
export SSH_AUTH_SOCK
export GPG_AGENT_INFO

## for authentication
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &

## SESSION CONFIGURATION END

but would welcome any comments or suggestions as to better ways of handling this.

There are still mysterious aspects, for example the polkit-gnome-authentication-agent-1 command must have the ampersand! Without it I got a black screen at login. Also 'echo $SSH_AUTH_SOCK' in a terminal sometimes comes up empty. I'm suspecting VirtualBox might be complicating things here...


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#2 2016-01-28 12:53:42

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

1. gnome-keyring

I don't use it myself.
I have even removed package 'gnome-keyring' because for me it is one of those processes sitting there and doing nothing useful.
I use gnupg (in emacs) to encrypt sensitive information

2. SSH_AUTH_SOCKET

2.1. Using a DM

Most DM's (lightdm included) set SSH_AUTH_SOCKET

It can be disabled in file /etc/X11/Xsession.options

When it is enabled, /etc/X11/Xsession.d/90x11-common_ssh-agent is handled (by modifying STARTUP)

After handling all options, STARTUP is exec'ed. (by lightdm?)

In my system  STARTUP=usr/bin/ssh-agent /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/me/.gnupg/gpg-agent-info-medion /usr/bin/dbus-launch --exit-with-session x-session-manager
As you can see I have gpg-agent enabled.
Process lightdm then spawns the window-manager (openbox)
Process openbox spawns ssh-agent, obtains SSH_AUTH_SOCKET from its child and sets and exports the variable.
Idem for gpg-agent.
From there on all our user processes (terminal-emulator, browser, ...) are children of openbox and inherit is environment variables.

2.2 Not using a DM - using startup in stead

2.2.1 Not using $HOME/.xinitrc

startup behaves just like the DM case.

2.2.2. Using $HOME/.xinitrc

In that case YOU have to setup and export environment variables for SSH and GNUPG, by editing $HOME/.xinitrc.
You start openbox as a window manager for instance.
All your user processes are children of openbox and inherit its environment setting.

Summary:

I don't think running in a VM alters the settings of the variables in question.
Of course I might be wrong here smile After all running an OS in A VM is a complex concept and its implementation might have bugs.
It is running a DM or not that determines if the variables in question are set for your processes.

AFTER THOUGHT:

Of course, the above does not apply to sessions you open on a VC.
Pehaps that is where you saw the variables not been set.

EDITED:
1. Using startup distinction between using/not using ĤOME/.xinitrc

xaos52

Offline

#3 2016-01-28 18:05:23

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: initializing gnome-keyring-daemon in autostart

What do we actually need GNOME-keyring for?

I never install it in my systems unless I want to use Evolution.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#4 2016-01-28 22:04:46

hhh
Meep!
Registered: 2015-09-17
Posts: 9,587
Website

Re: initializing gnome-keyring-daemon in autostart

Head_on_a_Stick wrote:

What do we actually need GNOME-keyring for?

I thought this had been raised before and I found that another package depended on it. I'll look into it again and post back.

-edit- we should test this further (rc2 test ISO output)...

user@debian:~$ sudo apt purge gnome-keyring
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  gnome-keyring*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 4,675 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 91321 files and directories currently installed.)
Removing gnome-keyring (3.14.0-1+b1) ...
Purging configuration files for gnome-keyring (3.14.0-1+b1) ...
Processing triggers for libglib2.0-0:i386 (2.42.1-1) ...
user@debian:~$ sudo apt-get --purge autoremove
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  gcr* libgck-1-0* libgcr-3-common* libgcr-base-3-1* libgcr-ui-3-1* p11-kit*
  p11-kit-modules*
0 upgraded, 0 newly installed, 7 to remove and 0 not upgraded.
After this operation, 3,791 kB disk space will be freed.
Do you want to continue? [Y/n]

Offline

#5 2016-01-29 04:43:38

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,789
Website

Re: initializing gnome-keyring-daemon in autostart

Why gnome-keyring?
Philip thought it was important enough to put in #! Of course these things change, and technologies get superseded...
As @hhh says, it has come up in the past - I think it might be useful for some users when accessing wireless networks. Of course if another package had depended directly on it we wouldn't have been necessary to put it in the install list.
I guess it's a convenience for some users, and one of those things that can be a pain to set up manually for new users.

(I use it myself to hold my webserver's password, so an "upload" script can run without having to prompt me for a password or store it in plain text somewhere. A bit of extra security, but that's for a separate post some day...)

As to "LightDM does it all for you", as per the Arch Wiki and @xaos52, I'm afraid in the case of an openbox setup like BL it doesn't seem to be that simple. In fact you can test it easily: comment out all the gnome-keyring stuff in openbox/autostart, log out/in and run 'echo $SSH_AUTH_SOCKET' in a terminal. (EDIT: I've been subsequently getting unpredictable results with this. No longer quite so sure.)

I don't want to sound too arrogant here, but it's all in my previous post, if you care to read it and check out the links. LightDM would do everything if it was in a GNOME/Unity/MATE session, but for us it only does the first part of starting up the daemon - we have to run what would have been done by the .desktop files in /etc/xdg/autostart.
Run

/usr/lib/i386-linux-gnu/openbox-xdg-autostart OPENBOX --list
#or
/usr/lib/x86_64-linux-gnu/openbox-xdg-autostart OPENBOX --list

to see what openbox is starting. (The OPENBOX option, in fact, appears to do nothing, but that's what is being sent.)

xaos52 wrote:

Process lightdm then spawns the window-manager (openbox)

This is a little mysterious. /usr/share/xsessions/lightdm-xsession.desktop contains the line 'Exec=default'. This is the session which is chosen by default (openbox.desktop runs 'Exec=/usr/bin/openbox-session' directly, but they both work.) Unfortunately 'default' is not in $PATH - it must be something comprehensible only to LightDM. Is this a standards-compliant .desktop file? Anyway, either way the end result is /usr/bin/openbox-session. This is a short script which loads ~/.config/openbox/environment, then

exec /usr/bin/openbox --startup "/usr/lib/i386-linux-gnu/openbox-autostart OPENBOX" "$@"

(or the amd64 version) So the remaining window for environment variables to enter the session would be if LightDM passed something in "$@", and if openbox --startup handled them.

xaos52 wrote:

Process openbox spawns ssh-agent, obtains SSH_AUTH_SOCKET from its child and sets and exports the variable.

Unfortunately I have been unable to confirm this. In my tests, the variable is not set unless the gnome-keyring-daemon is initialized from openbox/autostart with a --start option. (see https://wiki.gnome.org/Projects/GnomeKe … ningDaemon I linked to above.)

About "Not using a DM": IMO 'startx' without an .xinitrc file is the way to go. The same /etc/X11/Xsession should be invoked as via LightDM, and the same daemons started. (That work is skipped if ~/.xinitrc exists.) And the same work remains for us in initializing gnome-keyring-daemon. I spent a couple of weeks going into what startx does, back i the #! forums in 2012: http://crunchbang.org/forums/viewtopic.php?id=20442

I did all this testing in an X session, not a virtual terminal.

@xaos52, or anyone, can you confirm whether SSH_AUTH_SOCKET is being set or not on a standard BunsenLabs system?

EDIT
Testing on real hardware as opposed to a VM is time-consuming with multiple reboots, but just now I had SSH_AUTH_SOCKET set without the autostart lines. roll (GPG_AGENT_INFO was not set.) Other times, I'm certain that variable was not being set. I'd love to know what's going on here.

Maybe, as a compromise, we could have the lines I proposed in openbox/autostart, but commented out, and wait to see if users have problems? Meanwhile, yet more research, testing...
...anyway, to start off, I'll install seahorse and check if the login keyring is being correctly unlocked.

Last edited by johnraff (2016-01-29 07:29:11)


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#6 2016-01-29 06:56:01

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: initializing gnome-keyring-daemon in autostart

johnraff wrote:

About "Not using a DM": IMO 'startx' without an .xinitrc file is the way to go.

I would agree with this.

In Arch, we source startup scripts in /etc/X11/xinit/xinitrc.d to ensure correct dbus initialisation and such trivialities as Infinality font settings but these files simply do not exist in Debian and the startup is mediated through an opaque mechanism (opaque to me anyway).

If I use .xinitrc in my Debian systems, the session isn't initialised properly and gvfs won't mount USB sticks (for example).

However, if the window manager is set as x-session-manager and `startx` is used without ~/.xinitrc then automounting and other stuff works fine.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#7 2016-01-29 07:26:16

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,789
Website

Re: initializing gnome-keyring-daemon in autostart

Head_on_a_Stick wrote:

an opaque mechanism

If you've got some time to spare, and the inclination, have a look at my 2012 topic (link above). I just checked a Jessie system today and everything still seems pretty much the same.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#8 2016-01-29 07:37:17

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,789
Website

Re: initializing gnome-keyring-daemon in autostart

BTW I forgot to mention, all the lines mentioned in the Arch Wiki on starting gnome-keyring with PAM were present in /etc/pam.d/ though not necessarily the same files, so perhaps that's where the SSH_AUTH_SOCKET is ( sometimes  roll ) coming from:

john@bunsen:~$ grep -r 'pam_gnome_keyring.so' /etc/pam.d/
/etc/pam.d/lightdm:-auth  optional pam_gnome_keyring.so
/etc/pam.d/lightdm:-session optional        pam_gnome_keyring.so auto_start
/etc/pam.d/common-password:password	optional	pam_gnome_keyring.so 

Although they say:
You will still need the code in ~/.xinitrc below in order to export the environment variables required.

(Not .xinitrc in our case of course.)

Last edited by johnraff (2016-01-29 07:39:02)


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#9 2016-01-29 09:24:09

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

I still have the RC2 - that hhh posted some time ago for testing - installed

I have
- booted with standard config
- stopped X, edited out the gnome-keyring entry in autostart and restarted X
- stopped X, edited out the /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 & entry as well and restarted X
- stopped X and restarted with startx - without $HOME/.xinintrc

RESULTS:
In all cases SSH_AUTH_SOCKET was set.

Offline

#10 2016-01-30 08:36:15

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,789
Website

Re: initializing gnome-keyring-daemon in autostart

@Doctor xaos thank you for your help with this.

I tried one more test:

- uninstalled gnome-keyring, rebooted the machine

RESULT: SSH_AUTH_SOCKET was set.

Hmm... I eventually figured out gnome-keyring isn't the only thing that can set that variable. It was being set by ssh-agent which comes with the package openssh-client. You have that on your system I guess?
It's possible to tell them apart, they set different paths:

# without gnome-keyring:
john@bunsen:~$ echo $SSH_AUTH_SOCK
/tmp/ssh-vBstqwHbNh5c/agent.1831
john@bunsen:~$ echo $GPG_AGENT_INFO
# (nothing)

# with gnome-keyring:
john@bunsen:~$ gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg
** Message: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1

So if the path is /run/user/1000/keyring/ssh it's coming from gnome-keyring.

A useful diagnostic trick:
edit /etc/X11/Xsession and add 'set -x' somewhere - I put it on line 78 just after 'exec >>"$ERRFILE" 2>&1'
Logout/in and now ~/.xsession-errors will have more information. In particular the line that launches the X session:

exec /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch x-session-manager

(x-session-manager is a Debian alternatives link to, in our case, /usr/bin/openbox-session.)

Anyway, /usr/bin/ssh-agent is being launched, and presumably setting SSH_AUTH_SOCK.

Now, back to gnome-keyring. In fact this Debian bug suggests that ssh and gpg are both poorly supported in gnome-keyring and should not be included in its start-up. That fix is now done in a later version I think. Meanwhile we can just drop ssh and gpg from the initialization command, ie 'gnome-keyring-daemon --start --components=pkcs11,secrets' and let users use ssh-agent and gpg-agent respectively.

I have just found this helpful article about gnome-keyring:
http://www.nurdletech.com/linux-notes/a … yring.html
The guy seems to be using Fedora, so ignore the recommended X startup files which are different in Debian, and I think he's wrong in the PAM section when he says "A leading dash acts as a comment character in these pam files". According to man pam.d "If the type value from the list above is prepended with a - character the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system."
Leaving such quibbles aside, it's all quite interesting.

So I think if we're going to keep gnome-keyring the way to initialize it in openbox/autostart might be:

export $(gnome-keyring-daemon --start --components=pkcs11,secrets)

Note the lack of a final ampersand, and use of export instead of eval. That should directly export any variables output on stdout (no?), but in fact in this case I don't think there will be any.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#11 2016-01-30 12:56:05

kozimodo
Member
Registered: 2015-10-04
Posts: 53

Re: initializing gnome-keyring-daemon in autostart

Gnome-keyring encrypts and stores passwords for subversion and pidgin (if pidgin-gnome-keyring is installed) for example.  Otherwise passwords are not encrypted or are not stored.  If there is some alternative, that would be great but I find it pretty useful.

Offline

#12 2016-01-30 13:19:48

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

Great solution you found there, John. smile

You have that on your system I guess?

Yes.
And gnupg.

So if the path is /run/user/1000/keyring/ssh it's coming from gnome-keyring.

Only I never got that because I had gnome-keyring removed, and
commented out the gnome-keyring entry in $HOME/.config/openbox/autostart.

A useful diagnostic trick: ...

Yes. I have done this at several occasions to debug x11 startup.
For the crunchbang slim display manager for instance.

BTW: Do you also find this error message in $HOME/.xsession-errors:]
Failure: Module initialization failed     

...
Openbox-Debug: Granting ConfigureRequest x 1692 y 42 w 214 h 476
Entering openbox-xdg-autostart(python script)...
Failure: Module initialization failed                 <---------------
launcher.c 215: Using icon /usr/share/icons/Faenza-Bunsen-common/categories/22/applications-internet.png
...

As you can see I have been doing some debugging as well.
The error comes from /usr/lib/x86_64-linux-gnu/openbox-xdg-autostart, which is a python script, and gets executed somewhere in the openbox startup sequence.
At the moment I have not examined this any further.
I will do that though

Interesting read. Thx for that.

Remains the question about the necessity of

## for authentication
# /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &

in autostart.
As you see I have it commented out for the moment, hoping to find something is not working well when that process is not active.

xaos52

Offline

#13 2016-01-30 13:37:48

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: initializing gnome-keyring-daemon in autostart

I am fairly certain that I never had the policy-kit line in my autostart in my early live build and policykit still worked for me.

Offline

#14 2016-01-30 13:52:03

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

Thanks for your contribution, tk.
Reactions from others are welcomed.

Offline

#15 2016-01-30 16:21:33

Sector11
Conky 1.9er Mod Squid
From: Upstairs
Registered: 2015-08-20
Posts: 6,125

Re: initializing gnome-keyring-daemon in autostart

I stopped using gnome-keyring years ago when it started showing errors in my terminal while loading a conky with things like:

WARNING: gnome-keyring:: couldn't connect to: /home/username/.cache/keyring-XXXXXX/pkcs11: No such file or directory

And I've never had a problem by not having it.

In layman's terms: Why is it so important to have it installed?


The sun will never set if you keep walking towards it. - my son
Being positive doesn't understand physics.

Offline

#16 2016-01-30 17:39:17

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

So did I. Stop using it I mean. I even removed the 'gnome -keyring' package.

But gnome-keyring can be usefull for storing secrets in encrypted form.

Secrets such as the password for your wifi connection if you are using WPA, or your login password, or your root password, or passwords for websites.

For WiFi passwords, for example, NetworkManager stores such passwords in system files, but it stores them in 'clear form', not encrypted, which can be considered a security risk.
(A person with physical access to your computer can steal your hard drive and examine it at home, without knowing your root password,and so discover your secret wifi password because it is stored in clear form)

gnome-keyring and NetworkManager can be configured such that that wifi password is stored in encrypted form on your system, protected by a "passphrase" that only you know. Then even when someone has physical access to your computer and he removes your hard drive, he will never be able to find your password on that disk because of the encryption. 
When NetworkManager needs the password it can 'talk' to gnome-keyring, requesting for that password in a safe way such that the password is never visible in the clear, not on the disk, nor in memory.

Setting up gnome-keyring when you are using the gnome desktop is easy, peasy.
Using openbox as we do in bunsenlabs makes setting it up harder. But we will get there, I am sure. smile

Offline

#17 2016-01-30 18:02:49

Sector11
Conky 1.9er Mod Squid
From: Upstairs
Registered: 2015-08-20
Posts: 6,125

Re: initializing gnome-keyring-daemon in autostart

I don't use G-keyring or any network-manager.  I simply let DHCP automatically configure the interface, no WiFi or BlueTooth here.  Just me and my cable modem.


The sun will never set if you keep walking towards it. - my son
Being positive doesn't understand physics.

Offline

#18 2016-01-30 18:52:14

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

But perhaps you have other 'secrets' on your computer, that can be of value to someone that steals your hardware.

Offline

#19 2016-01-30 19:14:21

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

@John,
There is still 'danger ahead'.

I have re-installed gnome-keyring to do some more tests and:

export $(gnome-keyring-daemon --start --components=pkcs11,secrets)

seems to export only GPG_AGENT_INFO, not SSH_AUTH_SOCKET.
This could eventually be cured by using

Edited:
No, I don't think so.
$HOME/.local/openbox/autostart is interpreted by 'sh', which in bunsenlabs is linked to 'dash'  (as is the Debian standard)

declare -a -- gk-variables
gk-variables=( $(gnome-keyring-daemon --start --components=pkcs11,secrets) )
export "${gk-variables[@]}"
unset gk_variables

I guess the gnome-keyring components will still need to be started using the XDG mechanism, because the only process related to gnome-keyring running after startup is

Edited:
Correction: export $(gnome-keyring-daemon --startup) shoud be starting the necessary components, but only one instance of the daemon should be running, is is the case already.

me        8354     1  0 77888  9504   0 17:11 ?        00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login

which is the process to unlock the login key, started by PAM according to one of the links you posted.

EDIT:
I have to stop here, but from my debugging it seems the commands in $HOME/.config/openbox/autostart are NOT handled by a shell, but by the openbox executable itself!
Above is not true. autostart is interpreted by 'sh'.

There is one thing we are still missing though.
$(gnome-keyring-daemon should also be outputting a setting for  $GNOME_KEYRING_CONTROL.
It is not doing so!

Now my first guess here, and I do stress it only being a guess, is that we don't have any session set up at that time.
Then I remembered that in the old times, the very first thing that was launche in autostart was 'lxsession'.
That lxsession was probably (guessing again) a stripped down, customized version from the LXD 'lxsession'.

@John,
Do you still have access to the crunchbang source repo, can you verify this and make the source of  thet 'crunchified lxsession' available?
If not we will have to create one ourselves.

Well, well well.
Seems like we might finally have an answer to one of the very first questions I ever posted on the crunchbang forum:
"Why do we have 'lxsession' running as the first command in autostart? Is it doing anything useful?
The answer might be that it is creating a very elementary session so   that gnome-keyring works under openbox!

To be continued.

Offline

#20 2016-01-31 07:31:56

hhh
Meep!
Registered: 2015-09-17
Posts: 9,587
Website

Re: initializing gnome-keyring-daemon in autostart

It's awesome that you gents have had time to look into this, because I have not had time.

johnraff wrote:

@Doctor xaos thank you for your help with this.

I tried one more test:

- uninstalled gnome-keyring, rebooted the machine

RESULT: SSH_AUTH_SOCKET was set.

Hmm... I eventually figured out gnome-keyring isn't the only thing that can set that variable. It was being set by ssh-agent which comes with the package openssh-client.

I just added openssh-client to the package list in response to a twitter comment from a week ago that we discussed, right? Let me know if I can drop gnome-keyring soon, I plan to build RC2 tomorrow night (11PM-ish EST, Jan 31, we'll release it within the first few days of Feb if it looks good).

Offline

#21 2016-01-31 10:11:47

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

^ Seems like it won't be dropped after all because it provides some useful features.

John wrote:

So I think if we're going to keep gnome-keyring the way to initialize it in openbox/autostart might be:

We are just struggling a bit now to get it set up correctly to function under openbox.

Offline

#22 2016-01-31 10:36:26

Tao
Member
Registered: 2016-01-30
Posts: 7

Re: initializing gnome-keyring-daemon in autostart

Is responsible for what each of its components? Passwords for websites?

Offline

#23 2016-01-31 18:19:35

hhh
Meep!
Registered: 2015-09-17
Posts: 9,587
Website

Offline

#24 2016-01-31 19:51:46

hhh
Meep!
Registered: 2015-09-17
Posts: 9,587
Website

Re: initializing gnome-keyring-daemon in autostart

^Sorry, those points are all covered earlier in the thread. ops

Offline

#25 2016-02-01 03:19:31

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

Edited post #19

@John,
Do you still have access to the crunchbang source repo, can you verify this and make the source of  thet 'crunchified lxsession' available?
If not we will have to create one ourselves.

Offline

Board footer

Powered by FluxBB