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

fix: signature check #9

Conversation

gentlementlegen
Copy link
Member

Resolves #8

@gentlementlegen
Copy link
Member Author

Will need someone who has access to the UBIQUIBOT_PRIVATE_KEY to run the following:

openssl rsa -in UBIQUIBOT_PRIVATE_KEY.pem -pubout -out UBIQUIBOT_PUBLIC_KEY.pem

Or some equivalent to generate the matching public key and then set en environment variable UBIQUIBOT_PUBLIC_KEY with that value. Might be worth setting across the organization since every Worker will have to check this, thanks!

@gentlementlegen gentlementlegen marked this pull request as ready for review June 17, 2024 15:43
@0x4007
Copy link
Member

0x4007 commented Jun 17, 2024

then set en environment variable UBIQUIBOT_PUBLIC_KEY

Where

@0x4007
Copy link
Member

0x4007 commented Jun 17, 2024

then set en environment variable UBIQUIBOT_PUBLIC_KEY

Where

I added it to this repository's secrets.

@whilefoo
Copy link
Member

Might be worth setting across the organization since every Worker will have to check this, thanks!

the public key will be hardcoded in the SDK

@0x4007
Copy link
Member

0x4007 commented Jun 17, 2024

@gentlementlegen
Copy link
Member Author

@whilefoo not sure to understand then, the plug-ins would need it as well? That's how you did the code within assistive-plugin

@0x4007
Copy link
Member

0x4007 commented Jun 17, 2024

Also I realized this is going to be a problem. How will we handle key rotation?

@whilefoo
Copy link
Member

@whilefoo not sure to understand then, the plug-ins would need it as well? That's how you did the code within assistive-plugin

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.

Also I realized this is going to be a problem. How will we handle key rotation?

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.

@0x4007
Copy link
Member

0x4007 commented Jun 17, 2024

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.

@gentlementlegen
Copy link
Member Author

@whilefoo Okay thanks for the info. So before that SDK is done, shall I keep the PR on hold?

@0x4007
Copy link
Member

0x4007 commented Jun 18, 2024

@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.

@whilefoo
Copy link
Member

I agree, let's merge and I will open a new PR when SDK is ready

@whilefoo whilefoo merged commit fb1dfb8 into ubiquity-os-marketplace:development Jun 18, 2024
2 checks passed
@gentlementlegen gentlementlegen deleted the fix/signature-check branch August 20, 2024 19:17
gentlementlegen pushed a commit to gentlementlegen/daemon-pricing that referenced this pull request Sep 23, 2024
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

Successfully merging this pull request may close these issues.

Crash on missing environment variable
3 participants