Files for new release 2.64.1 are missing in release.jfrog.io
bb-Ricardo opened this issue · 6 comments
Describe the bug
A new version (2.64.1) of frog-cli was released on GitHub but the links to the release files under https://releases.jfrog.io/ui/repos/tree/General/jfrog-cli/v2-jf/2.64.1 return with 404.
Current behavior
Files are missing
Reproduction steps
try to download the files from the 2.64.1 release
Expected behavior
Files for release 2.64.1 be present
JFrog CLI version
2.64.1
Operating system type and version
any
JFrog Artifactory version
No response
JFrog Xray version
No response
Thank you for reporting this issue @bb-Ricardo.
The issue is now fixed and all the binaries are now available.
The issue was caused due to a human error, while working on upgrading JFrog CLI's build infrastructure. We apologize for the inconvinience caused by this.
Hi @eyalbe4,
thank you, I was able to download the binaries and it works now in my case.
Just a question: Is it planned to release checksum files or signatures as well, in order to be able to verify the binary is the actual release binary? Should I open another issue for that?
Happy to hear the issue is resolved @bb-Ricardo.
In relation to your question, which installer are you using for JFrog CLI? I'm not 100% sure about this, but I think debian and RPM already have a built in mechanism for integrity verification.
I know it sounds a bit crazy but we build our own repository and software installer for all sorts of standalone binaries which are used in our systems and pipelines and mostly are not part of any repository.
While adding new releases to our repository we check the integrity of the binaries to lower the risk of supply chain attacks.
Ideally it would look like this:
- vendor/maintainer compiles new version for different targets.
- all binaries are then checksummed and added to a checksum file
- a signature file for the checksum file will be created.
- all files including the cheksum and signature file are released.
This can be usually done via cosign or GPG. Public keys which are published can then be used to verify the signature and therefore the checksums.
Even if someone compromises the release.jfrog.io Artifactory instance and exchanges the binaries with malicious copies/versions, the integrity check would fail.
@bb-Ricardo
The checksums can be found in the Artifactory database and can be downloaded by running a HEAD request:
> curl -I https://releases.jfrog.io/artifactory/jfrog-cli/v2-jf/2.65.0/jfrog-cli-linux-386/jf
HTTP/1.1 200
Date: Sun, 01 Sep 2024 06:17:25 GMT
Content-Type: application/octet-stream
Content-Length: 32470343
Connection: keep-alive
X-JFrog-Version: Artifactory/7.92.1 79201900
X-Artifactory-Id: d3d9e0c8c07b619da604d69a87cd76252dff62ac
X-Artifactory-Node-Id: releases-artifactory-primary-2
Last-Modified: Thu, 29 Aug 2024 11:50:28 GMT
ETag: 426546d24c5922207fec42092942e561ecff19fb
X-Checksum-Sha1: 426546d24c5922207fec42092942e561ecff19fb
X-Checksum-Sha256: 3e36e2f95cb494dfbb8e589c668adb42f367e76b8111c25d1a46d4cbe8345747
X-Checksum-Md5: 7b8790802fdea54ae355ff9afca954c8
Accept-Ranges: bytes
X-Artifactory-Filename: jf
Content-Disposition: attachment; filename="jf"; filename*=UTF-8''jf
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Request-ID: 5656e55cef4bd70792286aaf8856f6bc
Please let us know if that helps.
Hi,
I'm aware of the possibility to request the checksum vie HEAD. But this does not guarantee that the binary has not been changed (including the checksum) between the original released one and a potential malicious one later on.
It seems that this topic needs a separate issue.