QA from CI engine notification through API need write access #9660

New Issue

GiteaMirror · 2025-11-02T08:45:47-06:00

GiteaMirror commented

2025-11-02 08:45:47 -06:00

Originally created by @gd197 on GitHub (Oct 6, 2022).

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

Originally created by @gd197 on GitHub (Oct 6, 2022). ### 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

GiteaMirror added the type/bug label 2025-11-02 08:45:47 -06:00

GiteaMirror closed this issue

2025-11-02 08:45:48 -06:00

GiteaMirror commented

2025-11-02 08:45:49 -06:00

@wxiaoguang commented on GitHub (Oct 6, 2022):

The behavior was changed by :

Reported by:

https://github.com/go-gitea/gitea/issues/20331

@wxiaoguang commented on GitHub (Oct 6, 2022): The behavior was changed by : * https://github.com/go-gitea/gitea/pull/20333 * https://github.com/go-gitea/gitea/pull/20332 Reported by: * https://github.com/go-gitea/gitea/issues/20331

GiteaMirror commented

2025-11-02 08:45:49 -06:00

@gd197 commented on GitHub (Oct 6, 2022):

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 ?

@gd197 commented on GitHub (Oct 6, 2022): 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 ?

GiteaMirror commented

2025-11-02 08:45:49 -06:00

@wxiaoguang commented on GitHub (Oct 7, 2022):

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.

@wxiaoguang commented on GitHub (Oct 7, 2022): 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.

GiteaMirror commented

2025-11-02 08:45:49 -06:00

@zeripath commented on GitHub (Oct 7, 2022):

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.

@zeripath commented on GitHub (Oct 7, 2022): 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.

GiteaMirror commented

2025-11-02 08:45:49 -06:00

@gd197 commented on GitHub (Oct 7, 2022):

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

@gd197 commented on GitHub (Oct 7, 2022): > * 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

GiteaMirror commented

2025-11-02 08:45:50 -06:00

@leytilera commented on GitHub (Oct 7, 2022):

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.

@leytilera commented on GitHub (Oct 7, 2022): > 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.

GiteaMirror commented

2025-11-02 08:45:50 -06:00

@Gusted commented on GitHub (Oct 9, 2022):

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

@Gusted commented on GitHub (Oct 9, 2022): 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).

GiteaMirror commented

2025-11-02 08:45:50 -06:00

@gd197 commented on GitHub (Oct 10, 2022):

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.

@gd197 commented on GitHub (Oct 10, 2022): 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.

GiteaMirror commented

2025-11-02 08:45:51 -06:00

@wxiaoguang commented on GitHub (May 12, 2023):

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

@wxiaoguang commented on GitHub (May 12, 2023): According to the discussions above, I think this issue could be closed.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9660