Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.9.3p2) with ESMTP id WAA18244; Wed, 21 Feb 2007 22:52:53 -0500 (EST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l1M3qNqN027220; Wed, 21 Feb 2007 22:52:23 -0500 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l1M3qLbT027210 for ; Wed, 21 Feb 2007 22:52:21 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l1M3q3rX013072; Wed, 21 Feb 2007 22:52:03 -0500 (EST) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l1M3q2Jv020775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Feb 2007 22:52:02 -0500 (EST) MIME-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37A25F01-F4F9-4F23-B666-120E7B45F5A0@mit.edu> Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: gsstest doesn't like krb5-1.6 GSSAPI library Date: Wed, 21 Feb 2007 22:51:35 -0500 To: krb5-bugs@MIT.EDU X-Mailer: Apple Mail (2.752.2) X-Scanned-BY: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu X-RT-Original-Encoding: us-ascii Content-Length: 1927 I'm playing with gsstest-1.26 (the latest on the SAP FTP site, though I've seen mentions on the net of a 1.27 which I haven't tracked down) and the 1.6 branch. First problem: gss_canonicalize_name returns a name that will be rejected by gss_release_name in the mechglue code because the "loopback" field is not set properly. With that problem quickly hacked around, it's still reporting three problem cases: TEST: acquiring *default* accepting credentials (simple) Status: gss_inquire_cred Acc() == (GSS_S_DEFECTIVE_CREDENTIAL) gss_display_status(0x000a0000,GSS_S_GSS_CODE) = "Invalid credential was supplied" RESULT NOT ok (rc=1) It looks like acquiring the default acceptor credentials doesn't produce an error, but calling gss_inquire_cred on the result to get a name out does, because internally it tries to import an empty name. (Acquiring the acceptor credentials by name was a previous test, and worked fine.) TEST: acquiring *default* accepting credentials (query) Status: gss_inquire_cred Acc() == (GSS_S_DEFECTIVE_CREDENTIAL) gss_display_status(0x000a0000,GSS_S_GSS_CODE) = "Invalid credential was supplied" RESULT NOT ok (rc=1) The "query" version of this test looks at the name in the acquired credentials, plays some games with exporting and importing and canonicalizing the name, then tries to acquire credentials using the resulting name. TEST: Trying gss_import_name() with "" Status: gss_import_name() == (GSS_S_CALL_INACCESSIBLE_READ| GSS_S_BAD_NAME) gss_display_status(0x01020000,GSS_S_GSS_CODE) = "A required input parameter could not be read" "An invalid name was supplied" ERROR: gss_import_name() didn't return GSS_S_BAD_NAME or GSS_S_FAILURE! RESULT NOT ok (rc=1) The test program uses an empty string, not a null or invalid pointer, so INACCESSIBLE_READ is probably incorrect. Ken