Sign helm releases #427

Merged
pat-s merged 13 commits from refs/pull/427/head into main 2023-05-13 10:11:15 +00:00
pat-s commented 2023-04-01 08:10:34 +00:00 (Migrated from gitea.com)

fix #31

First stab, need to iterate most likely.

@techknowlogick @lunny Could one of you add the GPG secrets here so the signing can be tested?

fix #31 First stab, need to iterate most likely. @techknowlogick @lunny Could one of you add the GPG secrets here so the signing can be tested?
lunny commented 2023-04-01 12:51:26 +00:00 (Migrated from gitea.com)

Done. Only push could read that secrets.

Done. Only push could read that secrets.
pat-s commented 2023-04-01 17:59:58 +00:00 (Migrated from gitea.com)

Thanks. I wonder if we can allow it for PRs for a short time and then remove it again? This way we can test whether the logic works instead of failing during the next release?

If think if you would add them with "allow in PRs", merge main (which triggers a new run), then we would see if it works in drone. If so, you could then remove the "allow in PRs" again? This would be a minimal exposure and if you do it, nobody could step in between.

Thanks. I wonder if we can allow it for PRs for a short time and then remove it again? This way we can test whether the logic works instead of failing during the next release? If think if you would add them with "allow in PRs", merge main (which triggers a new run), then we would see if it works in drone. If so, you could then remove the "allow in PRs" again? This would be a minimal exposure and if you do it, nobody could step in between.
lunny commented 2023-04-02 08:23:40 +00:00 (Migrated from gitea.com)

Thanks. I wonder if we can allow it for PRs for a short time and then remove it again? This way we can test whether the logic works instead of failing during the next release?

If think if you would add them with "allow in PRs", merge main (which triggers a new run), then we would see if it works in drone. If so, you could then remove the "allow in PRs" again? This would be a minimal exposure and if you do it, nobody could step in between.

Sorry, we cannot allow it for PR reading because there is a security problem. And since you have write permission, I think you can do that in a branch in this repository.

> Thanks. I wonder if we can allow it for PRs for a short time and then remove it again? This way we can test whether the logic works instead of failing during the next release? > > If think if you would add them with "allow in PRs", merge main (which triggers a new run), then we would see if it works in drone. If so, you could then remove the "allow in PRs" again? This would be a minimal exposure and if you do it, nobody could step in between. Sorry, we cannot allow it for PR reading because there is a security problem. And since you have write permission, I think you can do that in a branch in this repository.
pat-s commented 2023-04-02 08:42:10 +00:00 (Migrated from gitea.com)

Sorry, we cannot allow it for PR reading because there is a security problem.

I am not fully sure you understood my proposal :) I didn't ask to allow it in general for this repo but instead that you do it for a few mins while you update and rerun the action yourself and then revoke it again. This way, there is no exposure risk to anyone and I am not involved at all.

And since you have write permission, I think you can do that in a branch in this repository.

Ah true, I could change the trigger for executing that part of the CI and do so in a branch build and not within a PR. Good pointer, thanks!

> Sorry, we cannot allow it for PR reading because there is a security problem. I am not fully sure you understood my proposal :) I didn't ask to allow it in general for this repo but instead that you do it for a few mins while you update and rerun the action yourself and then revoke it again. This way, there is no exposure risk to anyone and I am not involved at all. > And since you have write permission, I think you can do that in a branch in this repository. Ah true, I could change the trigger for executing that part of the CI and do so in a branch build and not within a PR. Good pointer, thanks!
pat-s commented 2023-04-13 19:19:42 +00:00 (Migrated from gitea.com)

@lunny I keep getting the same non-successful results when importing

+ echo $GPGSIGN_PASSPHRASE > passphrase.txt && echo $GPGSIGN_KEY | gpg --batch --passphrase-file=passphrase.txt --import
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

Could you check whether the key is actually OK and importable? Maybe in an alpine docker container on your local machine?

@lunny I keep getting the same non-successful results when importing ``` + echo $GPGSIGN_PASSPHRASE > passphrase.txt && echo $GPGSIGN_KEY | gpg --batch --passphrase-file=passphrase.txt --import gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created gpg: no valid OpenPGP data found. gpg: Total number processed: 0 ``` Could you check whether the key is actually OK and importable? Maybe in an alpine docker container on your local machine?
lunny commented 2023-04-14 01:58:53 +00:00 (Migrated from gitea.com)

@lunny I keep getting the same non-successful results when importing

+ echo $GPGSIGN_PASSPHRASE > passphrase.txt && echo $GPGSIGN_KEY | gpg --batch --passphrase-file=passphrase.txt --import
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

Could you check whether the key is actually OK and importable? Maybe in an alpine docker container on your local machine?

It should be OK because I just finished the signing of act_runner https://gitea.com/gitea/act_runner/src/branch/main/.gitea/workflows/release-tag.yml . And since we are switching from drone -> Actions, maybe we can delay this PR?

> @lunny I keep getting the same non-successful results when importing > > ``` > + echo $GPGSIGN_PASSPHRASE > passphrase.txt && echo $GPGSIGN_KEY | gpg --batch --passphrase-file=passphrase.txt --import > gpg: directory '/root/.gnupg' created > gpg: keybox '/root/.gnupg/pubring.kbx' created > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 > ``` > > Could you check whether the key is actually OK and importable? Maybe in an alpine docker container on your local machine? It should be OK because I just finished the signing of act_runner https://gitea.com/gitea/act_runner/src/branch/main/.gitea/workflows/release-tag.yml . And since we are switching from drone -> Actions, maybe we can delay this PR?
pat-s commented 2023-04-14 06:19:40 +00:00 (Migrated from gitea.com)

And since we are switching from drone -> Actions, maybe we can delay this PR?

Ah sure, let's wait then or directly use the Gitea Action logic.

> And since we are switching from drone -> Actions, maybe we can delay this PR? Ah sure, let's wait then or directly use the Gitea Action logic.
pat-s commented 2023-05-02 14:43:10 +00:00 (Migrated from gitea.com)

@lunny Could you add the GPG key as Gitea Actions secrets?

@lunny Could you add the GPG key as Gitea Actions secrets?
pat-s commented 2023-05-05 08:34:03 +00:00 (Migrated from gitea.com)

I had to use the helm gpg plugin (and fork it first) as the official helm package --sign has issues with gpg and it's new keyring format: https://github.com/helm/helm/issues/2843

The current state worked fine and I hope we get a signed release during the next "real" release.

I had to use the helm gpg plugin (and fork it first) as the official `helm package --sign` has issues with gpg and it's new keyring format: https://github.com/helm/helm/issues/2843 The current state worked fine and I hope we get a signed release during the next "real" release.
justusbunsi (Migrated from gitea.com) reviewed 2023-05-05 08:35:59 +00:00
lunny (Migrated from gitea.com) reviewed 2023-05-05 08:36:06 +00:00
techknowlogick (Migrated from gitea.com) reviewed 2023-05-05 08:36:14 +00:00
lunny (Migrated from gitea.com) approved these changes 2023-05-05 08:40:47 +00:00
justusbunsi commented 2023-05-05 12:23:28 +00:00 (Migrated from gitea.com)

TBH, I am not sure if we should rely on a Helm plugin for a feature that is built-in to Helm. I saw the existing issue with gpg2 and the file format. But there seem to be a workaround for it by converting the key store into the legacy format https://helm.sh/docs/topics/provenance/#the-workflow. There is a hint about it.

But if it works, it works. I'd like to test it locally before I give my approval.

As an alternative to that, we could switch to OCI registry and use cosign in the future.

TBH, I am not sure if we should rely on a Helm plugin for a feature that is built-in to Helm. I saw the existing issue with gpg2 and the file format. But there seem to be a workaround for it by converting the key store into the legacy format https://helm.sh/docs/topics/provenance/#the-workflow. There is a hint about it. But if it works, it works. I'd like to test it locally before I give my approval. As an alternative to that, we could switch to OCI registry and use cosign in the future.
pat-s commented 2023-05-05 12:47:51 +00:00 (Migrated from gitea.com)

But if it works, it works. I'd like to test it locally before I give my approval.

I am with you there. I tested the workaround and it didn't work and resulted in another error I couldn't resolve. You can check the CI run history to spot the tries.

Happy to use the official way if you can get it working but I had to make a cut after more than one hour 🥴

As an alternative to that, we could switch to OCI registry and use cosign in the future.

This is new to me but sounds interesting!

> But if it works, it works. I'd like to test it locally before I give my approval. I am with you there. I tested the workaround and it didn't work and resulted in another error I couldn't resolve. You can check the CI run history to spot the tries. Happy to use the official way if you can get it working but I had to make a cut after more than one hour 🥴️ > As an alternative to that, we could switch to OCI registry and use cosign in the future. This is new to me but sounds interesting!
pat-s commented 2023-05-13 08:44:46 +00:00 (Migrated from gitea.com)

@justusbunsi Would you be ok to go with it for the time being? I am not so motivated to put much more time into this small issue given the issues and complexity on the helm side atm.

The current approach seems to work and we can always revisit once things have gotten better for the "official" command?

@justusbunsi Would you be ok to go with it for the time being? I am not so motivated to put much more time into this small issue given the issues and complexity on the helm side atm. The current approach seems to work and we can always revisit once things have gotten better for the "official" command?
justusbunsi commented 2023-05-13 09:26:36 +00:00 (Migrated from gitea.com)

Sure. Let's move on with this solution. Sorry for not responding earlier.

Sure. Let's move on with this solution. Sorry for not responding earlier.
Sign in to join this conversation.
No description provided.