Re: [git-buildpackage] environment clearing?
Hi Daniel, On Wed, Nov 18, 2015 at 03:37:55PM -0500, Daniel Kahn Gillmor wrote: > Almost: > > buildpackage.builder is the empty string, but And that is a bug in gbp itself since it should print the default value here instead of the empty string. Fixed with: https://git.sigxcpu.org/cgit/git-buildpackage/commit/?id=6d802390e2274bc0c3d03623edac2eb8c482a829 > buildpackage.pbuilder=False > > > If so, can you try to set the builder to a command that just dumps the > > environment into a file like: > > > > gbp buildpackage --git-builder='printenv > /tmp/foo' --git-no-pbuilder > > > > and check if it has all the needed environment variables? If I do this I > > do find DBUS_SESSION_BUS_ADDRESS in there as well as several gpg related > > ones (like GPG_AGENT_INFO) and looking at the code we don't clear the > > env, we either extend it or leave it untouched (by passing None). > > yes, i see DBUS_SESSION_BUS_ADDRESS in there too. h. > > > So are we sure it's environment variable related or maybe something else? > > > > Another possibility would be to use > > > > strace -f -o /tmp/bla.log -s2048 dpkg-buildpackage > > > > as builder so we can maybe figure what's going wrong (i.e. if it's not > > possible to open the dbus socket)? > > huh, this actually worked to build the package just fine. > > But it helped me to narrow things down! it looks like > --git-builder=debuild is what's causing the stripping, and when > buildpackage.builder is the empty string and debuild is available in the > $PATH, it prefers debuild to dpkg-buildpackage (which is probably > reasonable). > > I'll go hassle the debuild folks now :) > > Thanks for helping me debug, Thank you for your explanation! Cheers, -- Guido ___ git-buildpackage mailing list git-buildpackage@lists.sigxcpu.org http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
Re: [git-buildpackage] environment clearing?
On Mon 2015-11-16 14:38:04 -0500, Guido Günther wrote: > I'm sorry for being ignorant here but how exactly does this work? gpg > looks for a running agent to see if the key is already unlocked, if not > gpg-agent calls out for the pinentry, which then needs a D-Bus session > bus? it's rather complicated. Below is the workflow for "modern" GnuPG (2.1.x and higher) under GNOME 3: 0) gpg looks for a running gpg-agent. 1) if the agent doesn't exist, gpg starts one. 2) gpg now asks the agent for the use of a secret key 3) the agent checks if the key is already unlocked. 4) If the key is not unlocked, gpg-agent spawns a pinentry. 5) it spawns /usr/bin/pinentry by default, which is governed by /etc/alternatives. 6) pinentry is responsible for showing a prompt to the user. 7) if /usr/bin/pinentry points to pinentry-gnome3, then it uses gcr (the gnome crypto toolkit) to do the prompting. 8) gcr works by the running process communicating over dbus, using DBUS_SESSION_BUS_ADDRESS to find the correct unix-domain socket for communications. > This is during the "normal" build process? What builder are you using, > what does > > gbp config buildpackage.builder > gbp config buildpackage.pbuilder > > show? I assume s.th. like: > > $ gbp config buildpackage.builder > buildpackage.builder=dpkg-buildpackage > $ gbp config buildpackage.pbuilder > buildpackage.pbuilder=False Almost: buildpackage.builder is the empty string, but buildpackage.pbuilder=False > If so, can you try to set the builder to a command that just dumps the > environment into a file like: > > gbp buildpackage --git-builder='printenv > /tmp/foo' --git-no-pbuilder > > and check if it has all the needed environment variables? If I do this I > do find DBUS_SESSION_BUS_ADDRESS in there as well as several gpg related > ones (like GPG_AGENT_INFO) and looking at the code we don't clear the > env, we either extend it or leave it untouched (by passing None). yes, i see DBUS_SESSION_BUS_ADDRESS in there too. h. > So are we sure it's environment variable related or maybe something else? > > Another possibility would be to use > > strace -f -o /tmp/bla.log -s2048 dpkg-buildpackage > > as builder so we can maybe figure what's going wrong (i.e. if it's not > possible to open the dbus socket)? huh, this actually worked to build the package just fine. But it helped me to narrow things down! it looks like --git-builder=debuild is what's causing the stripping, and when buildpackage.builder is the empty string and debuild is available in the $PATH, it prefers debuild to dpkg-buildpackage (which is probably reasonable). I'll go hassle the debuild folks now :) Thanks for helping me debug, --dkg ___ git-buildpackage mailing list git-buildpackage@lists.sigxcpu.org http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
Re: [git-buildpackage] environment clearing?
Hi Daniel, On Mon, Nov 16, 2015 at 12:50:55PM -0500, Daniel Kahn Gillmor wrote: > hey folks-- > > I find that git-buildpackage seems to clear the environment in some > cases where dpkg-buildpackage does not. > > This results in a problem for some workflows that include the use of > GnuPG when a gpg-agent is running with a different environment than the > build process. > > the spot where i've noticed it is: > > * have a gpg-agent set up with no DBUS_SESSION_BUS_ADDRESS environment >variable of its own > > * use pinentry-gnome3 as the default pinentry > > * build a package with "gbp buildpackage" > > * have gnupg2 2.1.x instealled I'm sorry for being ignorant here but how exactly does this work? gpg looks for a running agent to see if the key is already unlocked, if not gpg-agent calls out for the pinentry, which then needs a D-Bus session bus? Which environment variables are needed for that? > When it comes to the step to sign the .dsc and .changes files, i get a > signature failure with no prompts. This is during the "normal" build process? What builder are you using, what does gbp config buildpackage.builder gbp config buildpackage.pbuilder show? I assume s.th. like: $ gbp config buildpackage.builder buildpackage.builder=dpkg-buildpackage $ gbp config buildpackage.pbuilder buildpackage.pbuilder=False If so, can you try to set the builder to a command that just dumps the environment into a file like: gbp buildpackage --git-builder='printenv > /tmp/foo' --git-no-pbuilder and check if it has all the needed environment variables? If I do this I do find DBUS_SESSION_BUS_ADDRESS in there as well as several gpg related ones (like GPG_AGENT_INFO) and looking at the code we don't clear the env, we either extend it or leave it untouched (by passing None). So are we sure it's environment variable related or maybe something else? Another possibility would be to use strace -f -o /tmp/bla.log -s2048 dpkg-buildpackage as builder so we can maybe figure what's going wrong (i.e. if it's not possible to open the dbus socket)? > If i use "dpkg-buildpackage" instead, i get a gnome3-based pinentry > prompt and the files get signed. > > And if i kill the gpg-agent and restart it with the same socket and a > default dbus environment variable that works with the current session > [0] then even "gpb buildpackage" will work and have signing happen. > > So this makes me think that gpb is stripping the environment before > invoking gpg, but i havne't been able to track it down. > > any pointers? See above though I'm not sure this is really helping. Cheers, -- Guido ___ git-buildpackage mailing list git-buildpackage@lists.sigxcpu.org http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
[git-buildpackage] environment clearing?
hey folks-- I find that git-buildpackage seems to clear the environment in some cases where dpkg-buildpackage does not. This results in a problem for some workflows that include the use of GnuPG when a gpg-agent is running with a different environment than the build process. the spot where i've noticed it is: * have a gpg-agent set up with no DBUS_SESSION_BUS_ADDRESS environment variable of its own * use pinentry-gnome3 as the default pinentry * build a package with "gbp buildpackage" * have gnupg2 2.1.x instealled When it comes to the step to sign the .dsc and .changes files, i get a signature failure with no prompts. If i use "dpkg-buildpackage" instead, i get a gnome3-based pinentry prompt and the files get signed. And if i kill the gpg-agent and restart it with the same socket and a default dbus environment variable that works with the current session [0] then even "gpb buildpackage" will work and have signing happen. So this makes me think that gpb is stripping the environment before invoking gpg, but i havne't been able to track it down. any pointers? --dkg [0] restarting the agent from within a running X11 session goes like this: gpg-connect-agent killagent /bye && gpg-connect-agent /bye ___ git-buildpackage mailing list git-buildpackage@lists.sigxcpu.org http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
