Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove dependency on libkadm5clnt_mit.so #13

Open
iNecas opened this issue Jun 29, 2016 · 4 comments
Open

remove dependency on libkadm5clnt_mit.so #13

iNecas opened this issue Jun 29, 2016 · 4 comments

Comments

@iNecas
Copy link

iNecas commented Jun 29, 2016

The libkadm5clnt_mit.so is considered highly unstable by the upstream and it's quite likely it gets removed form/broken in next krb5 releases (see https://bugzilla.redhat.com/show_bug.cgi?id=1330431 for more details).

@djberg96
Copy link
Collaborator

@iNecas What's the current standard? Heimdal?

@pkis
Copy link

pkis commented Jul 1, 2016

While the kerberos protocol is standardized (RFC 4120) the admin protocol is not.

Regarding the API, admin.h states:
/*

  • This API is not considered as stable as the main krb5 API.
    *
  • - We may make arbitrary incompatible changes between feature
  • releases (e.g. from 1.7 to 1.8).
  • - We will make some effort to avoid making incompatible changes for
  • bugfix releases, but will make them if necessary.
    */

Not sure about Heimdal, but I have not found any reference to admin API.

@sonOfRa
Copy link
Collaborator

sonOfRa commented Oct 5, 2016

I'm not sure how I can work around this. While redhat doesn't seem to use the kadmin API functionality of this gem, I use it quite extensively myself, so removing it would be counterproductive, as we don't have anything else that provides the same API (short of dropping shell commands and piping output into them). I'm not sure how to resolve this as of now, so I'd say the dependency will stay for now, unless someone comes up with a good idea to work around it.

@djberg96
Copy link
Collaborator

djberg96 commented Oct 5, 2016

Although I resisted it originally, I now think the admin portion should be split into its own gem. While this doesn't wholly address the issue here, it would at least allow the client portion to ignore such issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants