note about whether initiator cred lock is required

diff --git a/moonshot/mech_eap/TODO b/moonshot/mech_eap/TODO
index 9a7972b..0111459 100644 (file)
--- a/moonshot/mech_eap/TODO
+++ b/moonshot/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/moonshot/mech_eap/init_sec_context.c b/moonshot/mech_eap/init_sec_context.c
index 46e925e..15e0520 100644 (file)
--- a/moonshot/mech_eap/init_sec_context.c
+++ b/moonshot/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);