bzr commit fails when GPG agent is unavailable

[John Dong]

I usually run the Seahorse agent for GPG passphrase caching, but recently I've turned it off after switching to KDE.

When I try checking in, it tells me:
jdong@jdong-laptop:~/devel/pyfragtools/head$ bzr ci
modified defrag

You need a passphrase to unlock the secret key for
user: "John Dong (Ubuntu Key!) <email address hidden>"
1024-bit DSA key, ID B1233042, created 2005-09-27

can't connect to `/home/jdong/.gnome2/seahorse-437OZU/S.gpg-agent': Connection refused
gpg: can't connect to `/home/jdong/.gnome2/seahorse-437OZU/S.gpg-agent': connect failed
========================================
Then, it properly prompts for a passphrase, which I enter. Afterwards, bzr states:

bzr: ERROR: Failed to gpg sign data with command '['gpg', '--clearsign']'

even though I provided a correct passphrase after it fell back from agent usage.

[Martin Pool (mbp)]

This is strange. Can you check something - try running the signing
command from a shell and reproduce the failure and fallback, and then
tell me what the exit code was? You can get that by typing

  echo $?

--
Martin

[John Dong (jdong)]

It gives a return code of "2", despite correctly generating a signature. This is the same return code as an invalid password!

We might have to look at GPG's output (i.e. non-null) rather than return code?

[John A Meinel (jameinel)]

John Dong wrote:
> It gives a return code of "2", despite correctly generating a signature.
> This is the same return code as an invalid password!
>
> We might have to look at GPG's output (i.e. non-null) rather than return
> code?
>

I've found this myself. gpg returns a return code of '2' if it is unable
to connect to the gpg-agent, if 'use agent' is true (either from the
--use-agent command line or 'use-agent' is set in ~/.gnupg/gpg.conf

If you want a simple workaround, you can modify ~/.bazaar/bazaar.conf
and set:

[DEFAULT]
gpg_signing_command=gpg --no-use-agent

Then bzr will tell gpg not to try to connect to the gpg-agent.

In the future, we will probably use pygpgme for a more accurate way of
controlling gpg.

This bug can stay open until then, I guess.

John
=:->

[John Dong (jdong)]

Well, I'd like for it to use the agent when there is an agent, but fall back
to passwords when the agent cannot be contacted.

It should be a pretty "no-duh" check if GPG succeeded or failed (i.e. either
it outputs a signature or doesn't) without using return codes...

On 5/15/06, John A Meinel <email address hidden> wrote:
>
> John Dong wrote:
> > It gives a return code of "2", despite correctly generating a signature.
> > This is the same return code as an invalid password!
> >
> > We might have to look at GPG's output (i.e. non-null) rather than return
> > code?
> >
>
> I've found this myself. gpg returns a return code of '2' if it is unable
> to connect to the gpg-agent, if 'use agent' is true (either from the
> --use-agent command line or 'use-agent' is set in ~/.gnupg/gpg.conf
>
> If you want a simple workaround, you can modify ~/.bazaar/bazaar.conf
> and set:
>
> [DEFAULT]
> gpg_signing_command=gpg --no-use-agent
>
> Then bzr will tell gpg not to try to connect to the gpg-agent.
>
> In the future, we will probably use pygpgme for a more accurate way of
> controlling gpg.
>
> This bug can stay open until then, I guess.
>
> John
> =:->
>
> --
> bzr commit fails when GPG agent is unavailable
> https://launchpad.net/bugs/44755
>

[John Dong (jdong)]

http://jdlan.gotdns.org/~jdong/bzr/bzr.dev.gpg-fix/

I wrote up an extremely simple patch to bzr.dev that closes this bug for me. It simply checks length of "result" instead of return code to determine if a signature failed or succeeded. In my testing, it correctly identifies failed and succeeded signings.

[Robert Collins (lifeless)]

On Mon, 2006-05-15 at 21:02 +0000, John Dong wrote:
> http://jdlan.gotdns.org/~jdong/bzr/bzr.dev.gpg-fix/
>
> I wrote up an extremely simple patch to bzr.dev that closes this bug for
> me. It simply checks length of "result" instead of return code to
> determine if a signature failed or succeeded. In my testing, it
> correctly identifies failed and succeeded signings.

From the man page for GPG:

RETURN VALUE
       The program returns 0 if everything was fine, 1 if at least a
signature was bad, and other error codes for fatal errors.

Ignoring this value is cavalier at best.

I am strongly -1 on this patch.

I consider it a bug in gpg that it returns a status of 2 ('some fatal
error' according to the man page) if it can't contact the agent, and I
urge you to file a bug on gpg, perhaps asking for a '--auto-use-agent'
or something, which will not return 2 if the agent is missing.

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[John Dong (jdong)]

On 5/15/06, Robert Collins <email address hidden> wrote:
>
>
> >From the man page for GPG:
>
> RETURN VALUE
> The program returns 0 if everything was fine, 1 if at least a
> signature was bad, and other error codes for fatal errors.
>
>
> Ignoring this value is cavalier at best.

For signing? I do not see much of a threat in signing... Either a signature
went through and signed output goes to stdout, or nothing goes to stdout.
There is no 'grey area' in between...

I am strongly -1 on this patch.
>
> I consider it a bug in gpg that it returns a status of 2 ('some fatal
> error' according to the man page) if it can't contact the agent, and I
> urge you to file a bug on gpg, perhaps asking for a '--auto-use-agent'
> or something, which will not return 2 if the agent is missing.

I agree, it is that it's a GPG bug. I've filed a bug report over at GPG:
http://bugs.gnupg.org/cgi-bin/gnatsweb.pl?cmd=view&database=default&user=guest&password=guest&pr=655

But I still think that for Bazaar-NG to adamantly refuse to provide a
workaround or otherwise fix this situation only screws over the users in the
end.

Rob
>
> --
> GPG key available at: <http://www.robertcollins.net/keys.txt>.
>
> --
> bzr commit fails when GPG agent is unavailable
> https://launchpad.net/bugs/44755
>

[John A Meinel (jameinel)]

Another easy way to fix this if you so desire, would be to create a wrapper script around gpg. And then set your default gpg signing tool to be that.

Save the attached script somewhere, and chmod +x it.

Then edit ~/.bazaar/bazaar.conf to set:
gpg_signing_command=/home/jameinel/bin/mygpg.py

At that point, it will spawn the wrapper script, rather than spawning gpg. And the attached script will tell bzr that the signing was successful.

[John A Meinel (jameinel)]

The last message shows a reasonable workaround.

I don't think the core of bzr should cavalierly ignore the fact that gpg is returning an error code.

But if you are sure that on your machine an error code is not a fatal error, you can use the workaround.

[John A Meinel (jameinel)]

Just adding a bit of description text at the top of the file.

[Francis J. Lacoste (flacoste)]

This bug is still happening and biting me here.

From the comments, I don't see why this is Fixed released. Won't fix might be a better status.

[Robert Collins (lifeless)]

On Fri, 2009-06-12 at 20:42 +0000, Francis J. Lacoste wrote:
> This bug is still happening and biting me here.
>
> >From the comments, I don't see why this is Fixed released. Won't fix
> might be a better status.

Well we haven't merged the patch, nor even reviewed it AFAIK. John, care
to submit it for review in lp?

But that said, it really is hostile for gpg to do this; I suggest a
helper script that can correctly interpret gpg's behaviour is a more
appropriate way to solve this (morally the equivalent of using pygpgme,
but still allowing people to have different scripts than gpg itself).

-Rob

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Francis J. Lacoste wrote:
> This bug is still happening and biting me here.
>
>>From the comments, I don't see why this is Fixed released. Won't fix
> might be a better status.
>
> ** Changed in: bzr
> Status: Fix Released => New
>

It seems to be working just fine for me with Hardy, as I assume it is a
GPG + gpg-agent issue. Can you give the specifics of your platform and
what GPG version and agent you are using?

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko0e8EACgkQJdeBCYSNAAN0DgCg2E0gkuSJJRjFaKWRVkQ6cJJ+
9uoAoNisQCW6yplNGlHBtQvBSM6Krg47
=naOu
-----END PGP SIGNATURE-----

[Robert Collins (lifeless)]

This really is fixed released. Francis please file a new bug,probably on gpg.

[Kip Warner (kip)]

I am experiencing the same problem with nautilus-bzr extension 0.100.0-2~bazaar1~maverick2. I tried adding the following to the [DEFAULT] section in the config, to no avail:

gpg_signing_command=gpg --no-use-agent

I get the following error when I click the Commit button:

Failed to gpg sign data with command "[u'gpg --no-use-agent', '--clearsign']"