GIT sha256 support #6427

New Issue

GiteaMirror · 2025-11-02T06:55:31-06:00

GiteaMirror commented

2025-11-02 06:55:31 -06:00

Originally created by @6543 on GitHub (Dec 2, 2020).

SHA256 support comes in git-2.29, test deployment on codeberg-test does not work. Steps to reproduce:

git init --object-format=sha256
touch test
git add test
git commit -m "test"
git remote add origin git@codeberg.org:reinerh/test.git
git push -u origin main

Error: fatal: Protokollfehler: unerwartetes capabilities^{}

gitea version: 1.14.0+dev-294-g594cc4aa2

Originally created by @6543 on GitHub (Dec 2, 2020). SHA256 support comes in git-2.29, test deployment on codeberg-test does not work. Steps to reproduce: ```sh git init --object-format=sha256 touch test git add test git commit -m "test" git remote add origin git@codeberg.org:reinerh/test.git git push -u origin main ``` Error: `fatal: Protokollfehler: unerwartetes capabilities^{}` gitea version: 1.14.0+dev-294-g594cc4aa2

GiteaMirror added the type/feature type/proposal proposal/accepted labels 2025-11-02 06:55:31 -06:00

GiteaMirror closed this issue

2025-11-02 06:55:32 -06:00

GiteaMirror commented

2025-11-02 06:55:32 -06:00

@a1012112796 commented on GitHub (Dec 3, 2020):

Not suggest add it now because it still an experimental feature in git.
The error message is because git sha256 need core > repositoryformatversion=1 and extensions > objectformat = sha256.

@a1012112796 commented on GitHub (Dec 3, 2020): Not suggest add it now because it still an experimental feature in git. The error message is because git sha256 need ``core > repositoryformatversion=1`` and ``extensions > objectformat = sha256``.

GiteaMirror commented

2025-11-02 06:55:32 -06:00

@Gusted commented on GitHub (Mar 25, 2022):

How do we propose to set the SHA-256 setting for a repo? I assume we don't want to set this global(as this would only make sense for "new" gitea instance). Would it be a simple option on the repo creation to enable the SHA256 format?

@Gusted commented on GitHub (Mar 25, 2022): How do we propose to set the SHA-256 setting for a repo? I assume we don't want to set this global(as this would only make sense for "new" gitea instance). Would it be a simple option on the repo creation to enable the SHA256 format?

GiteaMirror commented

2025-11-02 06:55:33 -06:00

@lunny commented on GitHub (Mar 26, 2022):

If the repository is initialized in Gitea, we can have option in creating repository page, but if it's a repository pushing to create, we should have another method to detect it.

@lunny commented on GitHub (Mar 26, 2022): If the repository is initialized in Gitea, we can have option in creating repository page, but if it's a repository pushing to create, we should have another method to detect it.

GiteaMirror commented

2025-11-02 06:55:33 -06:00

@deknos commented on GitHub (Dec 17, 2022):

Hello,
NIST wanna sunset SHA1: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm

Yes, this will take some time and it is until 2030. Still, people should start it, as there are still no migration possibilities like i don't know, git make-readonly ; git migrate start --to=SHA2-256 ; git migrate clean --away=SHA1 or whatever. Also, this is also only for local git, there's no possibility for this for fetching/pulling already cloned gits.

Also, there may be more hashing algorithms in the future, or some are broken, just migrating to one will perhaps be enough for 10 years, but then we may have this issue again. Please for now, at least test and provide sha256 as an option.

migrating data will take time.

@deknos commented on GitHub (Dec 17, 2022): Hello, NIST wanna sunset SHA1: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm Yes, this will take some time and it is until 2030. Still, people should start it, as there are still no migration possibilities like i don't know, git make-readonly ; git migrate start --to=SHA2-256 ; git migrate clean --away=SHA1 or whatever. Also, this is also only for local git, there's no possibility for this for fetching/pulling already cloned gits. Also, there may be more hashing algorithms in the future, or some are broken, just migrating to one will perhaps be enough for 10 years, but then we may have this issue again. Please for now, at least test and provide sha256 as an option. migrating data will take time.

GiteaMirror commented

2025-11-02 06:55:33 -06:00

@Sword-Smith commented on GitHub (Feb 10, 2023):

Hello, NIST wanna sunset SHA1: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm

Yes, this will take some time and it is until 2030. Still, people should start it, as there are still no migration possibilities like i don't know, git make-readonly ; git migrate start --to=SHA2-256 ; git migrate clean --away=SHA1 or whatever. Also, this is also only for local git, there's no possibility for this for fetching/pulling already cloned gits.

Also, there may be more hashing algorithms in the future, or some are broken, just migrating to one will perhaps be enough for 10 years, but then we may have this issue again. Please for now, at least test and provide sha256 as an option.

migrating data will take time.

I second this. Also even if SHA-1 wasn't broken, it would still only be secure up to 80 bits, which shouldn't be considered safe nowadays. You should aim for 100 bits or preferably 128 bits which SHA-256 will give you.

Not as critical as I thought since the SHA-1 function is being used in a way that guarantees that the length is not affected, so the known SHA-1 attacks would not work. Also: A collision is not that dangerous, you need a second-preimage attack which AFAIK still has 160 bits security the way that SHA-1 is currently being used in git.

@Sword-Smith commented on GitHub (Feb 10, 2023): > Hello, NIST wanna sunset SHA1: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm > > Yes, this will take some time and it is until 2030. Still, people should start it, as there are still no migration possibilities like i don't know, git make-readonly ; git migrate start --to=SHA2-256 ; git migrate clean --away=SHA1 or whatever. Also, this is also only for local git, there's no possibility for this for fetching/pulling already cloned gits. > > Also, there may be more hashing algorithms in the future, or some are broken, just migrating to one will perhaps be enough for 10 years, but then we may have this issue again. Please for now, at least test and provide sha256 as an option. > > migrating data will take time. I second this. ~~Also even if SHA-1 wasn't broken, it would still only be secure up to 80 bits, which shouldn't be considered safe nowadays. You should aim for 100 bits or preferably 128 bits which SHA-256 will give you.~~ Not as critical as I thought since the SHA-1 function is being used in a way that guarantees that the length is not affected, so the known SHA-1 attacks would not work. Also: A collision is not that dangerous, you need a second-preimage attack which AFAIK still has 160 bits security the way that SHA-1 is currently being used in git.

GiteaMirror commented

2025-11-02 06:55:33 -06:00

@ptman commented on GitHub (May 16, 2023):

https://medium.com/@v3ai/how-to-use-sha-2-git-repositories-6c2a6ed5d580 - mentions how few git tools support sha256

@ptman commented on GitHub (May 16, 2023): https://medium.com/@v3ai/how-to-use-sha-2-git-repositories-6c2a6ed5d580 - mentions how few git tools support sha256

GiteaMirror commented

2025-11-02 06:55:34 -06:00

@applemayexist commented on GitHub (Sep 9, 2023):

What's the status of this? Git's documentation in 2.42.0 no longer calls the use of sha256 experimental, and states that no backward-incompatible changes are expected.

@applemayexist commented on GitHub (Sep 9, 2023): What's the status of this? [Git's documentation in 2.42.0](https://git-scm.com/docs/git-init#Documentation/git-init.txt---object-formatltformatgt) no longer calls the use of sha256 experimental, and states that no backward-incompatible changes are expected.

GiteaMirror commented

2025-11-02 06:55:34 -06:00

@lunny commented on GitHub (Sep 9, 2023):

Follow #23894

@lunny commented on GitHub (Sep 9, 2023): Follow #23894

GiteaMirror commented

2025-11-02 06:55:34 -06:00

@github-actions[bot] commented on GitHub (Mar 1, 2024):

Automatically locked because of our CONTRIBUTING guidelines

@github-actions[bot] commented on GitHub (Mar 1, 2024): Automatically locked because of our [CONTRIBUTING guidelines](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md#issue-locking)

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#6427