-
Notifications
You must be signed in to change notification settings - Fork 16
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
fix: signature check #9
fix: signature check #9
Conversation
Update worker-deploy.yml
Will need someone who has access to the
Or some equivalent to generate the matching public key and then set en environment variable |
Where |
I added it to this repository's secrets. |
the public key will be hardcoded in the SDK |
@whilefoo not sure to understand then, the plug-ins would need it as well? That's how you did the code within assistive-plugin |
Also I realized this is going to be a problem. How will we handle key rotation? |
the SDK will be a package that the plugins import and use to setup a HTTP server (worker), the public key of the kernel will be in the SDK but it can also be overriden when using the SDK.
If the keypair changes we can publish a new version, but a problem will be because plugins won't update to the next version immediately. I assume key changes will be rare so it's fine for now. |
I think we can plan for annual minimum but quarterly seems prudent. I suppose we should support clear errors for invalid keys. |
@whilefoo Okay thanks for the info. So before that SDK is done, shall I keep the PR on hold? |
I think never keep any pull on hold. Merge and then we make a new task to make necessary adjustments later. We never know how long it will take to get the new stuff done. More thoughts on this philosophy here. |
I agree, let's merge and I will open a new PR when SDK is ready |
fb1dfb8
into
ubiquity-os-marketplace:development
…/signature-check fix: signature check
Resolves #8