GPG signature / checksums for released artifacts should be provided.

[bahner]

Hepp!

I have no way of verifying that that the released artifacts, eg. ipfs-desktop-0.38.0-linux-amd64.deb is actually provided by you. At the very least the checksums should be provided and the list of checksums should be signed.

Preferably the artfacts should be properly signed when possible :-)

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We are triaging issues on weekly basis and aim to give initial feedback within a few business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.tech if you just need general support.

[lidel]

@bahner why you need checksums? what is the threat model you are protecting yourself against?

Right now, the release artifacts are built by GitHub CI and then attached to GitHub Release without a human intervention.
Checksums would be generated and hosted in the same place, making no difference to your security profile.

With this status quo, release tag is created by CI job, so dev can't sign it. Also, if you dont trust prebuilt binaries from github.com, you should checkout code, audit it, and build it yourself.

Of course nothing is set in stone: we are open to suggestions how this state could be improved, but we need to be sure there is an actual value added to end users, and we don't introduce maintenance costs without real world benefit.

[jonathancross]

Hi @lidel Yes, interesting point brought up in #2878

At the very least all commits should be signed with a key that is secure and not controlled by GitHub.
I see you are signing commits, which is great! But your key seems to have expired?

In other projects where security is important (eg Bitcoin), multiple devs will build from the source on their workstation without directly trusting GitHub. Reproducible builds ensure that everyone gets the same binary unless there is an issue, but devs individually attest to a particular checksum to reduce reliance on any particular machine.