Bug 209596

Summary: mail/fetchmail: mis-detects sslv2 on 11.x and openssl from ports, fails to build
Product: Ports & Packages Reporter: Peter Wemm <peter>
Component: Individual Port(s)Assignee: Matthias Andree <mandree>
Status: Closed FIXED    
Severity: Affects Many People CC: chalpin, mandree
Priority: --- Flags: chalpin: maintainer-feedback+
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Disable SSLv2.
none
alternative patch to disable import of the SSLv2_client_method symbol chalpin: maintainer-approval+

Description Peter Wemm freebsd_committer freebsd_triage 2016-05-18 03:31:28 UTC
Created attachment 170422 [details]
Disable SSLv2.

The configure script checks for SSLv2_method() being present in <openssl/ssl.h>.  This is visible unless you compile with -DOPENSSL_NO_SSL2_METHOD.  We don't have the SSLv2_method present in the library so the include file check gives a false positive.

The easiest way I found to fix it was to simply prevent sslv2 from being detected.  In 2016, this should absolutely be the case anyway.

The trivial fix I came up with is attached.
Comment 1 Peter Wemm freebsd_committer freebsd_triage 2016-05-18 03:34:33 UTC
The compile failure that shows the mis-detection of SSLv2:

cc  -O2 -pipe  -fstack-protector -fno-strict-aliasing -I/usr/kerberos/include -I/usr/include  -L/usr/local/lib  -fstack-protector -L/usr/lib -L/usr/lib -o fetchmail socket.o getpass.o fetchmail.o env.o idle.o options.o daemon.o driver.o transact.o sink.o smtp.o idlist.o uid.o mxget.o md5ify.o cram.o gssapi.o opie.o interface.o netrc.o unmime.o conf.o checkalias.o lock.o rcfile_l.o rcfile_y.o norm_charmap.o  pop3.o imap.o etrn.o odmr.o  rpa.o   libfm.a /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib   -lopie -lcrypt  -lkvm -lcom_err  -lssl -lcrypto  -L/usr/lib -lgssapi -lgssapi_krb5 -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -lwind -lheimbase -lroken -lcrypt -pthread
socket.o: In function `SSLOpen':
socket.c:(.text+0x11fd): undefined reference to `SSLv2_client_method'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Comment 2 Corey Halpin 2016-05-21 16:30:06 UTC
Looks good to me.  Thank you!
Comment 3 Matthias Andree freebsd_committer freebsd_triage 2016-05-22 12:49:56 UTC
Created attachment 170544 [details]
alternative patch to disable import of the SSLv2_client_method symbol

Alternative approach since Peter's does not appear to work on FreeBSD 10.3-RELEASE (which checks for OPENSSL_NO_SSL2 instead - note the missing _METHOD suffix) is to preload the autoconf cache.  (Sorry Corey, I figured that only when reviewing before the commit.)
Comment 4 Matthias Andree freebsd_committer freebsd_triage 2016-05-22 12:51:09 UTC
(Peter@, feel free to reassign the bug to yourself if Corey as the maintainer has approved of my patch.)
Comment 5 Corey Halpin 2016-05-24 13:41:21 UTC
Comment on attachment 170544 [details]
alternative patch to disable import of the SSLv2_client_method symbol

Passes 'poudriere testport' on 9.3, 10.1, and 10.3 for amd64; looks good to me. Thank you!
Comment 6 commit-hook freebsd_committer freebsd_triage 2016-05-24 20:33:54 UTC
A commit references this bug:

Author: mandree
Date: Tue May 24 20:32:55 UTC 2016
New revision: 415811
URL: https://svnweb.freebsd.org/changeset/ports/415811

Log:
  Disable SSLv2, to fix new/from-ports OpenSSL builds.

  Newer and ports-based builds define the SSLv2_client_method() in the
  headers unless OPENSSL_NO_SSL2, or, depending on version,
  OPENSSL_NO_SSL2_METHOD is defined, however newer OpenSSL versions in
  FreeBSD no longer provide the implementation in the library.

  Preload the autoconf (configure) cache to pretend SSLv2_client_method()
  were universally _un_available, effectively disabling SSLv2 altogether.

  PR:		209596
  Submitted by:	peter@ [first proposal], mandree@ [committed proposal]
  Reported by:	peter@
  Approved by:	chalpin@cs.wisc.edu (maintainer)

Changes:
  head/mail/fetchmail/Makefile
Comment 7 Matthias Andree freebsd_committer freebsd_triage 2016-05-24 21:30:21 UTC
Peter, Corey, if you think this should be MFH'd to the 2016Q2 ports branch, please drive that effort forward yourselves, my interest in 11-CURRENT is (currently) near zero.  It appears that it fixes a -HEAD build failure and thus qualifies for a MFH.