From areilly@bigpond.net.au  Sat Apr 17 03:39:02 2010
Return-Path: <areilly@bigpond.net.au>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B29CD1065675
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 17 Apr 2010 03:39:02 +0000 (UTC)
	(envelope-from areilly@bigpond.net.au)
Received: from nschwmtas02p.mx.bigpond.com (nschwmtas02p.mx.bigpond.com [61.9.189.140])
	by mx1.freebsd.org (Postfix) with ESMTP id 3ED178FC23
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 17 Apr 2010 03:39:01 +0000 (UTC)
Received: from nschwotgx01p.mx.bigpond.com ([124.188.161.100])
          by nschwmtas02p.mx.bigpond.com
          (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP
          id <20100417033855.VCWS28300.nschwmtas02p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com>
          for <FreeBSD-gnats-submit@freebsd.org>;
          Sat, 17 Apr 2010 03:38:55 +0000
Received: from duncan.reilly.home ([124.188.161.100])
          by nschwotgx01p.mx.bigpond.com with ESMTP
          id <20100417033855.ZXLQ3673.nschwotgx01p.mx.bigpond.com@duncan.reilly.home>
          for <FreeBSD-gnats-submit@freebsd.org>;
          Sat, 17 Apr 2010 03:38:55 +0000
Message-Id: <1271475535.56224@duncan.reilly.home>
Date: Sat, 17 Apr 2010 13:38:55 +1000
From: Andrew Reilly <areilly@bigpond.net.au>
Reply-To: Andrew Reilly <areilly@bigpond.net.au>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
X-Send-Pr-Version: 3.113
X-GNATS-Notify: chalpin@cs.wisc.edu

>Number:         145769
>Category:       ports
>Synopsis:       final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    mandree
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr 17 03:40:01 UTC 2010
>Closed-Date:    Mon Jul 05 14:07:58 UTC 2010
>Last-Modified:  Tue Jul 20 15:40:01 UTC 2010
>Originator:     Andrew Reilly
>Release:        FreeBSD 9.0-CURRENT amd64
>Organization:
>Environment:
System: FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Apr 17 00:13:12 EST 2010 root@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64


>Description:
	Since last week, using portmaster -a to rebuild ports
	has stopped at fetchmail with the following error:

	cc  -O2 -pipe -g -fno-strict-aliasing
	-I/usr/local/include -I/usr/kerberos/include
	-I/usr/include  -L/usr/local/lib -rpath=/usr/local/lib
	-L/usr/local/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 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
	/usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib
	-lopie -lcrypt -lmd5  -lkvm -lcom_err  -lssl -lcrypto
	-L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err
	-lcrypto -lasn1 -lroken -lcrypt -lcrypto
	/usr/lib/libhx509.so: undefined reference to `MD2_Init'
	/usr/lib/libhx509.so: undefined reference to `MD2_Final'
	/usr/lib/libhx509.so: undefined reference to `MD2_Update'

	Sure enough nm says that libhx509.so has U MD2_Init etc.
	Those symbols are defined by libcrypto, which can
	clearly be seen on the command line above, so I'm not
	sure why it isn't being found.  My limhx509.so is less
	than one day old.

>How-To-Repeat:
	cd /usr/ports/mail/fetchmail; make build
>Fix:

	I don't know, yet.  Still investigating.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: edwin 
State-Changed-When: Sat Apr 17 03:40:10 UTC 2010 
State-Changed-Why:  
Awaiting maintainers feedback (via the GNATS Auto Assign Tool) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145769 

From: Edwin Groothuis <edwin@FreeBSD.org>
To: chalpin@cs.wisc.edu
Cc: bug-followup@FreeBSD.org
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
Date: Sat, 17 Apr 2010 03:40:09 UT

 Maintainer of mail/fetchmail,
 
 Please note that PR ports/145769 has just been submitted.
 
 If it contains a patch for an upgrade, an enhancement or a bug fix
 you agree on, reply to this email stating that you approve the patch
 and a committer will take care of it.
 
 The full text of the PR can be found at:
     http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/145769
 
 -- 
 Edwin Groothuis via the GNATS Auto Assign Tool
 edwin@FreeBSD.org

From: Andrew Reilly <areilly@bigpond.net.au>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
Date: Mon, 26 Apr 2010 12:51:13 +1000

 --Apple-Mail-42--262185842
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii
 
 It is possible that fetchmail isn't failing for everyone because the =
 broken dependency only occurs when the GSSAPI option is enabled, which I =
 have.
 
 It seems that the (obsolete) MD2 functionality was not completely =
 expunged from the crypto libs in -CURRENT.  The attached patch is =
 probably a bit extreme, but I don't know enough about the crypto =
 framework to know what the 'right' answer is.  In any case, this is =
 sufficient to make the fetchmail build happy.
 
 Synopsis: remove *all* reference to MD2_* from the libhx509 crypto =
 library, so that it doesn't have dangling unsatisfied symbols in its =
 symbol table.
 
 
 --Apple-Mail-42--262185842
 Content-Disposition: attachment;
 	filename=hx509.patch
 Content-Type: application/octet-stream;
 	name="hx509.patch"
 Content-Transfer-Encoding: 7bit
 
 --- crypto.c	2008-05-07 23:39:29.000000000 +1000
 +++ crypto.c.md2expunged	2010-04-26 12:27:15.000000000 +1000
 @@ -841,6 +841,7 @@
      return 0;
  }
  
 +#if 0
  static int
  md2_verify_signature(hx509_context context,
  		     const struct signature_alg *sig_alg,
 @@ -870,6 +871,7 @@
  
      return 0;
  }
 +#endif /* 0 */
  
  static const struct signature_alg heim_rsa_pkcs1_x509 = {
      "rsa-pkcs1-x509",
 @@ -980,6 +982,7 @@
      md5_verify_signature
  };
  
 +#if 0
  static const struct signature_alg md2_alg = {
      "rsa-md2",
      oid_id_rsa_digest_md2,
 @@ -989,6 +992,7 @@
      SIG_DIGEST,
      md2_verify_signature
  };
 +#endif
  
  /* 
   * Order matter in this structure, "best" first for each "key
 @@ -1006,7 +1010,9 @@
      &sha256_alg,
      &sha1_alg,
      &md5_alg,
 +#if 0
      &md2_alg,
 +#endif
      NULL
  };
  
 
 --Apple-Mail-42--262185842--

From: Tim Katz <tim.katz@yahoo.com>
To: bug-followup@FreeBSD.org, areilly@bigpond.net.au
Cc:  
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
Date: Sat, 1 May 2010 07:33:16 -0700 (PDT)

 Andrew:
 
 You may be on to something.  Quoting from  the OpenSSL changelog (http://www.openssl.org/news/changelog.html):
 
 ----Begin Quote----
 
 Changes between 1.0.0 and 1.1.0  [xx XXX xxxx]
 ...
 *) Disable MD2 in the default configuration.
      [Steve Henson]
 ...
 
 ---End Quote---
 
 You can confirm this yourself by running "make options" from /usr/ports/security/openssl, and
 seeing that the MD2 option is indeed disabled by default, the reason being listed as "(obsolote)".
 
 So, if the OpenSSL programmers think it should be dropped because it's obsolete, I have no problem
 with you doing it as well. :)
 
 Thanks for looking into this. Hopefully other port maintainers will follow suit and drop MD2 as well,
 so their ported programs will build successfully, and we can all move on with our lives. ;)
 
 Regards,
 Tim
 
 
       

From: Stefan Walter <stefan@freebsd.org>
To: Corey Halpin <chalpin@cs.wisc.edu>
Cc: GNATS <FreeBSD-gnats-submit@FreeBSD.org>
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so
 undefined reference to MD2_Init etc
Date: Fri, 21 May 2010 21:03:20 +0200

 Dear maintainer of mail/fetchmail,
 
 a problem report has been submitted for your port for which your 
 feedback might be required; its contents can be found at [1]. If it 
 contains a patch or suggestions for a change, please send a followup to 
 the PR explaining whether or not you approve it and want it to be 
 committed.
 
 Regards,
 Stefan
 
 [1]: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/145769

From: "Matthias Andree" <matthias.andree@gmx.de>
To: bug-followup@freebsd.org, areilly@bigpond.net.au
Cc: stefan@freebsd.org, "Edwin Groothuis" <edwin@freebsd.org>
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so
 undefined reference to MD2_Init etc
Date: Sun, 06 Jun 2010 14:06:33 +0200

 This isn't a fetchmail fault, but I see it as incompatibility of the base  
 system Heimdal Kerberos libraries with a base system OpenSSL update that  
 disabled MD2.
 
 crypto.c wouldn't be a file that is part of fetchmail.
 
 This should be recategorized to bin/ and reassigned to the proper team.
 Edwin/Stefan, could either of you handle that?
 I've got an appointment...
 
 -- 
 Matthias 'mandree@' Andree

From: Stefan Walter <stefan@freebsd.org>
To: Matthias Andree <matthias.andree@gmx.de>
Cc: areilly@bigpond.net.au, Edwin Groothuis <edwin@freebsd.org>,
	GNATS <FreeBSD-gnats-submit@FreeBSD.org>
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so
 undefined reference to MD2_Init etc
Date: Fri, 25 Jun 2010 12:02:20 +0200

 Hi,
 
 Matthias Andree, 06.06.10, 14:06h CEST:
 
 > This isn't a fetchmail fault, but I see it as incompatibility of the base  
 > system Heimdal Kerberos libraries with a base system OpenSSL update that  
 > disabled MD2.
 > 
 > crypto.c wouldn't be a file that is part of fetchmail.
 > 
 > This should be recategorized to bin/ and reassigned to the proper team.
 > Edwin/Stefan, could either of you handle that?
 > I've got an appointment...
 
 it seems you're right, as there are more PRs seemingly referencing the
 same problem:
 
 ports/137729 (www/mod_auth_kerb2 broken, too)
 kern/147454 (libgssapi broken in head/8)
 
 Unfortunately, I'm not familiar with Heimdal at all, and I don't even know
 who to notify about this so this gets some attention...
 
 Best regards,
 Stefan

From: Andrew Reilly <areilly@bigpond.net.au>
To: Stefan Walter <stefan@freebsd.org>
Cc: Matthias Andree <matthias.andree@gmx.de>,
 Edwin Groothuis <edwin@freebsd.org>,
 GNATS <FreeBSD-gnats-submit@FreeBSD.org>
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
Date: Fri, 25 Jun 2010 20:41:06 +1000

 Hi there,
 
 On 25/06/2010, at 20:02 , Stefan Walter wrote:
 
 > Hi,
 >=20
 > Matthias Andree, 06.06.10, 14:06h CEST:
 >=20
 >> This isn't a fetchmail fault, but I see it as incompatibility of the =
 base =20
 >> system Heimdal Kerberos libraries with a base system OpenSSL update =
 that =20
 >> disabled MD2.
 >>=20
 >> crypto.c wouldn't be a file that is part of fetchmail.
 >>=20
 >> This should be recategorized to bin/ and reassigned to the proper =
 team.
 >> Edwin/Stefan, could either of you handle that?
 >> I've got an appointment...
 >=20
 > it seems you're right, as there are more PRs seemingly referencing the
 > same problem:
 >=20
 > ports/137729 (www/mod_auth_kerb2 broken, too)
 > kern/147454 (libgssapi broken in head/8)
 >=20
 > Unfortunately, I'm not familiar with Heimdal at all, and I don't even =
 know
 > who to notify about this so this gets some attention...
 
 Who knows how dynamic linking works?  I don't but I've tracked down the =
 fact that the symbols missing from libhx509.so (MD2_Init etc) *are* =
 defined by /lib/libcrypto.so, but libhx509.so doesn't show that =
 dependency when you run ldd on it.  I'm afraid that I don't know how to =
 change that situation, but I believe that it would make a difference to =
 those builds.
 
 I've written messages on the subject before, but it seems that the =
 people who might know what to do aren't reading, or perhaps there aren't =
 any...
 
 Cheers,
 
 --=20
 Andrew
 

From: "Matthias Andree" <matthias.andree@gmx.de>
To: "Stefan Walter" <stefan@freebsd.org>, "Andrew Reilly"
 <areilly@bigpond.net.au>
Cc: "Edwin Groothuis" <edwin@freebsd.org>, GNATS
 <FreeBSD-gnats-submit@freebsd.org>
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so
 undefined reference to MD2_Init etc
Date: Fri, 25 Jun 2010 13:26:50 +0200

 Andrew Reilly wrote on 2010-06-25:
 
 > Who knows how dynamic linking works?  I don't but I've tracked down the  
 > fact that the symbols missing from libhx509.so (MD2_Init etc) *are*  
 > defined by /lib/libcrypto.so, but libhx509.so doesn't show that  
 > dependency when you run ldd on it.  I'm afraid that I don't know how to  
 > change that situation, but I believe that it would make a difference to  
 > those builds.
 
 Either it's an ELF field that gets listed as "NEEDED" with readelf -d  
 libhx509.so,
 or it's the <dlfcn.h> stuff with dlopen(3), dlclose(3), dlerror(3) and  
 dlsym(3).
 
 -- 
 Matthias Andree

From: Andrew Reilly <areilly@bigpond.net.au>
To: Matthias Andree <matthias.andree@gmx.de>
Cc: "Stefan Walter" <stefan@freebsd.org>,
 "Edwin Groothuis" <edwin@freebsd.org>,
 GNATS <FreeBSD-gnats-submit@freebsd.org>
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
Date: Fri, 25 Jun 2010 23:19:20 +1000

 Hi Matthias,
 
 On 25/06/2010, at 21:26 , Matthias Andree wrote:
 
 > Andrew Reilly wrote on 2010-06-25:
 >=20
 >> Who knows how dynamic linking works?  I don't but I've tracked down =
 the fact that the symbols missing from libhx509.so (MD2_Init etc) *are* =
 defined by /lib/libcrypto.so, but libhx509.so doesn't show that =
 dependency when you run ldd on it.  I'm afraid that I don't know how to =
 change that situation, but I believe that it would make a difference to =
 those builds.
 >=20
 > Either it's an ELF field that gets listed as "NEEDED" with readelf -d =
 libhx509.so,
 > or it's the <dlfcn.h> stuff with dlopen(3), dlclose(3), dlerror(3) and =
 dlsym(3).
 
 So how does one add more NEEDED fields, when the library is being built? =
  The only NEEDED field when running readelf -d libhx509.so on my system =
 is libc.so.7.
 
 Looking for the MD2 entries in question:
 
 duncan [206]$ objdump -R libhx509.so | grep MD2
 000000000013e9c8 R_X86_64_JUMP_SLOT  MD2_Init
 000000000013ef18 R_X86_64_JUMP_SLOT  MD2_Final
 000000000013f420 R_X86_64_JUMP_SLOT  MD2_Update
 duncan [207]$ nm libhx509.a | grep MD2
                 U MD2_Final
                 U MD2_Init
                 U MD2_Update
 
 and lo:
 duncan [211]$ nm /usr/lib/libcrypto.a | grep MD2
 0000000000000000 T MD2
                 U MD2_Final
                 U MD2_Init
                 U MD2_Update
                 U MD2_Final
                 U MD2_Init
                 U MD2_Update
 0000000000000170 T MD2_Final
 00000000000002e0 T MD2_Init
 00000000000001f0 T MD2_Update
 0000000000000000 T MD2_options
 0000000000000000 R MD2_version
 
 There they are.  One assumes that they're also in libcrypto.so.6, so =
 shouldn't libhx509.so have a NEEDED entry that points to it?
 
 Cheers,
 
 --=20
 Andrew
 

From: Andrew Reilly <areilly@bigpond.net.au>
To: "Matthias Andree" <matthias.andree@gmx.de>
Cc: "Stefan Walter" <stefan@freebsd.org>, "Edwin Groothuis"
 <edwin@freebsd.org>, GNATS <FreeBSD-gnats-submit@freebsd.org>
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so
 undefined reference to MD2_Init etc
Date: Sun, 4 Jul 2010 12:43:04 +1000

 On Fri, 25 Jun 2010 13:26:50 +0200
 "Matthias Andree" <matthias.andree@gmx.de> wrote:
 
 > Andrew Reilly wrote on 2010-06-25:
 > 
 > > Who knows how dynamic linking works?  I don't but I've tracked down the  
 > > fact that the symbols missing from libhx509.so (MD2_Init etc) *are*  
 > > defined by /lib/libcrypto.so, but libhx509.so doesn't show that  
 > > dependency when you run ldd on it.  I'm afraid that I don't know how to  
 > > change that situation, but I believe that it would make a difference to  
 > > those builds.
 > 
 > Either it's an ELF field that gets listed as "NEEDED" with readelf -d  
 > libhx509.so,
 > or it's the <dlfcn.h> stuff with dlopen(3), dlclose(3), dlerror(3) and  
 > dlsym(3).
 > 
 
 See patch attached to bin/147175 just now.  The build of
 libhx509's shared lib needs to be told about libcrypto.so by
 adding DPADD and LDADD lines to the Makefile.  Works for me!
 
 Cheers,
 
 -- 
 Andrew
Responsible-Changed-From-To: freebsd-ports-bugs->mandree 
Responsible-Changed-By: mandree 
Responsible-Changed-When: Mon Jul 5 14:00:07 UTC 2010 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145769 

From: Matthias Andree <mandree@FreeBSD.org>
To: bug-followup@FreeBSD.org, areilly@bigpond.net.au
Cc: Corey Halpin <chalpin@cs.wisc.edu>
Subject: Re: ports/145769: bin/147175: final link of mail/fetchmail fails
 libhx509.so undefined reference to MD2_Init etc
Date: Mon, 05 Jul 2010 15:58:24 +0200

 Hi Andrew, *,
 
 fetchmail obtains the linker flags for GSSAPI from "krb5-config --libs gssapi"
 and pleads "not guilty".
 
 If -CURRENT introduces regressions there, krb5-config needs to be fixed to list
 the required libraries. This used to work before. Example from 8.1 amd64:
 
 $ which -a krb5-config
 /usr/bin/krb5-config
 
 $ krb5-config --libs gssapi
 -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -lroken
 -lcrypt
 
 Which looks right, -lhx509, and later -lcrypto.
 
 I haven't checked evolution-data-server though.
 
 Best regards
 Matthias
State-Changed-From-To: feedback->analyzed 
State-Changed-By: mandree 
State-Changed-When: Mon Jul 5 14:00:56 UTC 2010 
State-Changed-Why:  
analyzed, waits for fix to base system 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145769 
State-Changed-From-To: analyzed->closed 
State-Changed-By: mandree 
State-Changed-When: Mon Jul 5 14:07:57 UTC 2010 
State-Changed-Why:  
This is a base system issue (not a port problem), see bin/147175. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145769 

From: Matthias Andree <mandree@FreeBSD.org>
To: bug-followup@FreeBSD.org, areilly@bigpond.net.au
Cc:  
Subject: Re: ports/145769: bin/147175: final link of mail/fetchmail fails
 libhx509.so undefined reference to MD2_Init etc
Date: Mon, 05 Jul 2010 16:06:35 +0200

 OK, forget my previous email, I wrote nonsense. -lcrypto is on all the command
 lines already, and I misread which Makefile was supposed to be changed (I
 thought you meant the ports' makefiles, when instead you meant the Kerberos
 Makefile).

From: Andrew Reilly <areilly@bigpond.net.au>
To: Matthias Andree <mandree@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, Corey Halpin <chalpin@cs.wisc.edu>
Subject: Re: ports/145769: bin/147175: final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
Date: Tue, 6 Jul 2010 10:34:50 +1000

 Hi Matthias,
 
 On 05/07/2010, at 23:58, Matthias Andree wrote:
 
 > fetchmail obtains the linker flags for GSSAPI from "krb5-config --libs gssapi"
 > and pleads "not guilty".
 
 So do many others, thanks to diligent ports-patching (thanks!)
 This is not the issue.
 
 > If -CURRENT introduces regressions there, krb5-config needs to be fixed to list
 > the required libraries. This used to work before. Example from 8.1 amd64:
 > 
 > $ which -a krb5-config
 > /usr/bin/krb5-config
 > 
 > $ krb5-config --libs gssapi
 > -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -lroken
 > -lcrypt
 > 
 > Which looks right, -lhx509, and later -lcrypto.
 
 The result is the same on -current, but 7.1 doesn't list
 -lhx509, so that must have been introduced/split-out between 7.1
 and 8.  I have an 8.1 box, and ldd /usr/lib/libhx509.so.10 there
 only shows a dependence on /lib/libc.so.7 (not libcrypto), same
 as my -current system that has problems.
 
 > I haven't checked evolution-data-server though.
 
 I'm fairly sure that whatever the issue is, it is the same
 thing, and it is not fetchmail (or even ports) specific, but
 base system.  My original PR was against the base system, but it
 was re-filed as ports presumably because it used the fetchmail
 build as the example trigger.
 
 Given that all of this actually *works* on 8.1-RC1 (I've just
 built fetchmail there with no problems), perhaps the real
 problem is a change in the way the rtld works in -current?
 
 Summary of my observations:
 
 Libhx509.so doesn't exist on 7.1.
 
 On both 8.1 and -current, /usr/lib/libhx509.so.10 contains
 unsatisfied references to MD2_Final, MD2_Init and MD2_Update,
 all of which are provided by /lib/libcrypto.so.6.  Out of the
 box (before applying my patch), this dependency is *not*
 explicitly listed in libhx509.so.10: ldd only shows dependency
 on libc.so.
 
 On 8.1, specifying -lcrypto on the compiler command line is
 sufficient to configure and build something like fetchmail that
 depends on libhx509 (through the krb5-config --libs gssapi
 expression).
 
 On 9-current, the linker complains about the unsatisfied symbols
 in libhx509.so.10 irrespective of the presence of -lcrypto on
 the command line.  After adding the dependency information to
 libhx509.so.10 with my patch, the linker is happy again and
 fetchmail and evolution-data-server both build OK.
 
 I'm afraid that I don't know enough about shared linkage to know
 whether the 8.1 or the 9-current behaviour is "right", but it
 seems clear to me that something has changed, and something
 (either my patch or some back-step in the run-time linker or
 ???) needs to change in the base system so that things work
 again.
 
 I don't know how to bring this to the attention of anyone who
 really knows what is going on, or who that might be.
 
 Cheers,
 
 Andrew
 

From: Andrew Reilly <areilly@bigpond.net.au>
To: Matthias Andree <mandree@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: ports/145769: bin/147175: final link of mail/fetchmail fails libhx509.so undefined reference to MD2_Init etc
Date: Tue, 6 Jul 2010 10:39:10 +1000

 Hi Matthias,
 
 On Mon, Jul 05, 2010 at 04:06:35PM +0200, Matthias Andree wrote:
 > OK, forget my previous email, I wrote nonsense. -lcrypto is on all the command
 > lines already, and I misread which Makefile was supposed to be changed (I
 > thought you meant the ports' makefiles, when instead you meant the Kerberos
 > Makefile).
 
 Yes, sorry about making that patch from within the Kerberos
 directory.  The name "Makefile" is not terribly useful, really.
 That patch belongs in /usr/src/kerberos5/lib/libhx509, where Makefile
 is the only file.
 
 Cheers,
 
 -- 
 Andrew

From: "Schweigert, Udo CERT" <Udo.Schweigert@siemens.com>
To: Andrew Reilly <areilly@bigpond.net.au>
Cc: freebsd-ports-bugs@FreeBSD.org
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so
 undefined reference to MD2_Init etc
Date: Tue, 20 Jul 2010 10:41:40 +0200

 I think the problem is not related to the base system but to an incorrect
 installation of the openssl port. Please try to build openssl from the ports
 again with MD2 option enabled (an option which is per default set to "off").
 
 That solved the same issue I had with the mutt-devel port.
 
 (Having installed openssl from the ports results in two different versions of
 libcrypto to be available. The "-lcypto" flag to cc/ld then results in loading
 that from /usr/local/lib, which may not have the MD2-bits enabled if openssl
 was installed with the default options.)
 
 Regards
 
 Udo
 
 
 On Sun, Jul 04, 2010 at 02:50:04 +0000, Andrew Reilly wrote:
 > The following reply was made to PR ports/145769; it has been noted by GNATS.
 > 
 > From: Andrew Reilly <areilly@bigpond.net.au>
 > To: "Matthias Andree" <matthias.andree@gmx.de>
 > Cc: "Stefan Walter" <stefan@freebsd.org>, "Edwin Groothuis"
 >  <edwin@freebsd.org>, GNATS <FreeBSD-gnats-submit@freebsd.org>
 > Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so
 >  undefined reference to MD2_Init etc
 > Date: Sun, 4 Jul 2010 12:43:04 +1000
 > 
 >  On Fri, 25 Jun 2010 13:26:50 +0200
 >  "Matthias Andree" <matthias.andree@gmx.de> wrote:
 >  
 >  > Andrew Reilly wrote on 2010-06-25:
 >  > 
 >  > > Who knows how dynamic linking works?  I don't but I've tracked down the  
 >  > > fact that the symbols missing from libhx509.so (MD2_Init etc) *are*  
 >  > > defined by /lib/libcrypto.so, but libhx509.so doesn't show that  
 >  > > dependency when you run ldd on it.  I'm afraid that I don't know how to  
 >  > > change that situation, but I believe that it would make a difference to  
 >  > > those builds.
 >  > 
 >  > Either it's an ELF field that gets listed as "NEEDED" with readelf -d  
 >  > libhx509.so,
 >  > or it's the <dlfcn.h> stuff with dlopen(3), dlclose(3), dlerror(3) and  
 >  > dlsym(3).
 >  > 
 >  
 >  See patch attached to bin/147175 just now.  The build of
 >  libhx509's shared lib needs to be told about libcrypto.so by
 >  adding DPADD and LDADD lines to the Makefile.  Works for me!
 >  
 >  Cheers,
 >  
 >  -- 
 >  Andrew
 > _______________________________________________
 > freebsd-ports-bugs@freebsd.org mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs
 > To unsubscribe, send any mail to "freebsd-ports-bugs-unsubscribe@freebsd.org"

From: Matthias Andree <mandree@FreeBSD.org>
To: bug-followup@FreeBSD.org
Cc: Udo.Schweigert@siemens.com
Subject: Re: ports/145769: final link of mail/fetchmail fails libhx509.so
 undefined reference to MD2_Init etc
Date: Tue, 20 Jul 2010 17:33:48 +0200

 There is a compelling reason why MD2 is disabled in OpenSSL 1.0.0, and that's
 that MD2 has been broken for years. I have yet to see a proof that and why
 Kerberos requires MD2.
 
 - we lack a good framework to really have applications link against /usr/local/*
 versions of Kerberos or SSL - /usr/bin is before $LOCALBASE/bin in PATH, so the
 system will pick the system /usr/bin install instead
 
 - we lack a ports feature to demand "if you install OpenSSL 1.0.0, you must
 install Kerberos from ports" or similar.
 
 - even if we fix all this, we still have the problems that individual
 applications might look into system directories before $LOCALBASE. Those would
 have to be patched individually.
 
 I'd propose to change Kerberos to get along without MD2, or otherwise I'd
 request that someone shows chapter and verse of the norm that makes MD2
 mandatory in Kerberos.
 
 Barring such evidence, removal of MD2 from Kerberos/GSSAPI is the way to go.
 
 Also see http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2409
 
 On a related note, see http://tools.ietf.org/html/draft-lha-des-die-die-die-05
 for DES deprecation through Kerberos/GSSAPI.
>Unformatted:
