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

Adding PGP signing to the release process #5320

Merged
merged 1 commit into from Feb 19, 2019

Conversation

Projects
None yet
5 participants
@mattfarina
Copy link
Collaborator

commented Feb 15, 2019

If applicable:

  • this PR contains documentation
  • this PR contains unit tests
  • this PR has been tested for backwards compatibility
Adding PGP signing to the release process
Signed-off-by: Matt Farina <matt@mattfarina.com>
@bacongobbler
Copy link
Member

left a comment

looks good to me! One comment about CHECKSUM_VAL, otherwise this seems like a good process to follow for the time being.

I wish we could sign the release assets during the CI process, but I understand storing private keys in Circle may be a security risk. Do you think it's worth generating a "Helm CI" shared PGP key that signs release assets right in the CI pipeline, or would that be an anti-pattern for signing releases?

- [Linux i386](https://storage.googleapis.com/kubernetes-helm/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://storage.googleapis.com/kubernetes-helm/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL)
- [Linux ppc64le](https://storage.googleapis.com/kubernetes-helm/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://storage.googleapis.com/kubernetes-helm/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256) / CHECKSUM_VAL)
- [Linux s390x](https://storage.googleapis.com/kubernetes-helm/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://storage.googleapis.com/kubernetes-helm/helm-vX.Y.Z-linux-s390x.tar.gz.sha256) / CHECKSUM_VAL)
- [Windows amd64](https://storage.googleapis.com/kubernetes-helm/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://storage.googleapis.com/kubernetes-helm/helm-vX.Y.Z-windows-amd64.zip.sha256) / CHECKSUM_VAL)

This comment has been minimized.

Copy link
@bacongobbler

bacongobbler Feb 15, 2019

Member

Would you mind explaining what CHECKSUM_VAL is intended to be?

This comment has been minimized.

Copy link
@mattfarina

mattfarina Feb 15, 2019

Author Collaborator

That is where we insert the actual checksum for each of these. In addition to the linked file it's displayed here. The reason for this is that we currently have the checksum on the same host/domain as the files. If someone can compromise the file they can compromise the checksum, too. This provides storing the checksum in a second location.

Our plan for notary in v3 will make this a temporary thing for v2, I think.

@mattfarina

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 15, 2019

@bacongobbler When it comes to signing keys open source projects usually have the people control them. Companies will tend to have signing processes that are tightly controlled so they can highly control their keys. I don't think we should put our signing keys into another companies CI.

The apache foundation has written up a bunch on signing releases for anyone who wants to read about it over at https://www.apache.org/dev/release-signing

@bacongobbler bacongobbler added this to the 2.13.0 milestone Feb 19, 2019

@mattfarina mattfarina merged commit 1f761ef into helm:master Feb 19, 2019

3 checks passed

DCO DCO
Details
ci/circleci: build Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@mattfarina mattfarina deleted the mattfarina:release-process-pgp-sign branch Feb 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.