Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

providing of checksum files and signatures for released jf binaries #2687

Open
bb-Ricardo opened this issue Sep 5, 2024 · 1 comment
Open
Labels
feature request New feature or request

Comments

@bb-Ricardo
Copy link

Is your feature request related to a problem? Please describe.
Currently all jf binaries released at this location https://releases.jfrog.io/artifactory/jfrog-cli/v2-jf/ can not be verified as a checksum and signature it missing.

In order to mitigate supply chain attacks it is necessary to verify if a downloaded binary matches the checksum of the binary at build time.
This way a bad actor would not be able to change the binary without access to the private key which is used for the signature.

In an event of a compromised instance of releases.jfrog.io it would be possible to upload a malicious binary without any chance to verify the integrity of this binary.

Describe the solution you'd like to see

  • directly after the binary (for each platform and arch) has been build the checksum of this binary will be created.
  • all checksums for each binaries will be signed (cosign, GPG, openssl, ...)
  • binaries, checksums and signature will be published
  • Using a pre-published public key the signature can be verified and therefore the checksum of the downloaded binary

Describe alternatives you've considered
None, as the creation of checksums and signing need to be done at build time

@bb-Ricardo bb-Ricardo added the feature request New feature or request label Sep 5, 2024
@jcmcken
Copy link

jcmcken commented Oct 18, 2024

I'd also like to point out that the package distributions of the jfrog CLI (at least the RPMs, I didn't check the others) are signed with a GPG key with a very insecure signature (DSA1024/ELG2048). This was the default in 2009 from my brief research. The key reports it was created or signed in 2013.

All-in-all, this seems like a very suspect situation. At the very least the checksums for all of this stuff should be published in an independent location like in the GitHub release (which is very common). You can retrieve the SHA256 by appending .sha256 to the file downloaded from Artifactory, but it's not clear if this improves security in any way since it's stored in the same location as the file itself and (presumably) just auto-generated based on whatever bits are uploaded into that location.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants