QA from CI engine notification through API need write access

[gd197]

Description

Since gitea 1.16.9, it looks like the notification API for CI engines need write access to repositories code.
In my case, to secure our repositories, I would like the CI engine not having write access to repositories.
This configuration make the QA notification failing with invalid access.
In my configuration, I use the jenkins gitea plugin V1.4.3 with jenkins 2.356.
I wonder whether it is mandatory to make this API entry with write access mode ?
Sorry for not having anymore logs at the moment (I created dedicated groups for CI servers with write access since), I will try to reproduce the issue but I guess you know what I'm saying as it looks an expected feature.

Gitea Version

1.17.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

RHEL 8.6

How are you running Gitea?

from the binary provided on github official release

Database

MySQL

[wxiaoguang]

The behavior was changed by :

• Add write check for creating Commit status (#20332) #20333
• Add write check for creating Commit status #20332

Reported by:

• New commit status API doesn't check permissions properly #20331

[gd197]

Indeed, thanks for pointing me to the right change request, nevertheless, if i may, I would challenge the fact that write permission is required.
For security point of view, read access looks enough to me ?

[wxiaoguang]

From my point of view:

• Current approach also looks good to me. Requiring write permission is not wrong.
• To relax the permission:
  • For a private Gitea repository, the read permission (all team members) is safe to update the commit status.
  • For a public Gitea repository, only team members could update the commit status, but not the non-team users.

I didn't look into details for this problem. These issues and PRs are by @leytilera @Gusted @KN4CK3R @zeripath @6543 , how do you think.

[zeripath]

The previous mechanism allowed anyone to send commit statuses without any permissions check. I'm sure you can imagine the sort of problems that could cause.

Just create a token for the owner of the repo and pass it either as a header or as query param.

If we can get round to sorting out role permissions - I'd like to do this but don't have time at present - then we could make a nicer mechanism.

[gd197]

• To relax the permission:

  • For a private Gitea repository, the read permission (all team members) is safe to update the commit status.
  • For a public Gitea repository, only team members could update the commit status, but not the non-team users.

Indeed you got the point and I forgot to mention that our organizations are private by default and this is not the expected standard behavior. What do you think about :
whatever organization is private or public, API access is only allowed to team-users, whatever their role is ?
In that case, I would update the title of the issue

[leytilera]

From my point of view:

• Current approach also looks good to me. Requiring write permission is not wrong.

• To relax the permission:

  • For a private Gitea repository, the read permission (all team members) is safe to update the commit status.
  • For a public Gitea repository, only team members could update the commit status, but not the non-team users.

I didn't look into details for this problem. These issues and PRs are by @leytilera @Gusted @KN4CK3R @zeripath @6543 , how do you think.

I think the current approach is a good solution. Better would be to have a seperate permission for the commit statuses, but I don't know how big the changes are, that would be required to implement this.

[Gusted]

I don't think we should not relax permissions, it will be a weird exemption that people wouldn't expect if they didn't read the source code or this issue. It was already a big oversight that anyone without any permission were able to write commit statuses.

As @leytilera mentioned a new permission for this action should be fine (and do-able).

[gd197]

Ok Fully understand your point, the best solution is to have dedicated permission for such operation and fix the root cause.
Let me know whether your prefer to close that issue and create a new one or keep it.
Thanks for your feedback, highly appreciated.

[wxiaoguang]

According to the discussions above, I think this issue could be closed.