0

I am writing a bash script on a machine without expect. The script automates the build of a helm (v2.9.1) chart.

I've got to the part in the script where it runs a

helm package --sign --key 'mykey' --keyring 'path/to/keyring' -d chartdir chart

and because helm prompts for the passphrase of the gpg key I created in order to use provenance files (a requirement), I cannot script around the soliciting of the passphrase, which I would like to prompt for separately as the script is part of a CI/CD build chain.

I have tried using

yes $promptedPassPhrase | helm package --sign...

and I got

xrealloc: cannot allocate 18446744071562067968 bytes (237568 bytes allocated)

I also tried plain old

echo $promptedPassPhrase | helm package --sign...

and I got

Error: inappropriate ioctl for device

I also tried script and got the same response. As I do not have expect on the server, I cannot expect my way round it, so I'm stumped as to how to automate the helm package command and am not going to use a key without a passphrase as it is bad practice.

Community
  • 1
  • 1
volvox
  • 3,014
  • 16
  • 51
  • 80
  • `yes "$passphrase"` in a script is *even worse* practice. `yes` is an external command -- not part of the shell -- so it gets its own entry in the process table... meaning you're putting your passphrase in `ps` for everyone (all users on the system, including untrusted accounts like `nobody`) to see. – Charles Duffy Aug 23 '18 at 14:53
  • ...backing away from that implementation detail, though -- you can always implement your own `pinentry` tool and configure GPG to invoke it when a passphrase or PIN is needed. Set `use-agent` in `~/.gnupg/gpg.conf`, set `pinentry-program` to your program that retrieves the password from wherever it's stored (hopefully securely!) in `~/.gnupg/gpg-agent.conf`, and there you are. – Charles Duffy Aug 23 '18 at 14:55
  • @CharlesDuffy agreed on the use of Yes. Even trying it was like eating a dirty burger. – volvox Aug 23 '18 at 15:18
  • (BTW, if this is used in any kind of situation that actually matters, I'd tend to suggest having your private key stored in dedicated hardware -- gpg-agent can be used to communicate with a PKCS#11 smartcard, a YubiKey, etc; that way an attacker can't copy the private keying material off-host even if they do manage to 0wn the box. There are of course all the usual tricks to try to make a process harder to trace, but they're inadequate against a sufficiently competent attacker -- and these days, "sufficiently competent" can just mean running a [sysdig](https://sysdig.com/opensource/) trace). – Charles Duffy Aug 23 '18 at 15:25

1 Answers1

0

I don't know how long this has been the case, or exactly which versions this works on, but this doc page says:

If your PGP private key has a passphrase, [...] You can set the HELM_KEY_PASSPHRASE environment variable to that passphrase in case you don't want to be prompted to enter the passphrase.

This works for me on v2.13.1. It looks like it was added in October of 2018, so my guess is that it was first available in v2.12.0-rc.1.

Although this doesn't directly answer the OP's question (since they asked about v2.9.1), it will hopefully help anyone who ends up here because they (like me the first time round) missed that line in the doc.

Tsubashi
  • 730
  • 11
  • 26
  • It doesn't work for me in helm 3.1, – vgdub Jan 20 '23 at 05:40
  • Indeed. Looks like they removed that functionality in Helm 3. They did add a workaround in 3.4, though. See [here](https://github.com/helm/helm/pull/8394) for the pull request. There is also an [issue thread](https://github.com/helm/helm/issues/8455) on using stdin as a workaround for versions between 3.0 and 3.4 – Tsubashi Mar 08 '23 at 16:23