Strange behavior using pam_envoy without same password in keys

[cpixl]

Well, first things first: the #37 was fixed (at least for me) in the last commits... not sure which one, but it works perfectly right now! Thank you :)

But I would like to note that there's a strange behavior when the keys and the user password aren't the same: When trying to use gpg after I authenticated with LightDM, it will give me an pinentry (in this case pinentry-gtk-2) asking me for the passphrase... okay, everything good until here. In the same terminal, if I try something that will use the gpg-agent as ssh-agent (for example git push), it will simply give me this:

Agent admitted failure to sign using the key.
Permission denied (publickey).

... without even asking me anything!

At the same time, if I just authenticate through an tty, the behaviors will be switched: The gpg will give me the following (yes, always twice):

gpg: signing failed: Operation cancelled
gpg: signing failed: Operation cancelled

...again, without asking me anything first. And the ssh command (again, git push) will give me the pinentry (now pinentry-curses) correctly!

AAAAAAND (don't know if I should fill another issue for this one, if I should just tell me and I'll do it) if I authenticate on both LightDM and another tty at the same time... the chaos reigns. When I use anything in the terminal at my desktop, the pinentry will show on the tty as pinentry-curses, and if I try the same on the tty... it appears nowhere!

I would imagine that envoy-exec is here to help in the last situation by setting where the pinentry will appear... but unfortunately it just gives me the following on envoy-exec git push:

[1]    15029 segmentation fault (core dumped)  envoy-exec git push

If my account password and gpg key are the same, everything said works fine... but the envoy-exec git push still crashes.

[vodik]

Okay, this sounds like a legitimate problem that I'll have to (unfortunately) reproduce to debug. Yay! I'll hopefully setup a VM for this tonight. Sounds like it'll be a fun one to track down.

What would help is if you did a debug build of envoy and see if you can get me the backtrace of that segfault. Maybe that's enough to make the bug obvious.

[cpixl]

Hmm okay... sorry for the silly question, but I believe I have to do it: how to make a debug build? I'm not used to C programming, and looking at the Makefile didn't help me :(

[vodik]

Right. No worries.

CFLAGS='-ggdb3 -O0' make

[cpixl]

Done! Check your inbox :D

[vodik]

Would you still have the broken build of envoy kicking around? Specifically the version? gdb is telling me the segfault is on a weird line of code, I'm not sure if some of the refactoring work I've done is now getting in the way.

I'm speaking at a conference next week (which is also why its taken me so long to get around to this) but I want to tackle this and focus some serious effort in whipping this project back into shape.

[cpixl]

It was (and still is) the latest version :)

[vodik]

Alright, lets see if I can still reproduce it again now that I'm home.

@dan-silva might be worth trying again on a recent build because I've killed some defects found by Coverity.

[cpixl]

Okay, I reinstalled envoy but it still happens in the same way. I tested with v14 from Archlinux official binaries and the same for the AUR package (it's registered as v12.1, but it will get the commit anyway).

[vodik]

Okay, I'm just going to setup a VM and figure this out there. Let me get this straight:

1. Archlinux with LightDM
2. You unlock your keyring with pam (key password same as user login)
3. You get lots of weirdness with pinentry / envoy-exec segfaults.

Missing any steps?

[cpixl]

Just to make sure, here it is my /etc/pam.d/lightdm:

#%PAM-1.0
auth        include     system-login
-auth       optional    pam_gnome_keyring.so
auth        optional    pam_envoy.so
account     include     system-login
password    include     system-login
session     include     system-login
session     optional    pam_envoy.so    gpg-agent
-session    optional    pam_gnome_keyring.so auto_start

... and my /etc/pam.d/login:

#%PAM-1.0

auth       required     pam_securetty.so
auth       requisite    pam_nologin.so
auth       include      system-local-login
auth       optional     pam_envoy.so
account    include      system-local-login
session    include      system-local-login
session    optional     pam_envoy.so          gpg-agent

And that's it, I believe there's nothing else important on my setup that could mess with it :)

[vodik]

Cool, thanks. I'll see what I can reproduce tonight. Sorry, I've been tied up with other priorities.

[cpixl]

No problem, feel free to ask me anything if its necessary... and if you can't reproduce the issue, we can try a remote session to debug on my machine :)