From: Luke Howard <lukeh@padl.com>
Date: Thu, 6 Oct 2011 10:34:10 +0000 (+1100)
Subject: note about whether initiator cred lock is required
X-Git-Url: http://www.project-moonshot.org/gitweb/?p=mech_eap.orig;a=commitdiff_plain;h=baf4059512ee0d7863be23bfebb39f5645f2d61a

note about whether initiator cred lock is required
---

diff --git a/mech_eap/TODO b/mech_eap/TODO
index 9a7972b..0111459 100644
--- a/mech_eap/TODO
+++ b/mech_eap/TODO
@@ -1,6 +1,6 @@
 - integration with initiator-side EAP channel bindings
+- investigate initiator-side credential locking
 - always intern OIDs so they never need to be freed
 - handle many-to-many Shibboleth attribute mappings; need to encode both attribute and value index into more
 - add --with-xerces option
 - proper acquire_cred_ext implementation pending specification
-
diff --git a/mech_eap/init_sec_context.c b/mech_eap/init_sec_context.c
index 46e925e..15e0520 100644
--- a/mech_eap/init_sec_context.c
+++ b/mech_eap/init_sec_context.c
@@ -961,6 +961,11 @@ gssEapInitSecContext(OM_uint32 *minor,
     OM_uint32 major, tmpMinor;
     int initialContextToken = (ctx->mechanismUsed == GSS_C_NO_OID);
 
+    /*
+     * XXX is acquiring the credential lock here necessary? The password is
+     * mutable but the contract could specify that this is not updated whilst
+     * a context is being initialized.
+     */
     if (cred != GSS_C_NO_CREDENTIAL)
         GSSEAP_MUTEX_LOCK(&cred->mutex);