search

ubiquibot / comment-incentives

0 stars 10 forks source link

Updated workflow inputs #29

Open whilefoo opened 4 months ago

whilefoo commented 4 months ago

This modifies the workflow inputs so that they are compatible with the new kernel.

It accepts four inputs:

0x4007 commented 4 months ago

I am currently doing some research on making a plugin based on new architecture. Why not just pass in the auth token from the kernel? Seems redundant that each plugin needs to figure out auth every time.

https://github.com/pavlovcik/conversation-rewards/commit/1f4ba009bd81b3cbea79e8cde1735407d0504037#diff-1243c5424efaaa19bd8e813c5e6f6da46316e63761421b3e5f5c8ced9a36e6b6R3-R6

whilefoo commented 4 months ago

I am currently doing some research on making a plugin based on new architecture. Why not just pass in the auth token from the kernel? Seems redundant that each plugin needs to figure out auth every time.

pavlovcik/conversation-rewards@1f4ba00#diff-1243c5424efaaa19bd8e813c5e6f6da46316e63761421b3e5f5c8ced9a36e6b6R3-R6

I thought about that but if the plugin is public then anybody can see the token, but it's not a problem if plugins are all private but even then anyone with the access to the repo can use the token

0x4007 commented 4 months ago

I am currently doing some research on making a plugin based on new architecture. Why not just pass in the auth token from the kernel? Seems redundant that each plugin needs to figure out auth every time. pavlovcik/conversation-rewards@1f4ba00#diff-1243c5424efaaa19bd8e813c5e6f6da46316e63761421b3e5f5c8ced9a36e6b6R3-R6

I thought about that but if the plugin is public then anybody can see the token, but it's not a problem if plugins are all private but even then anyone with the access to the repo can use the token

I suppose that it depends on the partner if they want to use the plugin (do they trust it? Perhaps there is a way to invoke it based on a specific commit, which is great for security)

Aside from that, technically plugins can be hosted on Cloudflare Workers etc and the logs wont be public right

whilefoo commented 4 months ago

Actually I thought the inputs are visible in the UI but I've checked again and they are not.

I'm wondering if there's a way to generate an auth token with only read access because giving an auth token means the plugin can post comments as ubiquibot and has every permission that ubiquibot has.

0x4007 commented 4 months ago

can post comments as ubiquibot and has every permission that ubiquibot has.

Its scoped per installation ID (per organization, not repo, I believe.)

It is the partner's responsibility if they connect a bad plugin.

ChatGPT says we can't generate a token with less permissions. It suggests to make another GitHub App with less permissions and use its token instead (not feasible, I think its annoying to ask partners to add two apps.)

whilefoo commented 4 months ago

Its scoped per installation ID (per organization, not repo, I believe.)

Installation can be either on repo or organization.

It is the partner's responsibility if they connect a bad plugin.

But I still think it's still better to give the plugin only the read permissions (principle of least privilege). Maybe a plugin's repo is hijacked or the maintainer goes rogue.

0x4007 commented 4 months ago

Its scoped per installation ID (per organization, not repo, I believe.)

Installation can be either on repo or organization.

I know we can install the app and scope it to repo or org BUT I am pretty sure that the installation ID will be identical across every repository. Regardless if they installed it only on two repos, or they installed it org wide.

It is the partner's responsibility if they connect a bad plugin.

But I still think it's still better to give the plugin only the read permissions (principle of least privilege). Maybe a plugin's repo is hijacked or the maintainer goes rogue.

I think its really worthwhile to figure out if we can support commit hashes in our config. For example:

workflow: ubiquibot/conversation-rewards@18b21c6ede3ed4f5a27c011f3441b888b6cdfd47

It's impossible for a rouge hacker to spoof that.

But honestly even with my level of knowledge I don't think I would specify the commit hash. Seems a bit paranoid. We should just tightly scope the permissions of the bot once we are properly in production to not be able to cause mass chaos across an organization.

0x4007 commented 4 months ago

Consider this schema https://github.com/ubiquity/ubiquibot-kernel/issues/25#issuecomment-1959403559