-
Notifications
You must be signed in to change notification settings - Fork 46
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
extensible credential format #87
Comments
Hey Chris - Just curious if you had any timeframe for working towards this, or even potential interest in an external submission working towards this. In addition to the aforementioned SELinux security context issues, I have a potential use case for embedding the username (text string) within the credential, but this is obviously blocked by the current hard-coded credential format.
|
Hey Tim. This is at the top of my list when I cycle back to munge development (in the next couple of months?). This has been a blocker on new features for me as well. I need to finish thinking through the design to make sure it supports the future plans I have in mind. As part of this work, I'm envisioning adding a function to embed/extract custom payloads specified by an integer tag, buffer, and length. I think that would support your potential use case. I'll try to set aside some time in the next couple of weeks to poke at the design and post my plans here. |
Dear Chris, I have the same questions as @wickberg. Thanks. |
@victorusu: I'm currently busy adding functionality for our new cluster. Once that's working, I'll start on the next munge release. The new credential format is needed for much of the planned functionality going forward. Is there a particular feature or functionality you're interested in? |
The credential format v3 is not extensible. Supporting planned new features will require a new credential format. This format should be extensible to accommodate new features and functionality without having to update to another fixed format requiring backwards-compatibility to old formats.
Planned new features include:
time_t
values (support 64-bit time_t values #88)The text was updated successfully, but these errors were encountered: