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

Suitable to use for signing of models today? #359

Open
stefanberger opened this issue Mar 4, 2025 · 4 comments
Open

Suitable to use for signing of models today? #359

stefanberger opened this issue Mar 4, 2025 · 4 comments
Labels
question Further information is requested

Comments

@stefanberger
Copy link

Question

I was wondering whether the library and the format it is producing/using are suitable for signing models today or whether there may be something still missing?

@stefanberger stefanberger added the question Further information is requested label Mar 4, 2025
@mihaimaruseac
Copy link
Collaborator

We are planning to do a v1.0 release by the end of month if all goes well. From that point on, everything would be stable, backwards compatible.

Right now, you can test this, but we might need to change some parts here and there, so you might need to run some migration work after the v1.0 release.

@stefanberger
Copy link
Author

stefanberger commented Mar 5, 2025

Thanks for the response.

I have been playing around with signing with this library and found this particularly useful: instructlab/instructlab#1181 (comment) So, there could be a file with (potential) name oidc.yaml containing the identity and issuer of the signer... and maybe more (?). The file would be generated by the signing tool and help the lazy user (who exactly knows who the expected signer is supposed to be) just verify the model files by just confirming these:

oidc:
  identity: [email protected]
  issuer: https://accounts.google.com

What do you think about this type of file as part of 'standard model signing'?

@mihaimaruseac
Copy link
Collaborator

I think this could be part of the deployment strategy and could work if all the identities are expected to come from the same issuer.

Adding @haydentherapper for another point of view here

@stefanberger
Copy link
Author

I think this could be part of the deployment strategy and could work if all the identities are expected to come from the same issuer.

The format and contents of this oidc.yaml file has to correspond the verification process in some way. Do you have support for multiple identities or are you planning on supporting something like this?

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

No branches or pull requests

2 participants