Allow to set custom trusted clone plugins

[qwerty287]

closes #2601

[woodpecker-bot]

Deployment of preview was torn down

[pat-s]

How is that different to WOODPECKER_PLUGINS_TRUSTED_CLONE?

[xoxys]

You can now set it per repo as well.

[6543]

You can now set it per repo as well.

did not checked the code jet - but ony an instance admin should be able to change it

[6543]

one question (idea) that comes into my mind: why not add the config into TrustedConfiguration ?

[xoxys]

did not checked the code jet - but ony an instance admin should be able to change it

Repeating it doesnt help. Can we keep the discussion in the issue? You never responded to #2601 (comment)

[qwerty287]

Why the instance admin? This is about per-repo/per-user credentials, so the repo admins should decide how they are used.

[6543]

Why the instance admin? This is about per-repo/per-user credentials, so the repo admins should decide how they are used.

on public instances like e.g. codeberg:

1. an malicious aktor creates a new repo (-> repo admin (same is valid for org))
2. change the trusted clone plugin to one that extracts netrc and send it tho him
3. motivate other users to create pull requests to e.g. fix a type or what not
4. other users got there account hijacked

[xoxys]

But this would need a private repo then. And if the repo is private you can not easily convince people to contribute to exfiltrate their netrc credentials.

[6543]

limited repos are enouth ...

[xoxys]

What are limited repos? Netrc credentials are only required for cloning private repos and at least for gh there is only private/public.

[pat-s]

Limited -> logged-in users only
Private -> Fully-private / only visible to explicit org/repo members

---

How about adding a global option which allows changing WOODPECKER_PLUGINS_TRUSTED_CLONE on a repo level in the first place?

[xoxys]

Ok this only applies to gitea/forgejo then? Global option to toggle it sounds good to me.

[qwerty287]

I still don't get why. Cloning should always happen with the credentials from the "repo-user", i.e. the user that activeated the repo. If you now have a malicious repo and somebody creates a PR to this, how can this expose credentials except the repo-user ones?

[anbraten]

I still don't get why. Cloning should always happen with the credentials from the "repo-user", i.e. the user that activeated the repo. If you now have a malicious repo and somebody creates a PR to this, how can this expose credentials except the repo-user ones?

I think so as well. The person activating a repo (or repairing later on) will be used for cloning. You could only try to ask someone to create an org repo for you and then steal those credentials (which is possible already).

[xoxys]

Is this currently really the case already? I thought cloning is done by the user who made the commit.

[qwerty287]

That's actually impossible because wp can't have the credentials if the user who opens a pr is not registered at the wp instance (for example any non-maintainer on our repos).

[pat-s]

That's actually impossible because wp can't have the credentials if the user who opens a pr is not registered at the wp instance (for example any non-maintainer on our repos).

Makes sense. Hence, all security concerns don't apply?

[zc-devs]

You could only try to ask someone to create an org repo for you and then steal those credentials

Not necessary to ask. There could be a couple of repo admins in the org. One admin adds a repo, another adds a custom image and steals the creds of the first one. But this is matter of trust between the admins of an org. It's unlikely that they would do this in their right minds.

which is possible already

How?

user who opens a pr is not registered

There is crons also.

---

This magic should be in the docs (#4232). Seems, Bitbucket Datacenter works differently in regard of cloning.

[6543]

That's actually impossible because wp can't have the credentials if the user who opens a pr is not registered at the wp instance (for example any non-maintainer on our repos).

Makes sense. Hence, all security concerns don't apply?

uh nice - that's one of the things I was going to have to lookup :)

in this case I'm ok with as is :)

[pat-s]

Fine for you given the discussion above.