search

buildpacks / pack

CLI for building apps using Cloud Native Buildpacks
https://buildpacks.io
Apache License 2.0
2.58k stars 288 forks source link

Sign released binaries using PGP #934

Open jromero opened 4 years ago

jromero commented 4 years ago

Deferred from #799

Description

I would like to have proof that the pack releases on my system are the ones released by the Buildpacks organization.

Proposed solution

When releasing pack releases, we should sign the artifacts, using PGP signing.

importhuman commented 3 years ago

Is there any preference for either minisign (mentioned in #799) or the OpenPGP standard? Haven't worked out how either would be used, but wanted to know before I started. Also, I couldn't confirm whether minisign uses GPG/PGP keys, in case it's relevant.

sambhav commented 3 years ago

Would it be better to use cosign? We already use it for signing lifecycle images. FWIW We can also use it with goreleaser now https://goreleaser.com/customization/sign/

(goreleaser also allows for gpg signing)

inglor commented 6 months ago

Any progress on this?

jjbustamante commented 6 months ago

Hi @inglor

No yet, I talked with @natalieparellano in the past because we did something similar for lifecycle and I think we can do it for pack too. I think I can work on this for pack 0.35 or 0.36

inglor commented 6 months ago

Cosign is regarding the releases already build images you publish. I'm talking about how does downstream systems certify the tag in the git repository is indeed a tag created by the developers of the project. By signing the git tag (similar to how you already do your commits) downstream systems can individually certify these tags were indeed done by the said developer who is part of the project's release individuals.

A simple GPG sign of the tag and a list of PGP public keys who has access/permission to publish releases in the <root> of the repository (usually named KEYS) is enough for now. That is some effort from developers but if this is shared by a trusted small circle is OK and to my view is less effort from cosigning.

edit: I had initially misunderstood the cosigning part, now corrected it.

natalieparellano commented 6 months ago

Just to be clear I think there are 3 separate things we will want to sign:

I think we will want to do all of these. Some are more effort than others, but they are all quite achievable and we should prioritize them. We should have parity across pack and the lifecycle.

inglor commented 6 months ago

@natalieparellano

Thanks for the summary. I think you are correct and I'm mostly interested in 1st item from the list.

I had risen #2138 before I closed it in favour of this when I misunderstood the cosigning procedure. Would you like me to reopen or track everything here as one item concerning signing?

natalieparellano commented 6 months ago

Would you like me to reopen or track everything here as one item concerning signing?

@jjbustamante WDYT? One issue per thing being signed might be easier to track IMO

jjbustamante commented 6 months ago

Yes, I agree on having issue per artifact to be signed. @inglor we can re-open #2138 I think