If you attempt to decrypt an RSA-encrypted file with gnupg2 (installed with pkg install gnupg), it fails, like so: gpg-agent[3875]: can't connect to the PIN entry module: IPC connect call failed gpg-agent[3875]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry pkg install pinentry fixes the problem. But clearly the gnupg package needs pinentry as a dependency.
This failed to auto-assign because security/gnupg wasn't in the title. Assigning to maintainer now. pinentry is an option (which is off) so if this PR is correct, it should be unconditional (not option, not default option)
Without pinentry, you can't decrypt, because gnupg has no mechanism for collecting your passphrase. So unless you want to treat your encrypted files as write-only memory, pinentry needs to be an unconditional dependency.
I usually uses gpg as encrypt only on remote server, then transfer to backup storage server (which has pinentry). I just committed to turn PINENTRY option ON by default. Is it enough? Or you still feel PINENTRY should be installed unconditionally in such situation?
I turned PINENTRY off and gpg fails to sign anything: (marcus@medusa ~)> gpg --sign bar.txt gpg: signing failed: No pinentry gpg: signing failed: No pinentry This is a problem, if one uses e.g. mutt or some other program, which does not integrate pinentry.
Yes, signing requires private key, encryption is not. Anyway, change like this sometimes requested over years. I'm giving up and will commit depending on pinentry. Stay tuned.
A commit references this bug: Author: kuriyama Date: Sat Nov 22 09:53:17 UTC 2014 New revision: 373042 URL: https://svnweb.freebsd.org/changeset/ports/373042 Log: - Turn pinentry dependency mandatory, not option. PR: ports/194788 Submitted by: donaldcallen@gmail.com Changes: head/security/gnupg20/Makefile
A commit references this bug: Author: kuriyama Date: Sat Nov 22 09:55:14 UTC 2014 New revision: 373043 URL: https://svnweb.freebsd.org/changeset/ports/373043 Log: - Turn pinentry dependency mandatory, not option. [1] - Remove gpg-zip.1.gz manpage which command is not installed. [2] PR: ports/194788 [1], ports/195229 [2] Submitted by: donaldcallen@gmail.com [1], crest@sahiro.org [2] Changes: head/security/gnupg/Makefile head/security/gnupg/files/ head/security/gnupg/files/patch-doc-Makefile.in head/security/gnupg/pkg-plist
Fix committed. Thanks1
I think this change should be reverted. gnupg explicitly states that one of security/pinentry* must be installed. Package users can't easily switch from one alternative package to another. Forcing dependency on particular pinentry dialog will always leave some users unsatisfied with the default choice, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195475 for example.
(In reply to Max Brazhnikov from comment #9) > I think this change should be reverted. gnupg explicitly states that one of > security/pinentry* must be installed. Package users can't easily switch from > one alternative package to another. Forcing dependency on particular > pinentry dialog will always leave some users unsatisfied with the default > choice, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195475 for > example. As opposed to having *everyone* be dis-satisfied because their encrypted files can't be decrypted without doing some system administration. If someone hates the default pinentry, they can fix it. I think this change will annoy a lot less people than was the case without it. I have never seen this problem on a Linux system (I use Slackware; Mint for my wife, and Arch in the past, until I got sick of issues with systemd).
Another vote for reverting. When one installs gnupg, a very prominent banner is displayed (http://svnweb.freebsd.org/ports/head/security/gnupg/pkg-message?revision=340719&view=markup) indicating the need to install one of the pinentry* packages. It is not appropriate to force all gnupg users, many of whom are on headless servers, to install ~200 MB of unnecessary gtk/X stuff because some people don't heed the pkg-message.
This is quite remarkable. I read the installation warning and installed pinentry-ncurses. Another person did not read the warning, and eventually discovered he could fix it by installing pinentry. This should have been sufficient, but instead he also came here to demand that *everyone else* must install pinentry! What if I had come first and suggested that everyone install pinentry-ncurses? Or pinentry-qt? What if I don't need to decrypt or sign on this machine and thus don't need any form of pinentry at all? Not everyone's use case is the same. This should be reverted to allow us to choose what is best for us. BTW, since Linux comparison has been made, Arch gnupg depends on a package that is essentially the equivalent of FreeBSD's pinentry-ncurses, which seems to be the most sane choice, if we are going to force something on the entire userbase, but again I don't think we should force a choice at all.
I agree, your comment is quite remarkable. In its distortions. I DEMANDED nothing. I submitted a report about what I considered (and consider) a bug. The decision-makers at FreeBSD could have said "not a bug" and closed it. Instead, they chose to implement what I suggested. What you people are suggesting is like delivering a car without a steering wheel, with a little note in the glove-box saying "if you'd like to drive the car, you'll need to install a steering wheel".
(In reply to donaldcallen from comment #13) Demanded was possibly not the right word. But like all car analogies, yours is flawed, and I will not attempt to fix it. Instead, I will again remind you that the pkg-message warning is quite large and not at all hidden. That it lists several options, and the one you have chosen (arbitrarily? would you care to explain why pinentry is the One Right Choice, rather than pinentry-ncurses or pinentry-qt?) is one of the largest and most intrusive of them all, pulling in dozens of unneeded packages--and potential vulnerabilites--for many server admins. And that despite your continued belief that gnupg was crippled before this change, there is at least one person in this thread who was able to use gnupg perfectly for their purpose without any form of pinentry installed. For all these reasons, I submit that this is indeed Not A Bug and should be reverted. Incidentally, I am not sure why you are so adamant that this change stand. Even if it reverts, your having installed pinentry (as instructed by the pkg-message) will allow you to continue to upgrade via the pkg system with no additional effort -- forever. I did not find a flood of recent reports from "everyone" who you claim was dissatisfied prior to this PR. Instead, I see the opposite -- multiple comments from users who are essentially being forced out of the pkg system to ports because of this dependency change.
(In reply to proof.of.concept from comment #14) > (In reply to donaldcallen from comment #13) > > Demanded was possibly not the right word. But like all car analogies, yours > is flawed, and I will not attempt to fix it. > > Instead, I will again remind you that the pkg-message warning is quite large > and not at all hidden. That it lists several options, and the one you have > chosen (arbitrarily? would you care to explain why pinentry is the One > Right Choice, rather than pinentry-ncurses or pinentry-qt?) is one of the > largest and most intrusive of them all, pulling in dozens of unneeded > packages--and potential vulnerabilites--for many server admins. And that > despite your continued belief that gnupg was crippled before this change, > there is at least one person in this thread who was able to use gnupg > perfectly for their purpose without any form of pinentry installed. > > For all these reasons, I submit that this is indeed Not A Bug and should be > reverted. > > Incidentally, I am not sure why you are so adamant that this change stand. > Even if it reverts, your having installed pinentry (as instructed by the > pkg-message) will allow you to continue to upgrade via the pkg system with > no additional effort -- forever. I did not find a flood of recent reports > from "everyone" who you claim was dissatisfied prior to this PR. Instead, I > see the opposite -- multiple comments from users who are essentially being > forced out of the pkg system to ports because of this dependency change. This is a discussion about default behavior, nothing more. Whatever default is chosen can be altered by the user if it is considered inappropriate. Coming from Linux (I use Slackware, but have recent experience with gnupg on Arch, Debian, Mint, and Ubuntu systems), I found it surprising that the most straight-forward use of gnupg resulted in my not being able to decrypt a file I'd previously encrypted. To me, that default configuration was completely inappropriate and I fixed it, by installing pinentry. So was this an unmitigated disaster? Of course not. I just had to do some work that I didn't expect to have to do and that, in my opinion, I shouldn't have had to do, to get a working configuration of gnupg. Similarly, if you were to encounter the situation created by this change and disagreed with the default installation of pinentry, you could fix it, by uninstalling, or replacing it with your favorite flavor of pinentry. It's simply a matter of the over-worked term 'user-friendliness'. You choose defaults to try to get the right setup for the largest number of users. Yes, it's frequently guess-work, but the providers of at least five good Linux distributions set the default the way I am advocating here. I've also used OpenBSD more than a bit in the last five years (though not recently) and unless my memory is failing me, I never ran into this situation with that system. As for the "prominent" message when installing gnupg, like most people, when installing FreeBSD or any OS, I have a need for a set of applications. That set is pretty large, and so I have a script to do the installs in batch mode. Pretty standard Unix practice. Downloading and installing all of them is time-consuming and I do not sit in front of the screen reading every word that goes by. I have better things to do with my time. As for tee-ing the output to a file for review later, there is too much of it to sift through looking for possible problems. If there is a problem with the installation of an application, I will find out about it when I try to use, as was the case with gnupg. Lastly, I am not "adamant" about this. I am a very casual user of FreeBSD. I've tried it multiple times over the years, starting with the 7.x series. I have run into show-stoppers every time. It also does not support essential bits of hardware on machines I use a lot (I'm typing this on an Intel Atom box I built; FreeBSD does not deal with the integrated Intel graphics hardware correctly; I'm running Slackware on this machine; I have a Thinkpad T430; there is no driver for the wireless hardware in FreeBSD; again, Slackware on that machine). But I have a spare Lenovo workstation that I rarely use (it's too noisy and I only need the speed on occasion), and so I use it to occasionally see what is happening with OSes/Linux distributions that I don't regularly use. I have FreeBSD 10.1 installed on it at the moment, and so far, it is working well, my first positive experience with FreeBSD. It was there that I encountered this gnupg issue. Because of the lack of drivers, I can't use FreeBSD on my main machines even if I wanted to. So my stake in this is minimal. I don't think the default setup for gnupg makes sense and I filed a bug report saying so. But if you, as a community, decide to revert this, I will manage to deal with it, with support from friends and family :-)
I agree that security/gnupg should depend on a version of pinentry. This version of pinentry should in my opinion be the minimalistic version of pinentry. Or better yet, it should depend on security/pinentry, which depends on either pinentry-gtk2, pinentry-curses, or even pinentry-qt. Installing security/pinentry would then install (preferably) pinentry-curses, but if you have pinentrey-gtk2 already installed, then it should use pinentry-gtk2. When I was still using Gentoo, it did this by using "virtual" packages. FreeBSD has a mechanism called "meta-ports". For example, python packages use this. You install python27 and it installs /usr/local/bin/python27. You can pkg install python2, which only creates a symlink in /usr/local/bin/python2 -> python27. You can even pkg install python which only creates a symlink in /usr/local/bin/python -> python2. A similar solution would be preferable to me: pkg install pinentry, and it will install pinentry-curses if no pinentry is yet installed, else it will symlink to the installed version of pinentry. This is what I proposed in the security/pinentry bug report. With the current situation my system is still functional, but not in an optimal form. I installed pinentry from source using the ports collection where I disabled gtk2 support. This required some other ports (gmake, dialog4ports, etc). Some of these ports I will never use again, so they are unnecessary, but not that big a deal. What annoys me more is that when I now wish to upgrade my installed packages with `pkg upgrade`, it says that it needs to reinstall pinentry (options changed) and will pull in all the GTK2 dependencies again. I do not want these packages; I do not need these packages. In effect, my system is now broken, because I cannot upgrade my installed packages without cherry-picking the list and upgrading each package manually. Please fix this soon; my system is now a maintenance nightmare.
(In reply to Wybe van der Ham from comment #16) > When I was still using Gentoo, it did this by using "virtual" packages. > FreeBSD has a mechanism called "meta-ports". meta ports are not exact equivalent to Gentoos virtuals. I wish we could have them. > For example, python packages > use this. You install python27 and it installs /usr/local/bin/python27. You > can pkg install python2, which only creates a symlink in > /usr/local/bin/python2 -> python27. You can even pkg install python which > only creates a symlink in /usr/local/bin/python -> python2. The example is not correct. python2 already depends on python27 package and python27 will be installed when you install python2. > A similar solution would be preferable to me: pkg install pinentry, and it > will install pinentry-curses if no pinentry is yet installed, else it will > symlink to the installed version of pinentry. This is what I proposed in the > security/pinentry bug report. pkg can't optionally install packages: if pinentry package (built from meta port) depends on pinentry-curses, pinentry-curses will be always installed as dependency. The problem simply moves from gnupg port to pinentry meta port. All that I can do right now is to convert pinentry port into stub port, which installs nothing, but advises users to manually install pinentry-* port of their choise, or remove the port completely.
Either change is fine with me (though as you say, it just moves the issue around, and thus reversion here probably makes the most sense). Please do something though, as FreeBSD is now the only OS that requires the installation of a GUI/widget library as a prerequisite for its gnupg package. I've had to lock the gnupg package for three of our weekly maintenance cycles now. It would be nice to hear from Jun on if/when some change could be expected. Thanks.
I've reworked the pinentry ports, see my mail for details: http://lists.freebsd.org/pipermail/freebsd-ports/2014-December/097209.html
(In reply to Max Brazhnikov from comment #19) > I've reworked the pinentry ports, see my mail for details: > http://lists.freebsd.org/pipermail/freebsd-ports/2014-December/097209.html Thank you! This is a nice present under the Christmas tree. I will give it a try as soon as the binary packages are available. Also the pinentry-tty is a welcome extra!
I've converted security/pinentry to meta-alike port that depends on pinentry-tty by default. Besides pinentry-* ports can be co-installed now. Committed in r375494.
(In reply to Max Brazhnikov from comment #21) > I've converted security/pinentry to meta-alike port that depends on > pinentry-tty by default. Besides pinentry-* ports can be co-installed now. > Committed in r375494. Sanity restored. Many thanks to Max for his efforts in curtailing this package bloat. Happy new year!