Bug 1005916 - Importing PGP key fails because seahorse tries to use gpg instead of gpg2
Importing PGP key fails because seahorse tries to use gpg instead of gpg2
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: seahorse (Show other bugs)
25
All Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-09 12:40 EDT by Christian Stadelmann
Modified: 2017-01-28 19:21 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-28 19:21:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproducing comment #0, output of $ strace -f -e trace=process seahorse (20.59 KB, text/plain)
2017-01-24 12:48 EST, Christian Stadelmann
no flags Details

  None (edit)
Description Christian Stadelmann 2013-09-09 12:40:18 EDT
Description of problem:
I tried to import a public PGP key from a file

Version-Release number of selected component (if applicable): 3.8.2
GnuPG2: 2.0.19

How reproducible: Always

Steps to Reproduce:
1. Download or create a PGP public key
2. Import the key using File->Import->select the file
3. Press "Import"

Actual results:
Error message popup:
„Import fehlgeschlagen: Kindprozess »/usr/bin/gpg« konnte nicht ausgeführt
werden (Datei oder Verzeichnis nicht gefunden)“
translation:
"Import failed: could not execute child process »/usr/bin/gpg« (file or
directory not found)"

Expected results: Seahorse should import that key


Additional info:
The reason is simple: My Fedora 19 has /usr/bin/gpg2 (gnupg2 2.0.x) installed
and NOT gnupg 1.4.x which the importer tries to use. According to Seahorse developer Stef Walter this is a bug in packaging/building, not in seahorse: https://bugzilla.gnome.org/show_bug.cgi?id=707690
Comment 1 Liquid Fiber 2013-11-19 10:12:01 EST
I have the same error. Solved by installing gnupg package.
Comment 2 Fedora End Of Life 2015-01-09 14:47:00 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 3 Fedora End Of Life 2015-02-17 12:07:41 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 4 Christian Stadelmann 2015-03-06 08:50:09 EST
This bug is still present. I consider this a packaging issue.
Comment 5 Fedora End Of Life 2015-11-04 08:17:17 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 6 Fedora End Of Life 2015-12-01 21:57:09 EST
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 7 Michael Vorburger 2016-09-05 14:22:23 EDT
Similar problem here (no error, but just no PGP keys shown in Seahorse); one possible workaround solution is to migrate your keys from gpg to gpg2 as described on https://ask.fedoraproject.org/en/question/77129/gnome-passwords-and-keys-seahorse-doesnt-display-any-of-my-gpgpgp-keys/ :

    gpg --export-secret-keys >secretkeys
    gpg --export >publickeys
    gpg2 --import secretkeys publickeys

You should of course also wipe secretkeys after. Also note that you may only see it in “Passwords and Keys” [Seahorse] after a Desktop user session logout and re-login.
Comment 8 indolering 2017-01-23 17:46:54 EST
This is still a problem in Fedora 25. This is a packaging issue.
Comment 10 Christian Stadelmann 2017-01-23 20:28:59 EST
In case the maintainer(s) don't respond, we should probably go for the "non-responsive package maintainers" policy: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Btw, according to the package database, Matthias Clasen, who is an active package maintainer, also owns this package. And there is another packager awaiting review: https://admin.fedoraproject.org/pkgdb/package/rpms/seahorse/
Comment 11 Kalev Lember 2017-01-24 05:01:24 EST
Seahorse works just fine here with gpg2. Sounds like it's an issue with gpgme's automatic engine selection if it tries to run a non-existent /usr/bin/gpg as reported in comment #0. If this is still the case that it should be a gpgme bug.

As for the keys not showing up with gpg2 and only showing up with gpg that's reported in comment #7, that sounds like a migration issue that gpg2 should handle (but apparently doesn't).

Not sure there's anything to do here for Seahorse. Stef?
Comment 12 Christian Stadelmann 2017-01-24 12:48 EST
Created attachment 1244015 [details]
Reproducing comment #0, output of $ strace -f -e trace=process seahorse

(In reply to Kalev Lember from comment #11)
> Seahorse works just fine here with gpg2. Sounds like it's an issue with
> gpgme's automatic engine selection if it tries to run a non-existent
> /usr/bin/gpg as reported in comment #0. If this is still the case that it
> should be a gpgme bug.

Are you sure it is using gpg2, not gpg? Which of them do you have installed?
I tried to reproduce comment #0 and seahorse still uses /usr/bin/gpg although /usr/bin/gpg2 is installed. I still can reproduce that with only gnupg2 but not gnupg (1.4.x) installed. Note that seahorse does correctly start gpg2 at first, but still tries to use gpg (1) to import later.

> As for the keys not showing up with gpg2 and only showing up with gpg that's
> reported in comment #7, that sounds like a migration issue that gpg2 should
> handle (but apparently doesn't).

Yes, that's a known version intolerance issue with GnuPG. The solution is to only use one version and never downgrade. Since gpg2 has been around for a while, and to my knowledge all other GUI tools related to GnuPG are using version 2, so Seahorse should default to using version 2.
Comment 13 Christian Stadelmann 2017-01-24 12:55:16 EST
A truncated backtrace of running 

$ gdb seahorse
[reproduce comment #0 up to step 2]
Ctrl+C
(gdb) follow-fork-mode child
(gdb) break execve
(gdb) continue
[reproduce step 3]
(gdb) backtrace


#0  0x00007ffff3634c90 in execve () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff5049706 in g_execute (search_path_from_envp=0, search_path=0, envp=0x5555562aea40, argv=0x5555561d2690, file=0x5555562caee0 "/usr/bin/gpg") at gspawn.c:1678
#2  0x00007ffff5049706 in do_exec (child_err_report_fd=26, stdin_fd=<optimized out>, stdout_fd=30, stderr_fd=32, working_directory=working_directory@entry=0x0, argv=argv@entry=0x5555561d2690, envp=0x5555562aea40, close_descriptors=1, search_path=0, search_path_from_envp=0, stdout_to_null=0, stderr_to_null=0, child_inherits_stdin=0, file_and_argv_zero=0, child_setup=0x7ffff5b29250 <on_gnupg_process_child_setup>, user_data=0x7fffffffb540) at gspawn.c:1229
#3  0x00007ffff504a263 in fork_exec_with_pipes (intermediate_child=intermediate_child@entry=0, working_directory=0x0, argv=0x5555561d2690, envp=0x5555562aea40, close_descriptors=close_descriptors@entry=1, search_path=search_path@entry=0, search_path_from_envp=0, stdout_to_null=0, stderr_to_null=0, child_inherits_stdin=0, file_and_argv_zero=0, cloexec_pipes=0, child_setup=0x7ffff5b29250 <on_gnupg_process_child_setup>, user_data=0x7fffffffb540, child_pid=0x7fffffffb514, standard_input=0x7fffffffb510, standard_output=0x7fffffffb508, standard_error=0x7fffffffb50c, error=0x7fffffffb518) at gspawn.c:1426
#4  0x00007ffff504ace5 in g_spawn_async_with_pipes (working_directory=<optimized out>, argv=<optimized out>, envp=<optimized out>, flags=flags@entry=G_SPAWN_DO_NOT_REAP_CHILD, child_setup=child_setup@entry=0x7ffff5b29250 <on_gnupg_process_child_setup>, user_data=user_data@entry=0x7fffffffb540, child_pid=0x7fffffffb514, standard_input=0x7fffffffb510, standard_output=0x7fffffffb508, standard_error=0x7fffffffb50c, error=0x7fffffffb518) at gspawn.c:656
#5  0x00007ffff5b2af09 in _gcr_gnupg_process_run_async (self=0x55555629f170 [GcrGnupgProcess], argv=argv@entry=0x7fffffffb5b0, envp=envp@entry=0x0, flags=flags@entry=GCR_GNUPG_PROCESS_WITH_STATUS, cancellable=cancellable@entry=0x55555622a370 [GCancellable], callback=callback@entry=0x7ffff5b27920 <on_process_run_complete>, user_data=0x5555562de190) at gcr/gcr-gnupg-process.c:1041
#6  0x00007ffff5b278ea in _gcr_gnupg_importer_import_async (importer=<optimized out>, cancellable=0x55555622a370 [GCancellable], callback=0x7ffff7781cd0 <on_import_complete>, user_data=0x5555560c6830)
    at gcr/gcr-gnupg-importer.c:332
#7  0x00007ffff77818eb in gcr_import_button_clicked (button=<optimized out>)
    at ui/gcr-import-button.c:478
#8  0x00007ffff52db614 in _g_closure_invoke_va (closure=closure@entry=0x555555a0e290, return_value=return_value@entry=0x0, instance=instance@entry=0x5555560c6830, args=args@entry=0x7fffffffb890, n_params=<optimized out>, param_types=0x0) at gclosure.c:867
#9  0x00007ffff52f5dd9 in g_signal_emit_valist (instance=0x5555560c6830, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffb890) at gsignal.c:3300
#10 0x00007ffff52f643f in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3447
#11 0x00007ffff6f7478d in gtk_button_do_release (button=0x5555560c6830 [GcrImportButton], emit_clicked=<optimized out>) at gtkbutton.c:1843
#12 0x00007ffff6f747f5 in gtk_real_button_released (button=0x5555560c6830 [GcrImportButton])
    at gtkbutton.c:1961
#13 0x00007ffff52db614 in _g_closure_invoke_va (closure=closure@entry=0x555555a0e180, return_value=return_value@entry=0x0, instance=instance@entry=0x5555560c6830, args=args@entry=0x7fffffffbbf0, n_params=<optimized out>, param_types=0x0) at gclosure.c:867
#14 0x00007ffff52f5dd9 in g_signal_emit_valist (instance=0x5555560c6830, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffbbf0) at gsignal.c:3300
#15 0x00007ffff52f643f in g_signal_emit (instance=instance@entry=0x5555560c6830, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447
#16 0x00007ffff6f72be0 in multipress_released_cb (gesture=0x555556236260 [GtkGestureMultiPress], n_press=<optimized out>, x=<optimized out>, y=<optimized out>, widget=0x5555560c6830 [GcrImportButton])
    at gtkbutton.c:666
#17 0x00007fffee491c58 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#18 0x00007fffee4916ba in ffi_call (cif=cif@entry=0x7fffffffbf50, fn=fn@entry=0x7ffff6f72bc0 <multipress_released_cb>, rvalue=<optimized out>, avalue=avalue@entry=0x7fffffffbe20) at ../src/x86/ffi64.c:525
#19 0x00007ffff52dc0fa in g_cclosure_marshal_generic_va (closure=0x5555561fb3a0, return_value=0x0, instanQuit

If you need more details (full backtrace), please give me an email address + PGP key to send/encrypt to.
Comment 14 Kalev Lember 2017-01-24 23:29:58 EST
Aha! Looks like gcr is compiled to use /usr/bin/gpg instead of gpg2.
Comment 15 Fedora Update System 2017-01-24 23:53:16 EST
gcr-3.20.0-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb86e0feb
Comment 16 Kalev Lember 2017-01-24 23:54:05 EST
Can you try again with the linked gcr update, please?
Comment 17 Fedora Update System 2017-01-27 23:52:48 EST
gcr-3.20.0-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb86e0feb
Comment 18 Fedora Update System 2017-01-28 19:21:13 EST
gcr-3.20.0-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.