`gen_key` fails when run under `bazel build`

[vsajip]

Original report by phlax (Bitbucket: phlax, GitHub: phlax).

---

When trying to generate a key inside a job managed by bazel build no error is raised, but no key is created either

Running the same python-gnupg invokation directly works fine, as does running under bazel run so i suspect the problem is that bazel build takes control of stdin/out and this prevents python-gnupg from working correctly

‌

[vsajip]

Please provide a small script demonstrating the issue. Also, can you ensure logging is turned on for python-gnupg and see what the log shows?

[vsajip]

Original comment by phlax (Bitbucket: phlax, GitHub: phlax).

---

after turning on logging i see the problem

gpg: Fatal: can't create directory '/root/.gnupg': Read-only file system

‌

so it turns out its not to do with stdout/err after all

feel free to close this, altho it would be good in this situation if it raised an error rather than passing silently

[vsajip]

My guess is that gpg doesn’t pass this back in a way that python-gnupg can report it. Perhaps report upstream to the GnuPG project?

[vsajip]

Original changes by Vinay Sajip (Bitbucket: vinay.sajip, GitHub: vsajip).

---

changed state from "new" to "invalid"

[vsajip]

Original comment by phlax (Bitbucket: phlax, GitHub: phlax).

---

in terms of the key returned from gen_key - afaict if the key wasnt created then key.fingerprint is None , so i can raise on that basis, wondering if that should be the default

It would be still good to get FATAL logs from gpg - i had a quick look but wasnt sure of what to report where

thanks for help and advice

[vsajip]

You can report GnuPG issues at https://dev.gnupg.org/ - here’s an example of a bug I reported earlier this year. You might need to create an account there.

[vsajip]

Original comment by phlax (Bitbucket: phlax, GitHub: phlax).

---

the bit im not clear about is what the interaction between gnupg <> python-gnupg is

‌

this is a fuller dump of the logs from the failing interaction

‌

gpg --status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --version
gpg --status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --list-secret-keys --fingerprint --fingerprint "foo <foo.com>"
gpg: Note: trustdb not writable
gpg: checking the trustdb
[GNUPG:] KEY_CONSIDERED 9A501C13668974C71442483393D70DE648C8B389 0
gpg: trustdb rec 31: write failed (n=-1): Bad file descriptor
gpg: Fatal: /root/.gnupg/trustdb.gpg: failed to append a record: Bad file descriptor
gpg --status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --gen-key
gpg: failed to create temporary file '/root/.gnupg/.#lk0x0000558bb5b5f580.iota.15': Read-only file system
gpg: can't connect to the agent: Read-only file system
gpg: agent_genkey failed: No agent running
gpg: key generation failed: No agent running
[GNUPG:] ERROR key_generate 33554509
[GNUPG:] KEY_NOT_CREATED

‌

can python-gnupg not error on the basis that KEY_NOT_CREATED was returned or is it just checking the return code ?

[vsajip]

Original comment by phlax (Bitbucket: phlax, GitHub: phlax).

---

hmm, checking further it seems that the above log is the response if the trustdb exists but is not writeable

if no trustdb exists at all then the log is

‌

gpg --status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --gen-key
gpg: Fatal: can't create directory '/root/.gnupg': Read-only file system

‌

so i guess the bug would be that it should output KEY_NOT_CREATED in this circumstance also ?

[vsajip]

Well, if the gen_key() returned object's type and fingerprint are None, it means no key was generated. For reasons, you’d have to look in the log - gpg doesn’t indicate the reason for KEY_NOT_CREATED. Also, what is the return code from the gpg subprocess? The latest release of python-gnupg (0.4.8) should return the gpg return code in the returned object, and if it’s non-zero, a ValueError should be raised. If gpg returns zero, no exception is raised.

[vsajip]

and if it’s non-zero, a ValueError should be raised.

Actually, that’s not true (for backward compatibility reasons, a warning is logged, but no ValueError is raised - there have been cases in the past where gpg returned non-zero error codes that weren’t actually errors, but I don't know if that’s still the case.

You could check for the returned objects returncode attribute being non-zero and raising an exception yourself.

[vsajip]

I’ll reopen this issue while I think about adding a status attribute to the returned object.

[vsajip]

Original changes by Vinay Sajip (Bitbucket: vinay.sajip, GitHub: vsajip).

---

changed state from "invalid" to "open"

[vsajip]

Original comment by phlax (Bitbucket: phlax, GitHub: phlax).

---

the returncode from gpg is 2

i could also use that i guess, but yep that still doesnt give a reason

[vsajip]

That’s true, and it’s because gpg doesn’t provide a useful error. For example, you could get ‘Permission denied’, but you’d still have to trawl through the log to see what the actual file or directory was which was inaccessible.

[vsajip]

Fixed #161: Add 'status' attribute to GenKey instances.