By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 913

Summary:	Build issue: Kerberos support does not exist with any cmake converted package
Product:	TDE	Reporter:	Darrell <darrella>
Component:	other (any)	Assignee:	Timothy Pearson <kb9vqf>
Status:	RESOLVED INVALID
Severity:	critical	CC:	bugwatch, darrella
Priority:	P1
Version:	R14.0.0 [Trinity]
Hardware:	Other
OS:	Other
Compiler Version:		TDE Version String:
Application Version:		Application Name:
Bug Depends on:
Bug Blocks:	390

Description Darrell 2012-03-12 18:07:02 CDT

None of the packages converted to the cmake build process support kerberos (krb5).

Comment 1 Timothy Pearson 2012-05-25 14:52:04 CDT

Can you be more specific?  Which packages originally supported Kerberos?

Comment 2 Darrell 2012-05-25 20:02:05 CDT

Search the sources for:

if test -f /usr/kerberos/include/krb5.h; then

If kerberos is installed, then automake detects this. None of the cmake
packages detect kerberos.

Comment 3 Timothy Pearson 2012-06-13 00:02:05 CDT

The krb5.h check does nothing other than set an additional include directory.  Unless you can show me otherwise (i.e. a build failure or missing feature) I see no reason to copy orphaned checks from Autotools to CMake. ;-)

Comment 4 Darrell 2012-06-13 00:20:45 CDT

How do we know when kerberos support is built into a package?

I filed bug report 390 because in the automake days, (k)depim detected kerberos and built with that support. When (k)depim was installed to a system without kerberos, akregator would fail to fetch feeds.

As tdepim no longer autodetects kerberos, that support is not being built.

I personally don't need kerberos. I'm just testing various build scenarios. At the moment I see nothing in any build logs that kerberos support is being built in any cmake converted package.

Possibly only kerberos support is needed in tdelibs/tdebase and other packages pick up on that.

So back to basics: do we want kerberos support in TDE packages? If yes, then how do we test that functionality?

Comment 5 Timothy Pearson 2012-06-13 00:25:17 CDT

I just grepped in the tdepim source code, and krb5, kerberos, and similar strings.  The only thing I found was the file tdepim/kresources/groupwise/soap/stdsoap2.h, which does not appear to be tied in to the Autotools build system.

It is possible that openssl dictates, in a transparent fashion, whether or not applications linked against openssl require Kerberos.  All I know for sure is that there seems to be no Automake control over Kerberos support in TDE applications.

Comment 6 Darrell 2012-06-13 00:41:46 CDT

So you're saying that if TDE support kerberos, that support is indirect, probably through ssl?

How do we test this?

Just trying to make sure we're covered.

Comment 7 Timothy Pearson 2012-06-13 01:05:01 CDT

(In reply to comment #6)
> So you're saying that if TDE support kerberos, that support is indirect,
> probably through ssl?

Yes

> How do we test this?

Probably by the exact same method you used to discover the Kerberos support in the first place--i.e. build with CMake with Kerberos installed on the system, then move those files to a system without Kerberos installed and see if it fails.

More direct would be to use ldd to search for whatever TDE library has Kerberos references in it when built with Automake, then make sure that those references are present when built with CMake.

> Just trying to make sure we're covered.

Good idea. Keep doing so! :-)