[Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate

Martin Kosek mkosek at redhat.com
Mon Aug 8 11:43:42 UTC 2016


On 08/08/2016 01:31 PM, Jan Pazdziora wrote:
> On Mon, Aug 08, 2016 at 12:52:33PM +0200, Martin Kosek wrote:
>>
>> I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so let
>> me repeat my suggestion here. I still think it is premature to add plugins like
>> that to FreeIPA core git. We are not agreed yet how we will distribute FreeIPA
>> plugins, so I would not rush adding this plugin to FreeIPA core, especially
>> since it is very experimental and not even secure yet. FreeIPA plugin
>> distribution should be more thought through and discussed.
>>
>> As I proposed, this plugin can now live outside of FreeIPA core git, in it's
>> own life cycle (maybe in freeipa-plugins github git repo we create?) so that it
>> can be updated without updating whole FreeIPA core. In this effort, I would
>> suggest to only consider updates of
>>
>> * ipaserver/plugins/xmlserver.py
>> * ipaserver/rpcserver.py
>>
>> as these would have to patched by admin deploying this feature and would be
>> overwritten by RPM updates. The plugin itself or server.conf can be deployed
>> and installed separatenly, even via other RPM.
> 
> We want the feature (albeit experimental) to be available to upstream
> users and downstream customers, with as few steps to take and as few
> hoops to jump through as possible. Any bits we can get to users' and
> customers' hands via standard means are bits that they don't need to
> get from elsewhere, via nonstandard means, with us inventing and
> supporting these nonstandards processes.
> 
> Assuming the mere existence of the functionality (which will be
> disabled by default) does not decrease security of the default
> installations and configuration, I don't see why carrying it poses
> a problem.

I see your reasoning, I just think it is not strong enough to rush this new
method of delivering plugins in before discussing it more broadly.

Also, as I mentioned, we may want different life cycle for FreeIPA plugins that
we want for FreeIPA core bits. Thus the different repository suggestion. This
whole feature is (still) non-standard and experimental, so I do not personally
see that big problem in non-standard delivery mechanism.

Martin




More information about the Freeipa-devel mailing list