Bug 197837 - mail/spamassassin dependency on gpg1
Summary: mail/spamassassin dependency on gpg1
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Adam Weinberger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-19 22:23 UTC by Will
Modified: 2015-03-13 17:53 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (adamw)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will 2015-02-19 22:23:21 UTC
The spamassassin port requires gnupg1 when built with the option to check GPG keys in sa-update, but I imagine it should be able to work with gnupg (which now defaults to gnupg2) also. This ends up blowing away my earlier installation of gnupg2 as the default 'gpg' etc. in my path.
Comment 1 Bugzilla Automation freebsd_committer 2015-02-19 22:23:21 UTC
Auto-assigned to maintainer adamw@FreeBSD.org
Comment 2 Adam Weinberger freebsd_committer 2015-02-19 22:39:54 UTC
You can change the name of the binary that sa-update calls on line 345 of /usr/local/bin/sa-update. Alternatively, you can alter your $PATH to place a symlink from gpg to gpg2 ahead of /usr/local/bin.

The gnupg2 and gnupg20) ports do not install a gpg binary. If you created that symlink yourself I cannot help that the gnupg1 port overwrote that link.

The spamassassin port defaults to using the gpg version that the manual indicates it was written for and tested with.
Comment 3 Will 2015-02-19 22:50:42 UTC
Installing the gnupg2 package does seem to put the symlink there for me with no additional intervention (see 2nd set of output below), making 'gpg' gnupg2. Installing gnupg1 overwrites this, causing the unexpected behavior that the 'gpg' in one's path is now v1 instead of v2. Feel free to pass this on to the maintainers of gnupg if you think this is an issue on their end.

===>   Registering installation for gnupg1-1.4.18_2
Installing gnupg1-1.4.18_2...
root@aura:/usr/ports/security/gnupg1 # ls -al /usr/local/bin/gpg
-r-xr-xr-x  1 root  wheel  942560 Feb 19 14:49 /usr/local/bin/gpg


root@aura:/usr/ports/security/gnupg # make deinstall
===>  Deinstalling for gnupg
===>   Deinstalling gnupg-2.1.2
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
	gnupg-2.1.2

The operation will free 4 MB.
[1/1] Deinstalling gnupg-2.1.2...
[1/1] Deleting files for gnupg-2.1.2: 100%
root@aura:/usr/ports/security/gnupg # ls -al /usr/local/bin/gpg
ls: /usr/local/bin/gpg: No such file or directory
root@aura:/usr/ports/security/gnupg # make install
===>  Installing for gnupg-2.1.2
===>   gnupg-2.1.2 depends on package: pinentry>0 - found
===>   gnupg-2.1.2 depends on executable: indexinfo - found
===>   gnupg-2.1.2 depends on shared library: libassuan.so - found (/usr/local/lib/libassuan.so.0.4.3)
===>   gnupg-2.1.2 depends on shared library: libgcrypt.so - found (/usr/local/lib/libgcrypt.so.20.0.2)
===>   gnupg-2.1.2 depends on shared library: libksba.so - found (/usr/local/lib/libksba.so.8.11.3)
===>   gnupg-2.1.2 depends on shared library: libnpth.so - found (/usr/local/lib/libnpth.so.0.0.4)
===>   gnupg-2.1.2 depends on shared library: libgnutls.so - found (/usr/local/lib/libgnutls.so.28.30.12)
===>   gnupg-2.1.2 depends on shared library: libiconv.so - found (/usr/local/lib/libiconv.so.2.5.1)
===>  Checking if gnupg already installed
/usr/local/lib/libassuan.so.0.4.3
/usr/local/lib/libgcrypt.so.20.0.2
/usr/local/lib/libksba.so.8.11.3
/usr/local/lib/libnpth.so.0.0.4
/usr/local/lib/libgnutls.so.28.30.12
/usr/local/lib/libiconv.so.2.5.1
/usr/local/bin/indexinfo
===>   Registering installation for gnupg-2.1.2
Installing gnupg-2.1.2...
###############################################################################
				A T T E N T I O N

In order to use gpg-agent, you need to install a pinentry dialog.

The following ports of pinentry dialogs are available:

security/pinentry-curses	(ncurses based dialog)
security/pinentry-gtk2		(GTK 2.x based dialog)
security/pinentry-qt4		(QT4 based dialog)

###############################################################################

===> SECURITY REPORT: 
      This port has installed the following files which may act as network
      servers and may therefore pose a remote security risk to the system.
/usr/local/bin/watchgnupg

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.

      For more information, and contact details about the security
      status of this software, see the following webpage: 
http://www.gnupg.org/
root@aura:/usr/ports/security/gnupg # ls -al /usr/local/bin/gpg
lrwxr-xr-x  1 root  wheel  4 Feb 19 14:47 /usr/local/bin/gpg -> gpg2
Comment 4 Adam Weinberger freebsd_committer 2015-02-19 23:03:47 UTC
Hrmmn. That is very interesting. /usr/ports/security/gpg/pkg-install shouldn't be creating that link if the gpg binary already exists.

I'll have to do some investigating there.
Comment 5 Will 2015-02-19 23:06:43 UTC
I could be wrong, but in my case, I think it has to do with gnupg2 being installed already, and then gnupg1 getting installed along with upgrading SpamAssassin (as a dependency).

That is, if you install / upgrade gnupg to 2 (such that only security/gnupg is installed), then install SA (which installs gnupg1 as a dependency, it seems to overwrite the symlink without warning the user that the default 'gpg' is now v1 instead of v2.
Comment 6 Adam Weinberger freebsd_committer 2015-02-19 23:18:23 UTC
You're right. I was focusing on the wrong part of your output there.

Everything you're saying is correct---gnupg creates the link, but gpg1 writes bin/gpg as its own binary.

spamassassin depends on the version of gnupg it was written for, and gpg1 writes to the binary it expects to use.

I think that, technically, the answer is that things that expect to use gpg2 should be calling gpg2 specifically, not counting on the gpg symlink. I know that's not a satisfying answer.
Comment 7 Adam Weinberger freebsd_committer 2015-03-13 17:53:22 UTC
Should be fixed in r381227. Let me know if this doesn't resolve the issue satisfactorily.
Comment 8 commit-hook freebsd_committer 2015-03-13 17:53:41 UTC
A commit references this bug:

Author: adamw
Date: Fri Mar 13 17:52:47 UTC 2015
New revision: 381227
URL: https://svnweb.freebsd.org/changeset/ports/381227

Log:
  Allow depending on gpg2 instead of gpg1.

  Inspired by:
  PR:		197837
  Submitted by:	bogus19@veggiechinese.net

Changes:
  head/mail/spamassassin/Makefile