Codeberg/Community

Fork 12

CORS for packages #2144

New issue

Open

opened 2025-09-22 10:32:34 +02:00 by chrysn · 2 comments

chrysn commented

2025-09-22 10:32:34 +02:00

Comment

When packages are hosted in public Codeberg organizations, they are generally accessible, but not from web browsers (which'd require CORS).

Practical use cases for this are all situations when JupyterLite notebooks install packages from a repository: In those cases, Python (or Ruby or R) are running inside a browser's WASM engine. For example, aiocoap uses this in its documentation to enable users to explore the library without any installation. As a workaround, I'm manually mirroring its packages to an own server with fuller CORS control.

Please consider activating CORS at least for the generated indices and the packages themselves. As I understand discussion on Forgejo enabling this, it already has the right knobs (although I'm not sure if their granularity suffices).

Security implications

As I understand, the basic CORS setting (Access-Control-Allow-Origin: *) will only allow browsers to send requests that don't send access control headers, so no special considerations are needed for private package repos (if that's even a thing on Codeberg). This would be a problem if Codeberg operated under the assumption that certain IP addresses are privileged to see some information, but Codeberg being a public service, I don't think that's the case.

Crawling implications

Only hypothetical implications: If Codeberg does block certain IP ranges from accessing packages (as AIU it is done during the current bursts bot activity), the crawlers could commandeer people's browsers and make them download on their behalf, turning crawling into a distributed thing. However, that'd require the bot operators to lure users onto their own pages – and those own pages then still do show up in "Origin:" headers sent by the browser, so they could be blocked that way.

### Comment When packages are hosted in public Codeberg organizations, they are generally accessible, but not from web browsers (which'd require CORS). Practical use cases for this are all situations when [JupyterLite notebooks](https://jupyter.org/try) install packages from a repository: In those cases, Python (or Ruby or R) are running inside a browser's WASM engine. For example, aiocoap uses this [in its documentation](https://aiocoap.readthedocs.io/en/latest/pyodide.html) to enable users to explore the library without any installation. As a workaround, I'm manually mirroring [its packages](https://codeberg.org/aiocoap/-/packages) to an own server with fuller CORS control. Please consider activating CORS at least for the generated indices and the packages themselves. As I understand [discussion on Forgejo enabling this](https://codeberg.org/forgejo/forgejo/issues/9361#issuecomment-7272049), it already has the right knobs (although I'm not sure if their granularity suffices). ## Security implications As I understand, the basic CORS setting (`Access-Control-Allow-Origin: *`) will only allow browsers to send requests that *don't* send access control headers, so no special considerations are needed for private package repos (if that's even a thing on Codeberg). This *would* be a problem if Codeberg operated under the assumption that certain IP addresses are privileged to see some information, but Codeberg being a public service, I don't think that's the case. ## Crawling implications Only hypothetical implications: If Codeberg does block certain IP ranges from accessing packages (as AIU it is done during the current bursts bot activity), the crawlers could commandeer people's browsers and make *them* download on their behalf, turning crawling into a distributed thing. However, that'd require the bot operators to lure users onto their own pages – and those own pages then still do show up in "Origin:" headers sent by the browser, so they could be blocked that way.

chrysn referenced this issue from forgejo/forgejo

2025-09-22 10:35:17 +02:00

feat: Enable CORS for packages #9361

Gusted commented

2025-09-22 16:35:21 +02:00

Owner

@chrysn wrote in #2144 (comment):

Please consider activating CORS at least for the generated indices and the packages themselves. As I understand discussion on Forgejo enabling this, it already has the right knobs (although I'm not sure if their granularity suffices).

No, there is no feature in Forgejo that would enable CORS for the package routes. CORS is otherwise already enabled:

	`[cors]`
	`ENABLED = true`
	`ALLOW_DOMAIN = *`

The comment refers to adding it to Codeberg's reverse proxy setup to add this CORS, which is not something we would like to do. It should be implemented in Forgejo, adding CORS support for some route in a reverse proxy is not that trivial.

@chrysn wrote in #2144 (comment):

Only hypothetical implications: If Codeberg does block certain IP ranges from accessing packages (as AIU it is done during the current bursts bot activity), the crawlers could commandeer people's browsers and make them download on their behalf, turning crawling into a distributed thing. However, that'd require the bot operators to lure users onto their own pages – and those own pages then still do show up in "Origin:" headers sent by the browser, so they could be blocked that way.

We already have CORS enabled for the general API, so that shouldn't be too much of a new implication.

@chrysn wrote in https://codeberg.org/Codeberg/Community/issues/2144#issue-2413360: > Please consider activating CORS at least for the generated indices and the packages themselves. As I understand [discussion on Forgejo enabling this](https://codeberg.org/forgejo/forgejo/issues/9361#issuecomment-7272049), it already has the right knobs (although I'm not sure if their granularity suffices). No, there is no feature in Forgejo that would enable CORS for the package routes. CORS is otherwise already enabled: https://codeberg.org/Codeberg-Infrastructure/build-deploy-forgejo/src/commit/747d8b7c22db487a001e42642ba31c02a74747fb/etc/forgejo/conf/base.ini#L186-L188 The comment refers to adding it to Codeberg's reverse proxy setup to add this CORS, which is not something we would like to do. It should be implemented in Forgejo, adding CORS support for some route in a reverse proxy is not that trivial. @chrysn wrote in https://codeberg.org/Codeberg/Community/issues/2144#issue-2413360: > Only hypothetical implications: If Codeberg does block certain IP ranges from accessing packages (as AIU it is done during the current bursts bot activity), the crawlers could commandeer people's browsers and make _them_ download on their behalf, turning crawling into a distributed thing. However, that'd require the bot operators to lure users onto their own pages – and those own pages then still do show up in "Origin:" headers sent by the browser, so they could be blocked that way. We already have CORS enabled for the general API, so that shouldn't be too much of a new implication.

chrysn referenced this issue from forgejo/forgejo

2025-09-22 16:53:21 +02:00

feat: Enable CORS for packages #9361

chrysn commented

2025-09-22 16:56:03 +02:00

Author

Thanks. I'll see with that what I can do in the Forgejo issue; I'd welcome you to join me there to avoid the Telephone Game if you can spare the mindshare for it (but hope to get it moving from the feedback you already provided).

Thanks. I'll see with that what I can do in [the Forgejo issue](https://codeberg.org/forgejo/forgejo/issues/9361); I'd welcome you to join me there to avoid the Telephone Game if you can spare the mindshare for it (but hope to get it moving from the feedback you already provided).

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Community#2144

No description provided.

Rows
Columns