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.

Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to