Open rndquu opened 3 months ago
@gentlementlegen Pls check the description
Error: incorrect key pair for the given ciphertext
I believe this is the error thrown for
- Encrypted param with another PK
Another idea for a future vision of mine (perhaps out of scope for this task) is to abstract the GitHub UI with a Ubiquity app that looks like the following:
And behind the scenes we handle the forking on behalf of the user and populate the secrets.
This approach can generally allow us to build on top of GitHub as our backend while still being able to control the end user experience.
Another idea for a future vision of mine (perhaps out of scope for this task) is to abstract the GitHub UI with a Ubiquity app > that looks like the following:
- Login with GitHub
- Setup wizard with some text input fields for the secrets
- Save button
This is basically https://github.com/ubiquity/onboard.ubq.fi v2 where users should be able to edit their configs via UI.
So you propose to try to decrypt every parameter in the config instead of creating a special prefix like _UBIQUITY_ENCRYPTED_PARAM=
?
So you propose to try to decrypt every parameter in the config instead of creating a special prefix like
_UBIQUITY_ENCRYPTED_PARAM=
?
Yes
I don't fully understand how the _UBIQUITY_ENCRYPTED_PARAM
prefix may be used. For example, if partner wants to encrypt the evmPrivateEncrypted param then how to tell the kernel that param is encrypted? Either via some custom prefix, like evmPrivateEncrypted_UBIQUITY_ENCRYPTED_PARAM
or via introducing a new param option so the config could look like:
plugins:
issues.closed:
- uses:
- plugin: rndquu/conversation-rewards@fix/nonce-generation
with:
evmPrivateEncrypted:
value: "wOzNgt-yKT6oFlOVz5wrBLUSYxAbKGE9Co-yvT8f9lePsx7wJwPVugS9186zdhr1T4UpkpXvq9ii5M-nWfrydMnllSkowH4LirRZsHbvRVSvDoH_uh80p6HpwqDSG3g4Nwx5q0GD3H-ne4vwXMuwWAHd"
encrypted: true
I wanted things to be backwards compatible. But if decrypting every param takes time (or there are other issues with this approach) then we could stick to the encrypted
option param or suffixes.
like this
plugins:
issues.closed:
- uses:
- plugin: rndquu/conversation-rewards@fix/nonce-generation
with:
evmPrivateKey: "_UBIQUITY_ENCRYPTED_PARAM=wOzNgt-yKT6oFlOVz5wrBLUSYxAbKGE9Co-yvT8f9lePsx7wJwPVugS9186zdhr1T4UpkpXvq9ii5M-nWfrydMnllSkowH4LirRZsHbvRVSvDoH_uh80p6HpwqDSG3g4Nwx5q0GD3H-ne4vwXMuwWAHd"
like this
plugins: issues.closed: - uses: - plugin: rndquu/conversation-rewards@fix/nonce-generation with: evmPrivateKey: "_UBIQUITY_ENCRYPTED_PARAM=wOzNgt-yKT6oFlOVz5wrBLUSYxAbKGE9Co-yvT8f9lePsx7wJwPVugS9186zdhr1T4UpkpXvq9ii5M-nWfrydMnllSkowH4LirRZsHbvRVSvDoH_uh80p6HpwqDSG3g4Nwx5q0GD3H-ne4vwXMuwWAHd"
For me this way of telling the kernel that param is encrypted is more straightforward:
plugins:
issues.closed:
- uses:
- plugin: rndquu/conversation-rewards@fix/nonce-generation
with:
evmPrivateEncrypted:
value: "wOzNgt-yKT6oFlOVz5wrBLUSYxAbKGE9Co-yvT8f9lePsx7wJwPVugS9186zdhr1T4UpkpXvq9ii5M-nWfrydMnllSkowH4LirRZsHbvRVSvDoH_uh80p6HpwqDSG3g4Nwx5q0GD3H-ne4vwXMuwWAHd"
encrypted: true
I agree your approach looks good but what if someone creates a plugin with the same structure. Maybe we can change encrypted
to ubiquityEncrypted
?
I wanted things to be backwards compatible.
We shouldn't put effort into this until its necessary. We don't have active partners, however now at conferences I've been more focused on meeting prospective partners and investors.
Even if we get active partners (theres a couple interested in the pipeline) we can version lock plugins and things, right? Not sure if we can do versioned deployments of the kernel but that would be the final step to making things totally version-able and we no longer have to worry at all about backwards compatibility.
For us internally I think we should always be running the latest to catch problems faster.
I agree your approach looks good but what if someone creates a plugin with the same structure. Maybe we can change
encrypted
toubiquityEncrypted
?
Yes, plugin developer may create a param with the encrypted
name.
To sum up there are at least 3 options:
plugins:
issues.closed:
- uses:
- plugin: rndquu/conversation-rewards@fix/nonce-generation
with:
evmPrivateKey: "_UBIQUITY_ENCRYPTED_PARAM=wOzNgt-yKT6oFlOVz5wrBLUSYxAbKGE9Co-yvT8f9lePsx7wJwPVugS9186zdhr1T4UpkpXvq9ii5M-nWfrydMnllSkowH4LirRZsHbvRVSvDoH_uh80p6HpwqDSG3g4Nwx5q0GD3H-ne4vwXMuwWAHd"
plugins:
issues.closed:
- uses:
- plugin: rndquu/conversation-rewards@fix/nonce-generation
with:
evmPrivateEncrypted:
value: "wOzNgt-yKT6oFlOVz5wrBLUSYxAbKGE9Co-yvT8f9lePsx7wJwPVugS9186zdhr1T4UpkpXvq9ii5M-nWfrydMnllSkowH4LirRZsHbvRVSvDoH_uh80p6HpwqDSG3g4Nwx5q0GD3H-ne4vwXMuwWAHd"
ubiquityEncrypted: true
We could also reserve _
or some other special symbol 🔒
⚿
as a prefix for encrypted properties. The emoji isn't very aesthetic but it is functional and expressive.
plugins:
issues.closed:
- uses:
- plugin: rndquu/conversation-rewards@fix/nonce-generation
with:
🔒evmPrivateKey: "wOzNgt-yKT6oFlOVz5wrBLUSYxAbKGE9Co-yvT8f9lePsx7wJwPVugS9186zdhr1T4UpkpXvq9ii5M-nWfrydMnllSkowH4LirRZsHbvRVSvDoH_uh80p6HpwqDSG3g4Nwx5q0GD3H-ne4vwXMuwWAHd"
I tested all three while drafting my comment and I think that the lock emoji might be best. It might even be a strength that it renders in color (on macOS it is gold) so that it is easily noticeable.
So in conclusion it appears that the task is to read every config property, and if it includes the lock symbol, to attempt to decrypt it.
RFC @rndquu @whilefoo @gentlementlegen
I would be worried that we'd have issues on encode and decode configurations, I do not know if Unicode characters are properly handled by the library we are using, so it should be tested.
Although locked emoji does look good I anticipate issues in unexpected places. I think with decrypting sensitive config values we should be as explicit as possible.
Right now there are 2 ways to hide sensitive bot's config parameters:
Sensitive config parameters could be encrypted via our own
x25519_PUBLIC_KEY
(the same one we use for encrypting partners' private keys) and the kernel could then decrypt them.So as a part of this issue the kernel should be able to decrypt config parameters on initial config parsing.
The expected flow for parsing a single config param:
Notice that there is a difference between decrypting:
I hope https://doc.libsodium.org/ distinguishes those 2 errors because in the 2nd case it will be a very subtle bug and the kernel should ideally throw an error like
The config parameter encryption is invalid
so that partner knew he did something wrong on encrypting a param.P.S. Handy tool: https://keygen.ubq.fi/