[Feature Request] add checksum tag for releases api #7281

New Issue

GiteaMirror · 2025-11-02T07:21:37-06:00

GiteaMirror commented

2025-11-02 07:21:37 -06:00

Originally created by @LazyT on GitHub (May 1, 2021).

Hi,

I use the API to check for new versions and download them directly in my program.

At the moment it's unfortunately only possible to check the file size via "size:xxx". An additional crc tag like "md5:xxx" for each file would be safer to validate the download.

Could this be implemented please?

Thank you!

ref: https://codeberg.org/Codeberg/Community/issues/435

Originally created by @LazyT on GitHub (May 1, 2021). Hi, I use the [API](https://try.gitea.io/api/swagger#/repository/repoListReleases) to check for new versions and download them directly in my program. At the moment it's unfortunately only possible to check the file size via "size:xxx". An additional crc tag like "md5:xxx" for each file would be safer to validate the download. Could this be implemented please? Thank you! ref: https://codeberg.org/Codeberg/Community/issues/435

GiteaMirror added the type/enhancement type/proposal modifies/api labels 2025-11-02 07:21:37 -06:00

GiteaMirror commented

2025-11-02 07:21:38 -06:00

@6543 commented on GitHub (May 1, 2021):

@LazyT thanks for opening the issue.

the question is if md5 should be used because of collisions issues ...
Signature/Hash Choice for File Integrity Verification

archlinux use md5 & sha256; alpine sha512 ... for there package integrity checking

@6543 commented on GitHub (May 1, 2021): @LazyT thanks for opening the issue. the question is if md5 should be used because of collisions issues ... [Signature/Hash Choice for File Integrity Verification](https://stackoverflow.com/questions/13269606/signature-hash-choice-for-file-integrity-verification) archlinux use md5 & sha256; alpine sha512 ... for there package integrity checking

GiteaMirror commented

2025-11-02 07:21:38 -06:00

@LazyT commented on GitHub (May 2, 2021):

Add several tags "md5:xxx", "sha256:xxx", "sha512:xxx" so anybody can choose?

For me all hashes supported by Qt are fine. 😏

@LazyT commented on GitHub (May 2, 2021): Add several tags "md5:xxx", "sha256:xxx", "sha512:xxx" so anybody can choose? For me all hashes supported by [Qt](https://doc.qt.io/qt-5/qcryptographichash.html#Algorithm-enum) are fine. :smirk:

GiteaMirror commented

2025-11-02 07:21:38 -06:00

@naums commented on GitHub (May 11, 2021):

A checksum only helps if the download got corrupted, however it does not help if an evil attacker has replaced an asset. So while we're at it, the checksum should be encrypted using asynchronous crypto facing the user. And while we are at it, a feature could be added to the POST-Api, so a continuous integration server could securely post a release-asset.

Or maybe the thing you are trying to accomplish is to only check against download-errors, where I'm not sure if they could even occur, as either the TCP packages reach the application, then they are correct, or not, then they are not. Maybe I'm missing something.

@naums commented on GitHub (May 11, 2021): A checksum only helps if the download got corrupted, however it does not help if an evil attacker has replaced an asset. So while we're at it, the checksum should be encrypted using asynchronous crypto facing the user. And while we are at it, a feature could be added to the POST-Api, so a continuous integration server could securely post a release-asset. Or maybe the thing you are trying to accomplish is to only check against download-errors, where I'm not sure if they could even occur, as either the TCP packages reach the application, then they are correct, or not, then they are not. Maybe I'm missing something.

GiteaMirror commented

2025-11-02 07:21:39 -06:00

@LazyT commented on GitHub (May 12, 2021):

Or maybe the thing you are trying to accomplish is to only check against download-errors, where I'm not sure if they could even occur

Why do download sites provide an checksum for the files? Would you flash an bios without verifying the file after download? I'm not. 😉

For evil attackers the files should better use a signature.

@LazyT commented on GitHub (May 12, 2021): > Or maybe the thing you are trying to accomplish is to only check against download-errors, where I'm not sure if they could even occur Why do download sites provide an checksum for the files? Would you flash an bios without verifying the file after download? I'm not. :wink: For evil attackers the files should better use a signature.

GiteaMirror commented

2025-11-02 07:21:39 -06:00

@naums commented on GitHub (May 12, 2021):

TCP does that for you. The only thing why a file might get corrupted could be, that your PC crashed before the file is written from the OS out of the page cache to disk.

Nonetheless, unencrypted checksums together with the file is virtually useless against an attacker switching the file. Linux Distros use checksums always together with crypto to check against switched files (and in turn connection problems). I wouldn't flash a BIOS chip at all, especially when I can't be sure who put the file there.

When doing checksumming, placing the burden to your user, i.e. the programmer providing the binary, is a bit weird. A programmer wants to compile her code as always and the system(s) (CI, Gitea) should add crypto transparent to the programmer. Don't trust the user to do it right, that never works out.

tl;dr: Think about what you want to achieve, if it is a real problem and whether your solution suffices to solve the problem.

@naums commented on GitHub (May 12, 2021): TCP does that for you. The only thing why a file might get corrupted could be, that your PC crashed before the file is written from the OS out of the page cache to disk. Nonetheless, unencrypted checksums together with the file is virtually useless against an attacker switching the file. Linux Distros use checksums always together with crypto to check against switched files (and in turn connection problems). I wouldn't flash a BIOS chip at all, especially when I can't be sure who put the file there. When doing checksumming, placing the burden to your user, i.e. the programmer providing the binary, is a bit weird. A programmer wants to compile her code as always and the system(s) (CI, Gitea) should add crypto transparent to the programmer. Don't trust the user to do it right, that never works out. tl;dr: Think about what you want to achieve, if it is a real problem and whether your solution suffices to solve the problem.

GiteaMirror commented

2025-11-02 07:21:39 -06:00

@LazyT commented on GitHub (May 12, 2021):

Think about what you want to achieve

I think it's clear what I want to achieve: simply verify the update (automatically in my app, not by user) after the download is finished.

@LazyT commented on GitHub (May 12, 2021): > Think about what you want to achieve I think it's clear what I want to achieve: simply verify the update (automatically in my app, not by user) after the download is finished.

GiteaMirror commented

2025-11-02 07:21:39 -06:00

@naums commented on GitHub (May 12, 2021):

Verify against what? That the file is the same on your PC as is on the server - yes, your checksum works. Verify against someone with FTP-access replacing the file with malware - will not be secure without a sound idea about encryption.

My point is: a checksum is not really useful, you want a signature.

@naums commented on GitHub (May 12, 2021): Verify against what? That the file is the same on your PC as is on the server - yes, your checksum works. Verify against someone with FTP-access replacing the file with malware - will not be secure without a sound idea about encryption. My point is: a checksum is not really useful, you want a signature.

GiteaMirror commented

2025-11-02 07:21:40 -06:00

@LazyT commented on GitHub (May 12, 2021):

That the file is the same on your PC as is on the server - yes, your checksum works.

Great, that's what I want.

you want a signature.

No, as written above I would use a signature in my app to protect against evil hackers. That has nothing to do with the checksum to verify the download is corrupt...

@LazyT commented on GitHub (May 12, 2021): > That the file is the same on your PC as is on the server - yes, your checksum works. Great, that's what I want. > you want a signature. No, as written above I would use a signature in my app to protect against evil hackers. That has nothing to do with the checksum to verify the download is corrupt...

GiteaMirror commented

2025-11-02 07:21:40 -06:00

@noerw commented on GitHub (May 20, 2021):

The simple way would be to just upload a checksum file separately? This would also help when the upload to gitea was corrupted.
More convenient for API consumers would be to provide the checksum via an additional optional attribute on attachment uploads, which is validated by gitea after upload, and also provides the checksum for attachment retrieval

@naums If you want release signing, please open your own issue. Also:

TCP packet checksums are not enough
For a signature to be "secure" you also need to announce the signing key via a separate channel, this can't be achieved within Gitea alone. And the option to upload signatures as separate files is already available, so I see no need for a gitea feature.

@noerw commented on GitHub (May 20, 2021): The simple way would be to just upload a checksum file separately? This would also help when the *upload* to gitea was corrupted. More convenient for API consumers would be to provide the checksum via an additional optional attribute on attachment uploads, which is validated by gitea after upload, and also provides the checksum for attachment retrieval @naums If you want release signing, please open your own issue. Also: - [TCP packet checksums are not enough](https://www.evanjones.ca/tcp-checksums.html) - For a signature to be "secure" you also need to announce the signing key via a separate channel, this can't be achieved within Gitea alone. And the option to upload signatures as separate files is already available, so I see no need for a gitea feature.

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