Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Greetings, it appears that some change to -RECENT (relative to 8-STABLE) breaks linking several GSSAPI applications from ports, for instance, mail/fetchmail if GSSAPI is enabled. These applications then compile OK, but fail to link with MD2_Init and other MD2 symbols not defined, although the command line (obtained from krb5-config gssapi --libs) appears to list -lhx509 and -lcrypto in the right order (hx509 first). This is, according to the report, happening on -CURRENT, but does NOT happen on 8-STABLE or release candidates to 8.1. Andrew Reilly posted a patch to the base system Kerberos to bin/147175 to add a dependency from the shared hx509 library on libcrypto, however there are open questions neither he nor I can answer -- particularly if it's fixing the right problem, or if instead the run-time linker needed to be fixed. Please help: read PR bin/147175 and comment if you're knowledgeable about either run-time linking, KRB5/GSSAPI, or both :) Thank you. -- Matthias Andree ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
On Tue, Jul 06, 2010 at 10:20:28AM +0200, Matthias Andree wrote: Greetings, it appears that some change to -RECENT (relative to 8-STABLE) breaks linking several GSSAPI applications from ports, for instance, mail/fetchmail if GSSAPI is enabled. These applications then compile OK, but fail to link with MD2_Init and other MD2 symbols not defined, although the command line (obtained from krb5-config gssapi --libs) appears to list -lhx509 and -lcrypto in the right order (hx509 first). This is, according to the report, happening on -CURRENT, but does NOT happen on 8-STABLE or release candidates to 8.1. Andrew Reilly posted a patch to the base system Kerberos to bin/147175 to add a dependency from the shared hx509 library on libcrypto, however there are open questions neither he nor I can answer -- particularly if it's fixing the right problem, or if instead the run-time linker needed to be fixed. Please help: read PR bin/147175 and comment if you're knowledgeable about either run-time linking, KRB5/GSSAPI, or both :) You need to gather and show exact command that fails. Shared object that references a symbol but does not record a dependency on the object providing the symbol is the bug in the build of that object (usually). pgpErnjDTkL7K.pgp Description: PGP signature
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Am 06.07.2010 10:54, schrieb Kostik Belousov: On Tue, Jul 06, 2010 at 10:20:28AM +0200, Matthias Andree wrote: Please help: read PR bin/147175 and comment if you're knowledgeable about either run-time linking, KRB5/GSSAPI, or both :) You need to gather and show exact command that fails. Hi Kostik, thanks. I'd propose re-reading http://www.freebsd.org/cgi/query-pr.cgi?pr=147175, particularly the How to reproduce section, and ask specific questions that pop up afterwards. :-) Shared object that references a symbol but does not record a dependency on the object providing the symbol is the bug in the build of that object (usually). In that case, Andrew's proposed patch (same URL as above, which see) would be the way to go, because it adds those dependencies to the Heimdal X.509 library build Makefile. However, I'm neither into -current nor into base system affairs. Any takers? Best regards -- Matthias Andree ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
On Tue, Jul 06, 2010 at 01:47:18PM +0200, Matthias Andree wrote: Am 06.07.2010 10:54, schrieb Kostik Belousov: On Tue, Jul 06, 2010 at 10:20:28AM +0200, Matthias Andree wrote: Please help: read PR bin/147175 and comment if you're knowledgeable about either run-time linking, KRB5/GSSAPI, or both :) You need to gather and show exact command that fails. Hi Kostik, thanks. I'd propose re-reading http://www.freebsd.org/cgi/query-pr.cgi?pr=147175, particularly the How to reproduce section, and ask specific questions that pop up afterwards. :-) Install evolution-data-server as a reference to the command is a sure way to not get any help. I asked for explicit command that fails, PR does not contain this information. It is not even clear whether the issue is from the static or run-time linker. Shared object that references a symbol but does not record a dependency on the object providing the symbol is the bug in the build of that object (usually). In that case, Andrew's proposed patch (same URL as above, which see) would be the way to go, because it adds those dependencies to the Heimdal X.509 library build Makefile. However, I'm neither into -current nor into base system affairs. Any takers? Best regards -- Matthias Andree ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org pgpw50FVakpm2.pgp Description: PGP signature
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Hi Kostik, On 06/07/2010, at 18:54 , Kostik Belousov wrote: You need to gather and show exact command that fails. There's some a little more info in PR: ports/145769, although the fix that I suggest there is almost certainly a wrong turn (I nuked all reference to MD2_* from libhx509, there). I can't easily recreate the problem, now that I've patched my copy of /usr/src/kerberos5/lib/libhx509/Makefile, but the fault seems to be fairly consistent in the configure script of any port configured to use GSSAPI, such as fetchmail or evolution-data-server. From memory, the failing program is a one-line main() that calls MD2_Init(), and attempts to link it with a command line derived from `krb5-config --lib gssapi`. Shared object that references a symbol but does not record a dependency on the object providing the symbol is the bug in the build of that object (usually). That is what /usr/lib/libhx509.so.10 seems to do (see the undefined refs to MD2_* with nm /usr/lib/libhx509.a, and see the lack of dependency on /lib/libcrypto.so.6 with ldd), and yet this hasn't been widely reported, I suspect, because it still seems to work in 8-STABLE. Don't know why. The exact command that fails, in summary, is: get a 9-current system. cd /usr/ports/mail/fetchmail (or /usr/ports/databases/evolution-data-server, but that has lots of other dependencies that might take a while to build) make config # and tell it to enable GSSAPI (and NTLM) which isn't the default. make # watch the configure fail with a report of missing KRB5, but inspection of the configure.log will show that the real failure was a failure to link against the system-supplied shared libraries, specifically libhx509.so. Repeat the process on an 8-STABLE system and see that the config and build proceeds successfully, despite the fact that libhx509.so.10 has undefined symbols for MD2_* just as on -current. Please let me know if there's any other info that I can provide. Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Hi Kostik,
On 06/07/2010, at 22:33 , Kostik Belousov wrote:
Install evolution-data-server as a reference to the command is a sure way
to not get any help.
Why, because no-one uses ports?
I asked for explicit command that fails, PR does not contain this information.
It is not even clear whether the issue is from the static or run-time linker.
The specific command that fails is in the PR, to whit:
cc -o conftest -O2 -pipe -g -DLDAP_DEPRECATED -fno-strict-aliasing
-I/usr/local/include -I/usr/local/include/db41 -L/usr/local/lib -pthread
conftest.c -L/usr/local/lib -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509
-lcom_err -lcrypto -lasn1 -lroken -lcrypt
where, in this instance, conftest.c is something like (extracted from the
configure script from evolution-data-server):
/* contentes of confdefs.h, whatever that is, probably at least: */
#include krb5.h
/* end confdefs.h. */
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern C
#endif
char krb5_init_context ();
int
main ()
{
return krb5_init_context ();
;
return 0;
}
(fetchmail uses a conftest with a call to gss_check_version(), but the result
is the same.)
And the cc fails with
/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'
as reported in the PR.
It doesn't do this on my system any more, because I've fixed it with the patch
attached to that PR.
Cheers,
--
Andrew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
On Tue, Jul 06, 2010 at 11:26:26PM +1000, Andrew Reilly wrote:
Hi Kostik,
On 06/07/2010, at 22:33 , Kostik Belousov wrote:
Install evolution-data-server as a reference to the command is a sure way
to not get any help.
Why, because no-one uses ports?
Because you make it hard to reproduce the issue. E.g. my head scratch
box definitely will not be put to evolution-data-server compilation to
reproduce this.
I asked for explicit command that fails, PR does not contain this
information.
It is not even clear whether the issue is from the static or run-time
linker.
The specific command that fails is in the PR, to whit:
cc -o conftest -O2 -pipe -g -DLDAP_DEPRECATED -fno-strict-aliasing
-I/usr/local/include -I/usr/local/include/db41 -L/usr/local/lib -pthread
conftest.c -L/usr/local/lib -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509
-lcom_err -lcrypto -lasn1 -lroken -lcrypt
where, in this instance, conftest.c is something like (extracted from the
configure script from evolution-data-server):
/* contentes of confdefs.h, whatever that is, probably at least: */
#include krb5.h
/* end confdefs.h. */
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern C
#endif
char krb5_init_context ();
int
main ()
{
return krb5_init_context ();
;
return 0;
}
(fetchmail uses a conftest with a call to gss_check_version(), but the result
is the same.)
And the cc fails with
/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'
as reported in the PR.
Ok, this is useful. But, on the HEAD from Jul 2, I cannot reproduce it,
with conftest.c and command line above. As well as on the stable/8 that
is approx. one month old.
On both systems, MD2_* symbols are resolved by libcrypto.so. Check
your instance, do the symbols appear in the library ?
As a long shot, do you have openssl 1.0 installed from ports ?
Note the -L /usr/local/lib switch, that causes -lcrypto to be resolved
from /usr/local/lib, if present. AFAIR, 1.0 removed MD2.
It doesn't do this on my system any more, because I've fixed it with the
patch attached to that PR.
Cheers,
--
Andrew
pgpw50hEDkvZc.pgp
Description: PGP signature
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Hi Kostik, Thanks for looking at this, On 06/07/2010, at 23:46 , Kostik Belousov wrote: Ok, this is useful. But, on the HEAD from Jul 2, I cannot reproduce it, with conftest.c and command line above. As well as on the stable/8 that is approx. one month old. On both systems, MD2_* symbols are resolved by libcrypto.so. Check your instance, do the symbols appear in the library ? On both my 8- and -current (Jul 3) base systems, libcrypto.so has the MD2_* symbols, and libhx509.so doesn't (but requires to them). /usr/local/lib/libcrpto.a does *not* have the MD2 symbols. As a long shot, do you have openssl 1.0 installed from ports ? My -current box does. My 8.1-RC doesn't. Note the -L /usr/local/lib switch, that causes -lcrypto to be resolved from /usr/local/lib, if present. AFAIR, 1.0 removed MD2. Ah-ha. So I guess the situation properly is: Not having heimdal installed from ports, the ones that look for gssapi libs use the base system, and the /usr/bin/krb5-config gssapi --libs includes -lhx509, which has unresolved MD2_* symbols. The -L/usr/local/lib on the command line (presumably for other ports dependencies) makes the linker look in /usr/local/lib/libcrypto, which is there because of the openssl-1.0 port, and which doesn't have the MD2_ sybmols. My two fixes both kind of work: removing the MD2 references from the base system's libhx509 make it compatible with the -lcrypto in ports; adding an explicit dependency on the base system's libcrypto also works, because that does have the MD2 references. My 8-stable system presumably works because it doesn't have openssl-1.0 installed from ports. So: how should I fix this, properly, on my -current system? Is it as simple as installing heimdal from ports? I can't remove openssl-1.0: that has 191 ports listed in its REQUIRED_BY file. Should ports/security/heimdal be listed as a dependency of the ports that use GSSAPI? Is it OK for the base system libhx509.so to *not* have an explicit dependency on libcrypto, even though there seems to be one, and adding such a dependency seems to fix this problem? Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/2010 15:14:28, Andrew Reilly wrote: So: how should I fix this, properly, on my -current system? Is it as simple as installing heimdal from ports? I can't remove openssl-1.0: that has 191 ports listed in its REQUIRED_BY file. Rebuild the port of openssl-1.0.0 after modifying the OPTIONS to include MD2=on ? Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwzfUQACgkQ8Mjk52CukIx/gwCfW2/S+OgDEKz5ubUa3Ajv9V0x suUAn0r5zUiodJRiwrekZOLuKaI4uFHX =Zh4/ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
Am 06.07.2010, 21:00 Uhr, schrieb Matthew Seaman: On 06/07/2010 15:14:28, Andrew Reilly wrote: So: how should I fix this, properly, on my -current system? Is it as simple as installing heimdal from ports? I can't remove openssl-1.0: that has 191 ports listed in its REQUIRED_BY file. Rebuild the port of openssl-1.0.0 after modifying the OPTIONS to include MD2=on ? Not good given that MD2 is broken. Very broken, not just by a factor of 2^5 or something. Where upon rests the earlier assertion (not by Matthew) that Kerberos V needed MD2 checksums? I can't seem to find that in the KRB5 protocol and checksum RFCs. If it's not mandatory we may want to nuke MD2 from Kerberos to remedy a weakness... Chapter and Verse welcome. Thanks. -- Matthias Andree ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
On Tue, Jul 06, 2010 at 08:00:20PM +0100, Matthew Seaman wrote: On 06/07/2010 15:14:28, Andrew Reilly wrote: So: how should I fix this, properly, on my -current system? Is it as simple as installing heimdal from ports? I can't remove openssl-1.0: that has 191 ports listed in its REQUIRED_BY file. Rebuild the port of openssl-1.0.0 after modifying the OPTIONS to include MD2=on ? OK. I've done that, and backed out my patch to the base libhx509 build, and lo: fetchmail rebuilt entirely happily. But now I'm confused, because ldd fetchmail before the change and ldd fetchmail after the change are identical. I don't understand how that can be. I think that I need to tear things down and start from scratch. Or at least think about it a bit longer... Here's ldd fetchmail, after (same as before): fetchmail: libintl.so.9 = /usr/local/lib/libintl.so.9 (0x800681000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x80078a000) libopie.so.6 = /usr/lib/libopie.so.6 (0x800984000) libcrypt.so.5 = /lib/libcrypt.so.5 (0x800a8d000) libmd.so.5 = /lib/libmd.so.5 (0x800ba6000) libkvm.so.5 = /lib/libkvm.so.5 (0x800cb3000) libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x800dbc000) libssl.so.7 = /usr/local/lib/libssl.so.7 (0x800ebe000) libcrypto.so.7 = /usr/local/lib/libcrypto.so.7 (0x801016000) libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x8012b2000) libheimntlm.so.10 = /usr/lib/libheimntlm.so.10 (0x8013bc000) libkrb5.so.10 = /usr/lib/libkrb5.so.10 (0x8014c1000) libhx509.so.10 = /usr/lib/libhx509.so.10 (0x801631000) libasn1.so.10 = /usr/lib/libasn1.so.10 (0x801771000) libroken.so.10 = /usr/lib/libroken.so.10 (0x8018f3000) libc.so.7 = /lib/libc.so.7 (0x801a05000) I would have thought that the before would be using /lib/libcrypto.so.6, because that's what libhx509.so.10 told it to... Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Regression in GSSAPI/libxh509 linking? [PR bin/147175]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/2010 23:26:03, Matthias Andree wrote: Am 06.07.2010, 21:00 Uhr, schrieb Matthew Seaman: On 06/07/2010 15:14:28, Andrew Reilly wrote: So: how should I fix this, properly, on my -current system? Is it as simple as installing heimdal from ports? I can't remove openssl-1.0: that has 191 ports listed in its REQUIRED_BY file. Rebuild the port of openssl-1.0.0 after modifying the OPTIONS to include MD2=on ? Not good given that MD2 is broken. Very broken, not just by a factor of 2^5 or something. Where upon rests the earlier assertion (not by Matthew) that Kerberos V needed MD2 checksums? I can't seem to find that in the KRB5 protocol and checksum RFCs. If it's not mandatory we may want to nuke MD2 from Kerberos to remedy a weakness... Chapter and Verse welcome. Yeah. Even so, lots of software still expects it to be present and won't link without it. I hope no one is actually using it, or running with a cipher configuration that would permit it to be used. Cleaning all reliance on MD2 out of the ports and base would make a very good project for a bunch of people, and pushing those changes upstream would certainly help make the internet a better place. Probably should start with an experimental run on a tinderbox somewhere trying to build all ports that are OpenSSL consumers against security/openssl with MD2 turned off. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw0CfsACgkQ8Mjk52CukIzTAQCeOmkWeudx4UCnxI5wFBNrcAuY x80AnivuyK8mPfOPHPUe7Y95uMMpUSVo =PHpX -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
