Description of problem: If you use gnupg*2* (and gnupg is not installed), git tag complains with the misleading error message: | error: gpg did not accept the tag data | error: unable to sign the tag while an strace shows that it tried to find a "gpg" binary in the path and didn't succeed. Version-Release number of selected component (if applicable): git-1.6.2.5-1.fc11.i586 gnupg2-2.0.12-1.fc11.i586 How reproducible: Always. Steps to Reproduce: 1. Set up a git repository. 2. Try to tag HEAD with "git tag -u 0xC3732903 -m 'Test.' test-tag". Actual results: See above. Expected results: Signed tag. Additional info: If you create a soft link $PATH/gpg -> /usr/bin/gpg2, "git tag" works. Besides the misleading error message, git either should test whether gpg2 is available or provide a configuration option to set which gpg executable to use.
The error message in current git is better. From an F-12 box with git-1.6.6.1-1.fc12: error: cannot run gpg: No such file or directory error: gpg did not accept the tag data error: unable to sign the tag (And that's after manually moving gpg aside, as gnupg2 creates that in F-12.) While it would be good if this was configurable, to do it properly would require not only allowing configuration of the path to gpg, it should also allow configuring the options passed. That would allow someone to use a script or other tool to create the signatures. Of course, that's far more work than would be appropriate for our packages and should be handled upstream. I'm inclined to say that not having gpg in your path is a configuration problem and that since the error message is improved in more recent git versions, that this bug should be closed. I don't have time to implement the config setting for the gpg path, but if you do, please submit or suggest it upstream. Is that reasonable?
I'd rather prefer to have F12's "gpg2 is gpg" behaviour, but looking at the .spec I couldn't figure out where that is done. Any pointers?
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 WONTFIX if it remains open with a Fedora 'version' of '11'. 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 prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still a problem in Fedora 19.
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.
This is still a problem in Fedora 21.
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.
seems to be in fedora 23 as well
Does indeed affect Fedora 23 too. Keys made using Seahorse will be gpg2 so this will increasingly be an isue going forward.
Work-around for anyone affected: git config --global gpg.program gpg2
Hi guys, in my point of view, I could add gnupg as requires (at least optional) which solves the bug too, or ask upstream to set gpg2 as default. I'll check mailing list if this was discussed in upstream earlier. But if you don't want to have gnupg installed on your system and just use gnupg2, set correctly gpg.program as mentioned above.
*** Bug 1309175 has been marked as a duplicate of this bug. ***
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.
I guess this will be problem in newer version of Fedora then F23, just I haven't test it yet.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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.
It seems this is still going to be a problem for users until gpg2 is the default, either Fedora-wide, or for git.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
These days, git clearly says error: cannot run gpg: No such file or directory Upstream default won't change soon (for good reasons). As for the packaging, one could argue about recommending or requiring gnupg or gnupg2 (and changing gpg.program in the latter case), but given the migration path from gpg to gpg2.1+ this is a personal user decision, especially as long as there are still packages which require gnupg (1).
It would be nice to see "Suggests: gnupg2" in the Fedora packaging, and the default value of gpg.program set to gpg2 (with a patch, if necessary). This would make everything work nicely for Fedora users out-of-the-box. (The "Suggests:" is really just a formality... Fedora default installation includes gnupg2 already.) The problem with having the default (or an explicit value) be 'gpg' is that it will not work with Fedora's default desktop (GNOME) which runs a gpg-agent on the default socket (with gpg2) and no longer sets the appropriate agent environment variables for the 'gpg' command to find the agent. Certainly, it is a personal user decision to use their preferred gpg.program, and git should continue to support setting that on a per-user basis, but it is reasonable to have a default in Fedora that provides a good out-of-box experience. It is *not* reasonable for all new installations to be broken by default, and users to have to Google, find this issue, and apply the workaround.
*** Bug 1449901 has been marked as a duplicate of this bug. ***
for me it was pure luck to figure this out eventually (i even reported an issue because i didn't find this one) from my point of view fedora has turned gpg into a unsupported piece of suffering for the users without documenting the need to migrate to gpg2 for fedora "supported" tools in a way they an discover it when things go wrong i consider this downright hostile to the user because the necessary information is anything but easy to find, i'm aware of people that suffer from this decision since years and had given up on finding a solution one has to ask what thew heck is wrong when there is next to no documentation about a package that is intentionally not configured to use the supported and integrated tool when fedora chooses to correctly integrate gpg2 while making gpg1 a unsupported side-player, then it has a responsibility to encourage and enable the tool migration as well instead of leaving people suffering in the dark most community support channels are entirely unaware of this deliberate disservice and at least on freenode people tried to help me fix my gpg (which of course completely failed) i am very disappointed with the handling of this problem
To anyone who rambles here: please complain to the gnupg project for the broken upgrade path from gnupg 1 to gnupg 2.1 that messes up any attempts at controlled, automatic side-by-side installation. As for the fedora git package: defaulting to gpg2 would not be a problem on the git side. But look at this: "dnf erase gnupg" on a current F25 removes 35 packages for me, among them NetworkManager-team and -wifi, anaconda, bcache-tools, hplip. If you are interested in helping then please check what in fedora still depends on gnupg (the 1-version), check whether these packages work with gnupg2 and prod the packagers to move those packages to gnupg2. With the current state of affairs, changing the git package in fedora would help some but hurt others. In particular, it would migrate users' secret key stores behind their back as soon as they run a git command that invokes gpg2. That is a much more severe problem than git failing to call gpg for a user who has migrated to gpg2 actively, creating a gpg.conf that is shared with gpg(1) but unparsable for gpg(1). Besides, the bug report as phrased here is clearly a report for upstream (where the report was discussed and the default stays as is for the same reasons).
so how should i phrase a new bug that wont get closed as duplicate, this is a problem since 7 years - upstream is broken and the integration is in mental dissonance it should be easy to discover about the need to switch, not random luck on a hidden issue somewhere in issue tracker it took me weeks to stumble upon this issue, even the community support tried to prod me into the wrong direction (fixing gpg on fedora, which is impossible, instead of switching to gpg2) i'm totally fine with not having a upstream/technical solution, but why is this not documented in a really discoverable way (because trying to figure why the gpg agent is strange doesn't work out very well) if one knows, it takes like 5 minutes to make git with auto-sign work very pleasantly, but if one doesn't know it takes weeks and luck to find the related issues, i do know some people that just gave up on that
The error from git should no longer be terribly confusing, which was a good part of the original issue here. As Michael said, changing the default in the fedora package would hurt some just as it helps some others, so it's not a simple as changing it. We'd end up with more bugs filed saying gpg support in git is now broken. I toyed around a bit last week with various alternative ways to try and improve this situation. If the git config include feature took a directory, we could potentially use it to include /etc/gitconfig.d and then have some package (likely something pulled in per-fedora-product, so workstation and server could differ, for example) install /etc/gitconfig.d/gnupg2.conf. That's not feasible right now and it's not a perfect solution in any case. The closest thing I came up with is a patch I'll attach. This adds a README.Fedora.md file with a section on GnuPG explaining how to set the gpg.program. It also adds a git-gnupg2 subpackage which contains a %post script to set gpg.program to gpg2. This is something that could be installed by destkop spins which expect gpg2 to be the default gpg implementation. Changing the default to gpg2 and breaking current users (as well as deviating from upstream) is not a good solution, IMO.
Created attachment 1283222 [details] Add subpackage to enable gpg2 as default gpg.program
having a package that manages it correctly is already a huge enhancement, thanks ! whats now missing is a easy google-able way so people can more easily find the solution or package (this might need posting on a few communities) because at least i wouldn't be searching in the git README if my gpg agent "does not work"
The solution in the patch seems really good to me. It is better than current situation and can be used until the gnupg2 will not be supported by all packages in Fedora or upstream will not set gnupg2 as default.
For what it's worth, it seems the upstream developers intended for gpg2 to replace gpg. If you don't set the flag --enable-gpg2-is-gpg, upstream's configure.ac calls it a "hack" (USE_GPG2_HACK) to have the gpg2 binary named "gpg2" instead of "gpg". One Debian developer has informed me that they are hitting some pain points transitioning away from co-installation of gpg and gpg2, to just gpg2, but that they consider co-installation a larger pain point. I think this issue is evidence of that. As are all the issues with the new public key database format in 2.1.
This issue will mostly resolve itself when Fedora begins shipping gnupg2 as gpg (likely with gpg2 as a symlink to gpg and gnupg1 as gpg1). This was discussed most recently on the devel list here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BCJ2CXNDJ5VX32PVGK567AJ5LCRHGWUN/ The summary from that thread and the links included there is that upstream GnuPG developers are planning to ship the next gnupg-1.4 release which installs gpg by default as gpg1. It's not clear what release of Fedora will see this change, perhaps it'll be done in f28 (with or without waiting for the upstream gnupg-1.4 release, as Debian has done already). In light of this, I don't think that there's anything we can or should change in the git packaging. None of the potential changes we can make are suitable to ship without causing users of gpg or gpg2 pain. I think we should close this ticket and let the problem be resolved with the system-wide change that moves gpg to gpg2 by default. That will receive more attention and allow all users to adjust their tools/scripts as needed. Ideally, we'll be able to include documentation in the release notes for that system-wide change telling users how to revert back to gpg1 with git if that's desired. For now, the recommended solution for users who are using gpg2 is to set gpg.program via git config, as mentioned in earlier comments: git config --global gpg.program gpg2