perlgssapi-developer — discussion of development process

[Perlgssapi-developer] patches for typos

[Dan L. <da...@la...>]

Hi,

I noticed two typos while working with LWP-Authen-Negotiate today:

Diffs can be found at:

https://github.com/dlangille/LWP-Authen-Negotiate/commit/195a1c490575147e42dd830b6b8c4c667b1ae262

https://github.com/dlangille/LWP-Authen-Negotiate/commit/22844cd94b80dc239c226642dd8a6eb5bf1fa518

Thanks

— 
Dan Langille
http://langille.org/

[Perlgssapi-developer] GSSAPI 0.28 fails tests on OS X 10.8

[Eugene H. <eho...@gm...>]

Hi,

I've just found a problem with LWP::Authen::Negotiate crashing and tracked
it down to GSSAPI 0.28.

The crash happens to be gss_release_oid called from OID.xs (in DESTROY)
trying to release something that was not allocated. Settings breakpoint
there before running `t/checkoids.t` reveals that `oid` variable contains
oid equal to __SPNEGO_MECHTYPE_OID but it's pointer value is not equal to
`&myspnego_oid_desc`. That's all I have for now.

`make test` produces the following on my OS X 10.8 (64-bit). The malloc
error is the problem I'm talking about, though it seems there are other
checks that fail too:

PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/1constants.t ..... ok
t/2status.t ........ ok
t/checkoids.t ...... 1/34 perl(52431) malloc: *** error for object
0x7fff8291f4ff: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
t/checkoids.t ...... All 34 subtests passed
t/importnames.t .... ok
t/indicatemechs.t .. 1/5 # Kerberos 5, SPNEGO
t/indicatemechs.t .. ok
t/inquire_cred.t ... 1/6
#   Failed test '$cred1->inquire_cred($name, $lifetime, $cred_usage,
$oidset'
#   at t/inquire_cred.t line 47.
# inquire_cred()    lifetime: 0 seconds
# inquire_cred()    credusage: 0 (GSS_C_BOTH)
(in cleanup) oidset has no value.
# Looks like you failed 1 test of 6.
t/inquire_cred.t ... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/6 subtests
t/pod.t ............ ok
t/test.t ........... 1/13
#   Failed test ' $str eq '{ 1 2 840 113554 1 2 1 1 }' '
#   at t/test.t line 29.
#          got: '1 2 840 113554 1 2 1 1'
#     expected: '{ 1 2 840 113554 1 2 1 1 }'
perl(52438) malloc: *** error for object 0x7fff8291f535: pointer being
freed was not allocated
*** set a breakpoint in malloc_error_break to debug
t/test.t ........... Failed 1/13 subtests
t/zbugfixes.t ...... 1/3 #
#
#  if you want to run tests that do a realworld *use* of your GSSAPI
#  start a kinit and try to run
#
# ./examples/getcred_hostbased.pl
#
t/zbugfixes.t ...... ok

Test Summary Report
-------------------
t/checkoids.t    (Wstat: 6 Tests: 34 Failed: 0)
  Non-zero wait status: 6
t/inquire_cred.t (Wstat: 256 Tests: 6 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
t/test.t         (Wstat: 6 Tests: 13 Failed: 1)
  Failed test:  2
  Non-zero wait status: 6
Files=9, Tests=152,  1 wallclock secs ( 0.04 usr  0.02 sys +  0.37 cusr
 0.05 csys =  0.48 CPU)
Result: FAIL
Failed 3/9 test programs. 2/152 subtests failed.
make: *** [test_dynamic] Error 255


-- 
Eugene Homyakov <eho...@gm...>

[Perlgssapi-developer] GSSAPI 0.28 test failures on Solaris

[John D. <jd...@op...>]

Two problems on Solaris 10, one I can sort out myself, the other I
cannot:

1constants.t fails on the GSS_S_CRED_UNAVAIL test, this is easily fixed
in GSSAPI.c:

#if !defined(SEAM)
#include <gssapi/gssapi_generic.h>
#include <gssapi/gssapi_krb5.h>
#else
#include <gssapi/gssapi_ext.h>
+#define GSS_S_CRED_UNAVAIL GSS_S_FAILURE
#endif

(I suppose you could also change the test :-)


The other issue is with this test:

t/inquire_cred.t ... 1/6 
#   Failed test '$cred1->inquire_cred($name, $lifetime, $cred_usage,
$oidset'
#   at t/inquire_cred.t line 47.
# inquire_cred()    lifetime:   32256 seconds
# inquire_cred()    credusage:   1 (GSS_C_INITIATE)
       (in cleanup) oidset has no value.
# Looks like you failed 1 test of 6.

Now, when I run the Makefile.PL, I see this:

"Solaris Kerberos (based on MIT Kerberos 5 release 1.4.0)"

And I also see in the MIT krb5 'CHANGES' file a number of changes around
inquire_cred in ~1.4 era code.

So, is this even expected to work?

jd

Re: [Perlgssapi-developer] [rt.cpan.org #48732] look for krb5-config in /usr/kerberos/bin

[Achim G. <ac...@gr...>]

On Tuesday 18 August 2009, Mark Hedges via RT wrote:

>  Searching krb5-config command... not found! at Makefile.PL line 95.
> Warning: No success on command[/usr/bin/perl Makefile.PL]

Hmm... maybe I did the testing the wrong way?

1. I've additionally added the Makefile.PL Version information to the Build 
output, thanks for the idea.

2. Find below the manual step-by-steps executed I have executed on my platform

3. Please check if this test steps work on your platform
   by manual executing

4. If they work... please let me know an idea what makes the difference
   between manual stepping and your build environment.

Thank you!

Best Regards,
Achim


achim@mjoelnir ~ $ uname
Linux
achim@mjoelnir ~/svn_gssapi/GSSAPI $unset PATH

achim@mjoelnir ~/svn_gssapi/GSSAPI $ /usr/bin/perl Makefile.PL

 Welcome to GSSAPI.pm setup!

 (Makefile.PL Version 0.03)

 run "perl Makefile.PL --help" to see further installation options


----------------------------------------------------------
 Searching krb5-config command...
 krb5-config NOT found in $PATH... now doing some guesswork:

 1. trying /usr/kerberos/bin/krb5-config ...not found.
 2. trying /usr/bin/krb5-config ...found.

 using krb5-config command '/usr/bin/krb5-config'.

----------------------------------------------------------
 using GSSAPI implementation
 Kerberos 5 release 1.5.3


----------------------------------------------------------
 Adding from your Perlinstallation ($Config{lddlflags}) to LDDLFLAGS

 -shared -L/usr/local/lib

----------------------------------------------------------
 Bypassing to LDDLFLAGS

 -shared -L/usr/local/lib -Wl,-rpath -Wl,/usr/lib

----------------------------------------------------------
 Using LIBS

 -L/usr/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl

----------------------------------------------------------
 Using INC includeconfiguration




----------------------------------------------------------
Writing Makefile for GSSAPI

Re: [Perlgssapi-developer] [rt.cpan.org #48732] look for krb5-config in /usr/kerberos/bin

[Achim G. <ac...@gr...>]

On Monday 17 August 2009, Mark Hedges via RT wrote:
> So I appreciate your help if
> the build script can look through a list of other directories that would
> be awesome.

Hello Mark,

I've modified the Makefile.PL as discussed.
Find the new Makefile.PL attached to this email.

Please check if the new Makefile.PL works within your toolchain.
Please let me know if that works.
Please let me know if there are any problems.

Best Regards,
Achim

Re: [Perlgssapi-developer] [rt.cpan.org #48732] look for krb5-config in /usr/kerberos/bin

[Achim G. <ac...@gr...>]

On Saturday 15 August 2009, Mark Hedges via RT wrote:

> I can build all other modules using CPAN with sudo
> unless they have bugs, but this one is broken because it does not look
> in the "system standard" place for `krb5-config`. 

Hello Mark,

As far as I know there is no '"system standard" place for `krb5-config'.
So the "which krb5-config"-way was choosed because this works on the most
platforms, Kerberos-implementions (MIT, Heimdal, Sun) and conditions.
The idea was to keep the Makefile.PL's complexity small.
But you're correct, on the circumstances you describe the Makefile.PL
behaves 'broken'.

Your suggestion how Makefile.PL should additonally search the
'"system standard" place for `krb5-config`' is... to test
a given list of binaries.

If I got the idea right that means maintaining a list of 
paths to search for the krb5-config binary within Makefile.PL?

What's the output of

perl -e "print $^O; "

on your platform?

(Sorry I can't provide a patch within the next days... you will get my answer
at the end of this week)

Best Regards,
Achim

Re: [Perlgssapi-developer] [rt.cpan.org #48732] look for krb5-config in /usr/kerberos/bin

[Achim G. <ac...@gr...>]

Hello Mark,

if you run the the "perl Makefile.PL" in this way:

perl Makefile.PL --gssapiimpl /usr/kerberos

You can always specify the path where to look for
krb5_config utility. (run "perl Makefile.PL --help" for all available 
options).

In general the GSSAPI-Makefile.PL does not look into the PATH environment,
it makes direct use of the systems /usr/bin/which for searching for 
krb5-config and it's path.

From that point of view I suppose if you can make your sudo-toolchain properly
run the "which krb5-config" the other parts will work fine.

Does this help on your problem?

Best Regards,
Achim


On Saturday 15 August 2009, Mark Hedges via RT wrote:
> Fri Aug 14 18:31:29 2009: Request 48732 was acted upon.
> Transaction: Ticket created by MARKLE
>        Queue: GSSAPI
>      Subject: look for krb5-config in /usr/kerberos/bin
>    Broken in: 0.26
>     Severity: (no value)
>        Owner: Nobody
>   Requestors: MA...@cp...
>       Status: new
>  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=48732 >
>
>
> CentOS 5.3 krb5-workstation package installs krb5-* utils in
> /usr/kerberos/bin and /usr/kerberos/sbin, and adds the bin to the
> default PATH.  As root I can use CPAN to build the package, but when I
> use `sudo perl -MCPAN -e shell` or sudo a script that uses CPAN
> directly, CPAN does not use my PATH or root's PATH, and it fails to find
> the config script.  Is it safe to look for krb5-config in
> /usr/kerberos/bin if it does not find it in the available PATH?

Re: [Perlgssapi-developer] GSSAPI-0.26 does not pass make test stage on SCO Openserver 6.0

[Achim G. <ac...@gr...>]

On Monday 04 May 2009, you wrote:

> I have included files showing Perl making the Makefile (GSSpmake.txt), the
> initial make (GSSmake.txt),
> and  the make test stage (GSStest.txt)

Hello Jeffrey,

I suppose the main difference between running testst by "make test" and 
running by "prove" or "prove -v" is PERL_DL_NONLAZY=1.
(set in the Makefile)

To check is this is the main difference please

1. run kdestroy to ensure you run the test without TGT
   (fail of test 19 of t/test.t is another problem 
    I have to dig deeper into, we want to skip it here)

2. manually edit your Makefile and remove the 4 "PERL_DL_NONLAZY=1" from the
   4 lines of Makefile (I've prepared this for you, find attached the 
   modified Makefile)

3. run "make test" and check if "make test" fails. (This should not fail if my 
   assumption is correct)

4. manually set environment PERL_DL_NONLAZY=1 and run "prove" command.
   (this should fail if my assumption is correct).

BR, Achim
   

Re: [Perlgssapi-developer] GSSAPI-0.26 does not pass make test stage on SCO Openserver 6.0

[Jeffrey P. <jp...@ro...>]

Hello.

1)
I have added files for the various tests.  
The  prove  t/whatever are named test_t.txt
The prove -v t/whatever are named test-v_t.txt

2) ExtUtils::MakeMaker is now at 6.50.
   I have run kinit, have the daemons running, and have a realm set up.
Made no difference.

Lastly, as far as I can tell other shared library commands work.

-- 
Jeffrey Pikul
jp...@ro...

Re: [Perlgssapi-developer] GSSAPI-0.26 does not pass make test stage on SCO Openserver 6.0

[Achim G. <ac...@gr...>]

On Wednesday 06 May 2009, you wrote:
> Hello Achim.
>
> Responding to your points:

Hello Jeffrey,

From my point of view the fact is strange that running tests by "prove -v"
results in no errors, but "make test" fails in the way you described.

Hmmm. 

Just to be sure... please run and send the output of

1.

prove t

2.

prove -v t

3. Just to be sure: The version of ExtUtils::MakeMaker on my current 
environment is 6.42. Is there any chance you do the build and test
using  ExtUtils::MakeMaker 6.42 or higher?

Is your environment already configured in a realworld Kerberos-setup so you 
can run the tests with a valid TGT (Means: run kinit first, rerun the tests)?


The output of your ldd-command looks strange to me:

"ldd: bad magic number in: ./blib/arch/auto/GSSAPI/GSSAPI.so"

On my systems (Linux, *BSD) this command prints out a list of linked
shared libs.

Your dynamic linking system is OK and works as expected?
(ldd works properly on other executables?)



BR, Achim


BTW: Please keep 'per...@li...' in the 
mail-loop, the people reading there have more knowledge and are more 
experienced than me. (That's why I add the complete email with all data
to this Mail.)

Re: [Perlgssapi-developer] GSSAPI-0.26 does not pass make test stage on SCO Openserver 6.0

[Achim G. <ac...@gr...>]

On Monday 04 May 2009, you wrote:
> Hello.
>
> I am trying to build GSSAPI-0.26 on a SCO Openserver 6 server.

Hello Jeffrey,

Thank you for your detailed report. (I've attached the complete Email
as a reference for the listmembers)

I am sorry, at the moment I have no idea what is going wrong 
exactly or how to debug deeper.

Just... peeking around in the darkness... here are some questions:

1. I never had hands on a SCO Openserver system. 
The compiler you use to build the GSSAPI module is the same that was used to 
build your perl? ( perl -V )

2. in the GSSAPI build dir please run

prove -v t/1constants.t

and send back the output

3. in the GSSAPI build dir please run

ldd ./blib/arch/auto/GSSAPI/GSSAPI.so

and send back the output

4. Please let me know the $VERSION of your ExtUtils::MakeMaker module
( grep '^$VERSION ='  `perldoc -l ExtUtils::MakeMaker` )

5. Please send the Makefile generated by perl Makefile.PL

6. Please tar the content of you /usr/include/heimdal
   directory and send the .tar.gz file to me.


Thank you!

BR, Achim

[Perlgssapi-developer] Your Test report of GSSAPI.pm http://www.nntp.perl.org/group/perl.cpan.testers/2009/01/msg3143134.html

[Achim G. <ac...@gr...>]

Hello Ulrich,

Thank you for providing GSSAPI-test report
<http://www.nntp.perl.org/group/perl.cpan.testers/2009/01/msg3143134.html>.


To dive a little bit deeper into the problem I need your support:

Are you willing to help and send me related to this report

1. The output of 
 
perl Makefile.PL

2. The output of

prove -v t/zbugfixes.t


?

Thank you!

BR, Achim



----------  Forwarded Message  ----------

Subject: CPAN Testers Daily Summary Report
Date: Friday 30 January 2009
From: CPAN Tester Report Server <do_...@cp...>
To: "Achim Grolms" <AG...@cp...>

Dear Achim Grolms,

Please find below the latest reports for your distributions, generated by CPAN 
Testers, from the last 24 hours. 

To set your preferences for what you wish to have reported in this Daily 
Summary, please visit the CPAN Testers Preferences system at 
https://prefs.cpantesters.org.


GSSAPI-0.26:
- i386-netbsd-thread-multi / 5.10.0:
  - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/3143134



If you have an issue with a particular report, or wish to gain further 
information from the tester, please use the 'Find A Tester' tool at 
http://stats.cpantesters.org/cpanmail.html, using the NNTP ID of the report 
to locate the correct email address.

If you wish to unsubscribe from these notifications, please login to the CPAN 
Testers Preferences system, with your PAUSE credentials, and disable CPAN 
Testers notifications permanently or temporarily. If you have problems with 
accessing the site, please contact Barbie <ba...@cp...> and request to be 
removed from the automatic mailings. 

Thanks,
The CPAN Testers
-- 
Reports:     http://www.cpantesters.org
Statistics:  http://stats.cpantesters.org
Wiki:        http://wiki.cpantesters.org
Preferences: https://prefs.cpantesters.org

-------------------------------------------------------

Re: [Perlgssapi-developer] [rt.cpan.org #38158] GSSAPI test errors on Solaris 8 and 10

[Achim G. <ac...@gr...>]

On Monday 04 August 2008, Marek Rouchal via RT wrote:

> According to the README, GSSAPI is supposed to work with the Solaris
> 10 native GSS library. I tried (both on Solaris 10 and 8):
>     perl Makefile.PL --gssapi_libs='-lgss' --gssapi_inc='-
> I/usr/include'

> not ok 72 - GSS_S_CRED_UNAVAIL

Hello Marek,

unforutanetely I have no Solaris available for testing.
Can you check in your installation

1. If your GSSAPI header files define GSS_S_CRED_UNAVAIL ?
2. If yes - what file?
3. If no - will the missing GSS_S_CRED_UNAVAIL constant break
   your existing Perl-software?   

Thank you!

BR, Achim

Re: [Perlgssapi-developer] **SPAM ZEN 79.196.241.104** Re: Re: [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Achim G. <ac...@gr...>]

On Sunday 03 February 2008, Markus Moeller wrote:
> Achim,
>
> I tested on my systems and it looks good.

Release 0.25 of GSSAPI.pm is available at CPAN
now.

Thank you!

Achim

Re: [Perlgssapi-developer] **SPAM ZEN 79.196.241.104** Re: Re: [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Markus M. <hu...@mo...>]

Achim,

I tested on my systems and it looks good.

Thank you
Markus

----- Original Message ----- 
From: "Achim Grolms" <ac...@gr...>
To: <per...@li...>; "Markus Moeller" 
<hu...@mo...>
Cc: <bug...@rt...>; "Leif Johansson" <le...@it...>
Sent: Saturday, February 02, 2008 2:06 PM
Subject: **SPAM ZEN 79.196.241.104** Re: [Perlgssapi-developer] Re: 
[rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss 
library


> On Saturday 02 February 2008, Markus Moeller wrote:
>> Achim,
>>
>> I changed to check for the Solaris keyword in the version string
>
> Hello Markus,
>
> I've added your patch to the Subversion repository.
> You can checkout the trunk version by
>
> svn checkout
> https://perlgssapi.svn.sourceforge.net/svnroot/perlgssapi/GSSAPI/trunk/GSSAPI
>
>
> Please let me know if the trunk version now works for you.
>
> @All: Please let me know if the trunk version still works for you...
>
> If everything works fine for you I will push the new version to CPAN.
>
> Thank you,
> Achim
> 

Re: [Perlgssapi-developer] [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Achim G. <ac...@gr...>]

On Saturday 02 February 2008, Markus Moeller wrote:
> Achim,
>
> I changed to check for the Solaris keyword in the version string

Hello Markus,

I've added your patch to the Subversion repository.
You can checkout the trunk version by

svn checkout 
https://perlgssapi.svn.sourceforge.net/svnroot/perlgssapi/GSSAPI/trunk/GSSAPI


Please let me know if the trunk version now works for you.

@All: Please let me know if the trunk version still works for you...

If everything works fine for you I will push the new version to CPAN.

Thank you,
Achim

Re: [Perlgssapi-developer] **SPAM ZEN 79.196.247.75** Re: **SPAM ZEN 83.227.179.169** Re: [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Markus M. <hu...@mo...>]

Achim,

I changed to check for the Solaris keyword in the version string.

Markus

----- Original Message ----- 
From: "Achim Grolms" <ac...@gr...>
To: "Markus Moeller" <hu...@mo...>
Cc: "Leif Johansson" <le...@it...>; <bug...@rt...>; 
<per...@li...>
Sent: Saturday, February 02, 2008 12:23 AM
Subject: **SPAM ZEN 79.196.247.75** Re: **SPAM ZEN 83.227.179.169** Re: 
[Perlgssapi-developer] [rt.cpan.org #32788] Enhancement to use 
OpenSolaris/Solaris 10 native gss library


> On Saturday 02 February 2008, Markus Moeller via RT wrote:
>>        Queue: GSSAPI
>>  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=32788 >
>>
>> Please find attached an updated Makefile.PL and GSSAPI.xs.
>
> Hello Markus, thank you very much!
>
> Your Makefile.PL does the check of libs
> by testing for OS:
>
> if ($^O =~ /solaris/) {
>    $libconf = "-L/usr/lib -R/usr/lib -lgss";
> }
>
> My idea was to check the output of
>
> krb5-config --version
>
> for /Solaris/
>
> to check if the used GSSAPI-implementation is the
> Kerberos-implementation shipped with Solaris.
>
>
> The problem with simply checking $^O =~ /solaris/
> is (from my point of view):
>
> if the OS is Solaris, but the installed GSSAPI-implementation
> is plain MIT-Kerberos...(or Heimdal) setting -DSEAM would be wrong?
>
> Do I see a problem where no problem exists?
>
> Thank you,
> Achim
>
> 

Re: [Perlgssapi-developer] **SPAM ZEN 79.196.247.75** Re: **SPAM ZEN 83.227.179.169** Re: [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Markus M. <hu...@mo...>]

But I only check for solaris when krb5-config returns "Unknown" from
/usr/bin/krb5-config: Unknown option `gssapi' -- use `--help' for usage

If krb5-config is from MIT or Heimdal it will work as expected.

Markus

----- Original Message ----- 
From: "Achim Grolms" <ac...@gr...>
To: "Markus Moeller" <hu...@mo...>
Cc: "Leif Johansson" <le...@it...>; <bug...@rt...>; 
<per...@li...>
Sent: Saturday, February 02, 2008 12:23 AM
Subject: **SPAM ZEN 79.196.247.75** Re: **SPAM ZEN 83.227.179.169** Re: 
[Perlgssapi-developer] [rt.cpan.org #32788] Enhancement to use 
OpenSolaris/Solaris 10 native gss library


> On Saturday 02 February 2008, Markus Moeller via RT wrote:
>>        Queue: GSSAPI
>>  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=32788 >
>>
>> Please find attached an updated Makefile.PL and GSSAPI.xs.
>
> Hello Markus, thank you very much!
>
> Your Makefile.PL does the check of libs
> by testing for OS:
>
> if ($^O =~ /solaris/) {
>    $libconf = "-L/usr/lib -R/usr/lib -lgss";
> }
>
> My idea was to check the output of
>
> krb5-config --version
>
> for /Solaris/
>
> to check if the used GSSAPI-implementation is the
> Kerberos-implementation shipped with Solaris.
>
>
> The problem with simply checking $^O =~ /solaris/
> is (from my point of view):
>
> if the OS is Solaris, but the installed GSSAPI-implementation
> is plain MIT-Kerberos...(or Heimdal) setting -DSEAM would be wrong?
>
> Do I see a problem where no problem exists?
>
> Thank you,
> Achim
>
> 

Re: [Perlgssapi-developer] **SPAM ZEN 83.227.179.169** Re: [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Markus M. <hu...@mo...>]

Please find attached an updated Makefile.PL and GSSAPI.xs. This works on my 
Solaris 10 and OpenSolaris box.

Markus

----- Original Message ----- 
From: "Leif Johansson" <le...@it...>
To: <ac...@gr...>
Cc: <bug...@rt...>; <hu...@mo...>; 
<per...@li...>
Sent: Tuesday, January 29, 2008 11:38 PM
Subject: **SPAM ZEN 83.227.179.169** Re: [Perlgssapi-developer] [rt.cpan.org 
#32788] Enhancement to use OpenSolaris/Solaris 10 native gss library


> Achim Grolms wrote:
>> On Wednesday 30 January 2008, you wrote:
>>
>>>> But *if* GSS_C_NT_HOSTBASED_SERVICE is available and
>>>>  is not used...
>>>> Why the need to define it in GSSAPI.xs?
>>>> Why to define it in "the other direction"?
>>>>
>>>> #define gss_nt_service_name GSS_C_NT_HOSTBASED_SERVICE
>>>>
>>>> Hmm. Am I wrong?
>>>>
>>>> Thank you,
>>>> Achim
>>>>
>>> the only need would be to support applications which relied on the
>>> older definition - I can't think of any.
>>>
>>
>> "Application"... that means application using the GSSAPI.pm
>> module? This applications run against the code in
>> xs/OID.xs :
>>
>>
>> GSSAPI::OID_const
>> gss_nt_service_name()
>>     CODE:
>>         RETVAL = GSS_C_NT_HOSTBASED_SERVICE;
>>     OUTPUT:
>>         RETVAL
>>
>>
>> Is there a point a Perl-application using GSSAPI.pm
>> will have a use for the (C-level) 'gss_nt_service_name'?
>>
>> Thank you,
>> Achim
>>
> Not that I can think of
> 

Re: [Perlgssapi-developer] [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Achim G. <ac...@gr...>]

On Wednesday 30 January 2008, Markus Moeller wrote:

> Unfortunatly I am not that good in perl otherwise I would have send you a
> patch.

Can you provide an account on your machine(s) I can
use as a Testenvironment?

If not - are you willing to test Codesnippets
and Changes and some "play the remote UI" I will forward to you?

First question: Please run

perl -e "print $^O";

on both of your OS and send me the output.

Second question:

As far as I understand  the only problem on 
Opensolaris is the missing --libs gssapi option
of krb5-config?

Because of high workload at the moment I am not able to answer
quickly on requests related to GSSAPI.pm

Thank you,
Achim

Re: [Perlgssapi-developer] **SPAM ZEN 79.196.230.199** Re: [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Markus M. <hu...@mo...>]

I see the following on OpenSolaris

krb5-config --version
Solaris Kerberos (based on MIT Kerberos 5 release 1.4.0)

but krb5-config --libs gssapi fails with
/usr/bin/krb5-config: Unknown option `gssapi' -- use `--help' for usage

Can you check for the SUN gss package with pkginfo -q SUNWgss and set a 
flag -DSEAM for example, set the libs to "-L/usr/lib -R/usr/lib -lgss" and 
add
a ifdef to GSSAPI.xs like

#if !defined(SEAM)
#include <gssapi/gssapi_generic.h>
#include <gssapi/gssapi_krb5.h>
#else
#include <gssapi/gssapi_ext.h>
#endif

On Solaris 10 a krb5-config comes back with
krb5-config --version
Solaris Kerberos (based on MIT Kerberos 5 release 1.2.1/1.3.0)

I think it is more 1.3 than 1.2 and the above pkginfo would work too.

Unfortunatly I am not that good in perl otherwise I would have send you a 
patch.

Markus

----- Original Message ----- 
From: "Achim Grolms" <ac...@gr...>
To: "Markus Moeller" <hu...@mo...>
Cc: <bug...@rt...>; "Leif Johansson" <le...@it...>; 
<per...@li...>
Sent: Wednesday, January 30, 2008 6:34 AM
Subject: **SPAM ZEN 79.196.230.199** Re:[Perlgssapi-developer] [rt.cpan.org 
#32788] Enhancement to use OpenSolaris/Solaris 10 native gss library


On Wednesday 30 January 2008, Markus Moeller via RT wrote:
>        Queue: GSSAPI
>  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=32788 >
>
> It is a bit strange I have to admit. On my OpenSolaris I don't need the
> defines, but on Solaris 10 I do.

>From your logfile I can see that your run of
Makefile.PL sets the define for the "MIT 1.2.x workaround":

cc -c  -I/usr/include/kerberosv5 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-xarch=v8 -D_TS_ERRNO -xO3 -xspace -xildoff   -DVERSION=\"0.24\" -DXS_VERSION=\"0.24\"
 -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"  -DMITKERB12
GSSAPI.c

This -DMITKERB12 is set by Makefile.PL triggered by the output of

krb5-config --version

("MIT 1.2.x workaround" means: tweak the defines to make GSSAPI.pm build
against old MIT implementations that don't provide the GSS_C_* style
uppercase constants but only the lowercase constants)

What's the output of krb5-config --version on your Solaris 10?

As far as I can see Makefile.PL tries to use the
"MIT 1.2.x workaround" in that case, but this seems to be wrong because
GSS_C* style constants are already available on the Solaris 10 Kerberos
system.

Can you try to build GSSAPI.pm without the -DMITKERB12 define?
This define is set in Makefile.PL,
you will find the code that checks for "MIT 1.2.x" in Makefile.PL,
too.

sub is_mit_1_2 {
   my ($cfgcmd) = @_;
   my $r = undef;
   my @vinfo = krb5_version( $cfgcmd );
   FOUND: {
      foreach ( @vinfo) {
         if ( m/Kerberos 5 release 1\.2/) {
            $r = 1;
            last FOUND;
         }
       }
   }
   return $r;
}

Does this help?

Thank you,
Achim

Re: [Perlgssapi-developer] [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Achim G. <ac...@gr...>]

On Wednesday 30 January 2008, Markus Moeller via RT wrote:
>        Queue: GSSAPI
>  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=3D32788 >
>
> It is a bit strange I have to admit. On my OpenSolaris I don't need the
> defines, but on Solaris 10 I do.

=46rom your logfile I can see that your run of
Makefile.PL sets the define for the "MIT 1.2.x workaround":

cc -c  -I/usr/include/kerberosv5 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D=
64 =20
=2Dxarch=3Dv8 -D_TS_ERRNO -xO3 -xspace -xildoff   -DVERSION=3D\"0.24\" -DXS=
_VERSION=3D\"0.24\"=20
 -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"  -DMITKERB12=20
GSSAPI.c

This -DMITKERB12 is set by Makefile.PL triggered by the output of

krb5-config --version

("MIT 1.2.x workaround" means: tweak the defines to make GSSAPI.pm build
against old MIT implementations that don't provide the GSS_C_* style
uppercase constants but only the lowercase constants)

What's the output of krb5-config --version on your Solaris 10?

As far as I can see Makefile.PL tries to use the=20
"MIT 1.2.x workaround" in that case, but this seems to be wrong because
GSS_C* style constants are already available on the Solaris 10 Kerberos=20
system.

Can you try to build GSSAPI.pm without the -DMITKERB12 define?
This define is set in Makefile.PL,
you will find the code that checks for "MIT 1.2.x" in Makefile.PL,
too.

sub is_mit_1_2 {
   my ($cfgcmd) =3D @_;
   my $r =3D undef;
   my @vinfo =3D krb5_version( $cfgcmd );
   FOUND: {
      foreach ( @vinfo) {
         if ( m/Kerberos 5 release 1\.2/) {
            $r =3D 1;
            last FOUND;
         }
       }
   }
   return $r;
}

Does this help?

Thank you,
Achim

Re: [Perlgssapi-developer] **SPAM ZEN 83.227.179.169** Re: [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Markus M. <hu...@mo...>]

It is a bit strange I have to admit. On my OpenSolaris I don't need the 
defines, but on Solaris 10 I do.

OpenSolaris:

# make
cp GSSAPI.pm blib/lib/GSSAPI.pm
cp GSSAPI/OID/Set.pm blib/lib/GSSAPI/OID/Set.pm
cp GSSAPI/OID.pm blib/lib/GSSAPI/OID.pm
cp GSSAPI/Status.pm blib/lib/GSSAPI/Status.pm
/usr/bin/perl /usr/perl5/5.8.4/lib/ExtUtils/xsubpp  -typemap 
/usr/perl5/5.8.4/lib/ExtUtils/typemap -typemap typemap  GSSAPI.xs > 
GSSAPI.xsc && mv GSSAPI.xsc GSSAPI.c
cc -c  -I/usr/include/kerberosv5  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
 -D_TS_ERRNO -xO3 -xspace -xildoff    -DVERSION=\"0.24\"  -DXS_VERSION=\"0.24\" 
 -KPIC "-I/usr/perl5/5.8.4/lib/i86pc-solaris-64int/CORE"   GSSAPI.c
Running Mkbootstrap for GSSAPI ()
chmod 644 GSSAPI.bs
rm -f blib/arch/auto/GSSAPI/GSSAPI.so
LD_RUN_PATH="/usr/lib" cc  -G GSSAPI.o  -o 
ib/arch/auto/GSSAPI/GSSAPI.so   -L/usr/lib -R/usr/lib -lgss
chmod 755 blib/arch/auto/GSSAPI/GSSAPI.so
cp GSSAPI.bs blib/arch/auto/GSSAPI/GSSAPI.bs
chmod 644 blib/arch/auto/GSSAPI/GSSAPI.bs
Manifying blib/man3/GSSAPI.3
Manifying blib/man3/GSSAPI::OID::Set.3
Manifying blib/man3/GSSAPI::OID.3
Manifying blib/man3/GSSAPI::Status.3


Solaris 10:

# make
cc -c  -I/usr/include/kerberosv5 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  
-xarch=v8 -D_TS_ERRNO -xO3 -xspace -xildoff   -DVERSION=\"0.24\" -DXS_VERSION=\"0.24\" 
 -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"  -DMITKERB12 
GSSAPI.c
"xs/OID.xs", line 85: undefined symbol: gss_nt_user_name
"xs/OID.xs", line 85: warning: improper pointer/integer combination: op "="
"xs/OID.xs", line 92: undefined symbol: gss_nt_machine_uid_name
"xs/OID.xs", line 92: warning: improper pointer/integer combination: op "="
"xs/OID.xs", line 99: undefined symbol: gss_nt_string_uid_name
"xs/OID.xs", line 99: warning: improper pointer/integer combination: op "="
"xs/OID.xs", line 106: undefined symbol: gss_nt_service_name
"xs/OID.xs", line 106: warning: improper pointer/integer combination: op "="
"xs/OID.xs", line 113: undefined symbol: gss_nt_exported_name
"xs/OID.xs", line 113: warning: improper pointer/integer combination: op "="
"xs/OID.xs", line 120: undefined symbol: gss_nt_service_name
"xs/OID.xs", line 120: warning: improper pointer/integer combination: op "="
"xs/OID.xs", line 174: undefined symbol: gss_nt_service_name
"xs/OID.xs", line 174: warning: improper pointer/integer combination: op "="
cc: acomp failed for GSSAPI.c
make: *** [GSSAPI.o] Error 2


Markus

----- Original Message ----- 
From: "Leif Johansson" <le...@it...>
To: <ac...@gr...>
Cc: <bug...@rt...>; <hu...@mo...>; 
<per...@li...>
Sent: Tuesday, January 29, 2008 11:38 PM
Subject: **SPAM ZEN 83.227.179.169** Re: [Perlgssapi-developer] [rt.cpan.org 
#32788] Enhancement to use OpenSolaris/Solaris 10 native gss library


> Achim Grolms wrote:
>> On Wednesday 30 January 2008, you wrote:
>>
>>>> But *if* GSS_C_NT_HOSTBASED_SERVICE is available and
>>>>  is not used...
>>>> Why the need to define it in GSSAPI.xs?
>>>> Why to define it in "the other direction"?
>>>>
>>>> #define gss_nt_service_name GSS_C_NT_HOSTBASED_SERVICE
>>>>
>>>> Hmm. Am I wrong?
>>>>
>>>> Thank you,
>>>> Achim
>>>>
>>> the only need would be to support applications which relied on the
>>> older definition - I can't think of any.
>>>
>>
>> "Application"... that means application using the GSSAPI.pm
>> module? This applications run against the code in
>> xs/OID.xs :
>>
>>
>> GSSAPI::OID_const
>> gss_nt_service_name()
>>     CODE:
>>         RETVAL = GSS_C_NT_HOSTBASED_SERVICE;
>>     OUTPUT:
>>         RETVAL
>>
>>
>> Is there a point a Perl-application using GSSAPI.pm
>> will have a use for the (C-level) 'gss_nt_service_name'?
>>
>> Thank you,
>> Achim
>>
> Not that I can think of
> 

Re: [Perlgssapi-developer] [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Leif J. <le...@it...>]

Achim Grolms wrote:
> On Wednesday 30 January 2008, you wrote:
>   
>>> But *if* GSS_C_NT_HOSTBASED_SERVICE is available and
>>>  is not used...
>>> Why the need to define it in GSSAPI.xs?
>>> Why to define it in "the other direction"?
>>>
>>> #define gss_nt_service_name GSS_C_NT_HOSTBASED_SERVICE
>>>
>>> Hmm. Am I wrong?
>>>
>>> Thank you,
>>> Achim
>>>       
>> the only need would be to support applications which relied on the
>> older definition - I can't think of any.
>>     
>
> "Application"... that means application using the GSSAPI.pm
> module? This applications run against the code in
> xs/OID.xs :
>
>
> GSSAPI::OID_const
> gss_nt_service_name()
>     CODE:
>         RETVAL = GSS_C_NT_HOSTBASED_SERVICE;
>     OUTPUT:
>         RETVAL
>
>
> Is there a point a Perl-application using GSSAPI.pm
> will have a use for the (C-level) 'gss_nt_service_name'?
>
> Thank you,
> Achim
>   
Not that I can think of

Re: [Perlgssapi-developer] [rt.cpan.org #32788] Enhancement to use OpenSolaris/Solaris 10 native gss library

[Achim G. <ac...@gr...>]

On Wednesday 30 January 2008, you wrote:
> > But *if* GSS_C_NT_HOSTBASED_SERVICE is available and
> >  is not used...
> > Why the need to define it in GSSAPI.xs?
> > Why to define it in "the other direction"?
> >
> > #define gss_nt_service_name GSS_C_NT_HOSTBASED_SERVICE
> >
> > Hmm. Am I wrong?
> >
> > Thank you,
> > Achim
>
> the only need would be to support applications which relied on the
> older definition - I can't think of any.

"Application"... that means application using the GSSAPI.pm
module? This applications run against the code in
xs/OID.xs :


GSSAPI::OID_const
gss_nt_service_name()
    CODE:
        RETVAL = GSS_C_NT_HOSTBASED_SERVICE;
    OUTPUT:
        RETVAL


Is there a point a Perl-application using GSSAPI.pm
will have a use for the (C-level) 'gss_nt_service_name'?

Thank you,
Achim