nephatrine
commented
1 week ago This is the Fedora documentation on the usage of the caret in the package version (https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_handling_non_sorting_versions_with_tilde_dot_and_caret) just to state that this is a real use case. There are packages on EPEL8 and EPEL9 that contain such characters as well.
I tested that the issue occurs using the standard DNF package manager on AlmaLinux 8 and AlmaLinux 9. Presumably actual RHEL and Rocky Linux would 8/9 would have the same issues as they're all using DNF.
As RHEL7 does not support the caret operator in the version to begin with, I did not test Centos 7 or anything else that old as its a moot point.
It looks like openSUSE has different versioning guidelines on post-versions so a caret theoretically wouldn't appear in packages intended for it, but I did test on an openSUSE system and Zypper has the same encoding behaviour as DNF and so it 404s trying to use a URL containing %255E instead of just %5E. It works fine if the
It might be that there's some other bizarre RPM-based package manager that both can have a caret appear in the package version and requires it to be url-encoded in the
KN4CK3R
wxiaoguang
Description
When uploading a file with a name like
hello-test-0.0.1^15.git7166d1f2-1.el9.x86_64.rpmto the RPM registry, I am able to see the file correctly in the Gitea packages UI and can manually download the RPM from there, but DNF cannot download it on an actual system. DNF does see that the package exists and tries to download it, but gets 404 errors:In my gitea logs, I can see those 404 attempts.
If I try to put one of those URLs into my web browser like
https://example.com/api/packages/testuser/rpm/almalinux/el9/package/hello-test/0.0.1%255E15.git7166d1f2-1.el9/x86_64/hello-test-0.0.1%255E15.git7166d1f2-1.el9.x86_64.rpm, I indeed get a messagepackage does not exist.If, however, I change those instances of field works and allows packages to be downloaded by the package manager and seems to match the behaviour of other RPM repositories.
%255Ein the URL to%5E, the URL does work so it seems the caret is being url encoded twice. Looking in therepodata/primary.xml.gzthat gitea produces, I see that thelocationfield it produces has the caret already encoded to%5E, but in major RPM repositories like EPEL (https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/repodata/) this is not the case and thelocationdoes not have carets already url encoded. In my own testing producing a version of the gitea repository files that does not have the caret pre-urlencoded in theI have reproduced the issue on the demo site here: https://demo.gitea.com/nephatrine/-/packages/rpm/hello-test/0.0.1%5E15.git7166d1f2-1.el9
Gitea Version
1.22.2
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
2.45.2
Operating System
Alpine 3.20
How are you running Gitea?
I build Gitea myself and run it from my own docker container.
Database
SQLite