Patches pending review

Rob Crittenden rcritten at redhat.com
Tue May 5 20:22:29 UTC 2015


Rob Crittenden wrote:
> Simo Sorce wrote:
>> ----- Original Message -----
>>> From: "Rob Crittenden" <rcritten at redhat.com>
>>> To: "Ipsilon" <ipsilon at lists.fedorahosted.org>
>>> Sent: Tuesday, May 5, 2015 2:13:48 PM
>>> Subject: Patches pending review
>>>
>>> Here is a list of the patches I have pending review:
>>>
>>> ticket 35:
>>> https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit/?h=logger&id=41ea3772220b37690c7fae6a79f1b13efc7a4f8b
>>
>> This one looks good but seem to need a rebase, cherry-pick barfs.
> 
> Rebased.
> 
>>
>>> ticket 90:
>>> https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/log/?h=db_sessions
>>
>> I've had no time to look at this one yet.
>>
>>> ticket 111:
>>> https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit/?h=no_sssd_ui&id=f6d2225ec4325275f1eeb0b8089f1d598a7e7fc4
>>
>> This is reaaaallly ugly, can we rather have a config option we look for and not enable sssd
>> if this optoin is not set ?
>> This way you *can* enable/disable it via the admin UI, which is handy if you are testing
>> stuff as an admin, you just shouldn't be able to change the configuration. (mark the module
>> cnfiguration with a "read-only" property somewhere ?
> 
> No argument there about the ugly. I was trying to avoid creating a whole
> new mechanism to manage this one plugin, and I think I was looking at
> enable/disable differently.
> 
> So I was looking at a much lower level, where disabling the plugin would
> actually unconfigure it in sssd, apache, etc rather than just having the
> info plugin not fire when a user authenticates. Configure is similar. If
> the plugin was enabled at install time then one can turn it on/off but
> if not, you're stuck.
> 
> The other complicating factor is that the same enable/disable code gets
> called both by the UI and during startup, so some state information is
> needed to know whether one can properly allow it or not.
> 
> I can see about setting a config option during install that would
> indicate whether the underlying plumbing is configured or not and
> perhaps base enable/disable requests on that. I'll take a look.
> 
> 
>>> ticket 116:
>>> https://fedorapeople.org/cgit/rcritten/public_git/ipsilon.git/.git/commit/?h=gssapi_test
>>
>> I think we shouldn't really allow non-mutual auth, if that check is because mod_auth_gssapi
>> fails to reutn the token on a 200 OK, then we just need to require a new enough
>> mod_auth_gssapi, Ifixed that bug in master a couple of weeks ago, and can make a release
>> if necessary.
> 
> Yeah, that'd be great. In the meantime I'll pull the upstream source and
> do some local testing.

I tested upstream release 1.2.0 and mod_auth_gssapi is still not sending
back a header for mutual auth when auth succeeds.

rob



More information about the ipsilon mailing list