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.