delvh
commented
1 year ago On our end, to preserve the old git archive behavior, we needed to explicitly configure the git client used by Gitea like so: git config --global tar.tgz.command 'gzip -cn' git config --global tar.tar.gz.command 'gzip -cn'
Luckily, Gitea already supports a mechanism for changing git internal behavior.
Add the following to your app.ini:
[git.config]
tar.tgz.command = gzip -cn
tar.tar.gz.command = gzip -cnThe only problem is we cannot just set that as default as not everyone will have gzip installed. And if I have the choice between something being slightly broken and being completely broken, I prefer the slightly broken.
petergardfjall
chenrui333
lunny
Description
Not entirely sure if this is a bug, a feature request or just an attempt to raise awareness of a potential issue to the community (I didn't see this mentioned in any other issue).
In short, the issue is that newer releases of Gitea do not produce
tar.gzrepo archives that are checksum-stable with older Gitea releases (dating back tov1.17.2). For most clients this may not be an issue, but for us, who use Gitea as an important part of our supply-chain it has dire consequences.Details
It seems like somewhere between Gitea
v1.17.2andv1.19.3an upgrade of thegitcommand line tool in theDockerfilewas made to2.38(v1.19.3appears to use2.38.5). This brought with it a behavioral change in thegit archivecommand, which changed its default behavior from using thegzip(1)command to using an internal zlib library (see commit).Since the
GetArchiveAPI call directly usesgit archiveunder the hood, it means that thetar.gzrepository archives produced by Gitea are no longer checksum-stable. This may not have been an explicit promise of the Gitea API, but it is something that we relied upon.Notably this issue was also faced by GitHub, who first reacted by letting clients know that this was never officially guaranteed by the API. Given the community outrage that followed and GitHub's important position in supply chains and supply chain tooling, GitHub soon rolled back the change (some more of this discussion is covered in this discussion)
On our end, to preserve the old
git archivebehavior, we needed to explicitly configure thegitclient used by Gitea like so:Discussion
If one relies on Gitea to produce checksum-stable repo archives, newer versions of Gitea will not be consistent with older releases. Where do we go from here?
At a minimum, I think this needs to be documented, although I would prefer to see something more substantial.
If Gitea wants to be a strong player in a world increasingly concerned with supply chain attacks and the likes, it might be good to actually make promises regarding checksum stable archives. Adding a few tests would be an easy way to prevent unintended changes to produced archives. Changing the default back to the old behavior (of using
gzip(1)) like GitHub did could also be an option.Although a fix for this particular issue was outlined above, it does requires some "hackery" to get in place. One could perhaps consider exposing more of the
gitconfiguration through Gitea's own configuration "API"?Gitea Version
v1.19.3
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
Linux
How are you running Gitea?
Helm chart
Database
PostgreSQL