Except for the "static object" agreed.
FWIW, I don;t think we can have something for iteration 5, we need to stabilize interfaces a lot more before it makes sense to expose them. IMO this is a v1 target (I changed the version accordingly)

priority: critical => major
version: 0.4.0 => 1.0

In the 3rd party documentation we need to cover what we expect developers to use confdb, sysdb we provide. We also need to explain that there are other alternatives. If 3rd party vendor does not want to use default back end and stand up their own (that will read its own configuration and implement DBUS itself) they are also welcome.
But this means that we have to keep DBUS public... Not good...
Anyways the concern is that creating a lot of rules might be a problem for 3rd party vendors that are used to developing binaries that do everything themselves rather than a plugin that relies on a lot of already provided source. For some vendors it is a very scary approach since it assumes trusting somebody else's code.
I know couple companies that would not like it. Unfortunately we want them to write back ends for SSSD.

I'm going to go out on a limb here and say that we should absolutely not make the SBUS protocol public. The sssd_be process exists solely to implement that transport so the back-ends do not have to. The sssd_be process does nothing but load plugins that perform all of the actual heavy lifting and provides a public interface to our private SBUS protocol.

Given that all business logic is performed in the back-end plugin, I don't see any reason why a 3rd-party vendor would see any benefit in reinventing the back-end binary, since it does very little beyond loading the private plugin and passing messages to the master data provider. No business logic is ever performed in the sssd_be binary.

Dmitri, you say that you know a couple companies that wouldn't like it. I doubt this is true, as it's no more restrictive than writing a PAM module (it presents a set of interfaces that the shared object must implement and defines the return values it accepts).

fixedin: =>

Fields changed

priority: major => critical

Moving to bugfix-only development until after 0.5.0. Lowering priority.

priority: critical => major

Fields changed

milestone: Iteration 5 => SSSD 1.0

Fields changed

doc: => 0
docupdated: => 0
milestone: SSSD 1.0 => SSSD 1.0 RC
priority: major => critical
tests: => 0
testsupdated: => 0

Fields changed

status: new => assigned

Taking this back off my plate for the moment. Per discussion with Simo, our interfaces are not stable enough yet to create this package. It will probably wait until after the daemon is feature-complete.

status: assigned => new

Fields changed

milestone: SSSD 1.0 RC => SSSD 1.0

Fields changed

milestone: SSSD 1.0 => SSSD 1.1

Fields changed

priority: critical => blocker

Some months ago Simo mentioned that it might be a good idea to use the tevent request schema to access the backend. I think it would make sense to move to tevent before making the API "public", but I'm not sure if this change is considered too big for 1.1?

cc: => simo

The purpose of the devel package should be to allow 3rd parties including closed source to build back ends for the SSSD. We can use tevent inside the front end as much as we want but having any parts of it inside the back end can be a problem for a third party.

Per a discussion we had on IRC this morning, I think our plan is that we will stabilize and expose the D-BUS API instead of providing the library-loader for third-party implementations.

This will also remove any concerns about licensing of the backends.

Fields changed

status: new => assigned

Deferring to 1.2. It's too soon to release a stable public API.

milestone: SSSD 1.1 => SSSD 1.2

Fields changed

milestone: SSSD 1.2 => SSSD 1.3

Fields changed

priority: blocker => minor

Fields changed

milestone: SSSD 1.5.0 => SSSD 1.6.0

Fields changed

coverity: =>
milestone: SSSD 1.6.0 => SSSD 1.7.0
upgrade: => 0

Fields changed

milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Deferred
rhbz: =>

Fields changed

rhbz: => 0

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1086

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.