I was wondering if anyone had any tips regarding multiline environment variables.
Specifically, I’ve got a PEM formatted private key for accessing a Google service. I’m currently reading it in via an environment variable but I keep getting the error Error: error:0906D06C:PEM routines:PEM_read_bio:no start line. I’m fairly sure that’s because the newlines aren’t being preserved and the parser can’t find the start line.
Here’s a screenshot of the results of me pasting the environment variable in as a service variable:
Making all of this worse: this was working yesterday. In between one deploy and the next this stopped working. So if this issue sounds familiar or someone else has a workaround or any ideas, please let me know.
Last time it worked was yesterday, not sure about the time. Late afternoon for me (I’m in CDT).
I’m not sure I escaped them enough. I wrote \n (the first time I tried to get this to work) and was getting the same error. I haven’t tried it today. Maybe I should’ve written \\n? Any opinions before I go find-and-replacing when I get a chance?
Thanks for the info – just trying to discern whether it having stopped working might relate to our multi-container rollout. If it has worked the entire time before, and doesn’t now, this could be a bug, we’ll check.
I’m having the same problem; if I paste in multi-line strings then the newlines appear to be turned into spaces. Did you find a workaround / was this resolved?
In many of my Google integrations I configure the base64 part of the secret, and manage the new lines from within the code. Not a fix, but a workaround, and in my case also leaves the configuration values cleaner.
@drhayes@WillFG We’ve released an update to the dashboard that fixes this issue. Line breaks in environment variable values are now preserved correctly.
Hey @cnr can you give me an example file and what you expect to see on the printenv | grep MY_FILE side of things?
For most file type env vars I always transform them to base64 and then transform them back on the device side, that way I know they are always correct. But lets see if we can figure out what is going on for you.
Hey @cnr , I just looked a bit deeper into this and it looks like the “fix” for this was rolled back because it was affecting older OS devices that couldn’t interpret the newlines that fix introduced. So for now the currently recommended way to do files in env vars is to use base64 encoded env vars.
@shaunmulligan Thank you for looking into this! That would explain why it’s not working.
I can certainly base64 encode, but then the utility of the dashboard env var setting tool is a little bit decreased because I can no longer edit the variables in the dashboard, there is now a prior step.
For context:
We use a single env var with our entire config file in it. Originally this was intended as YAML, but now we are using json so we can still edit the cleartext values in the dashboard.
Is there any way you could distinguish between the compatible and incompatible devices when newlines are concerned? Maybe it could just auto-convert to base64, or auto-strip newlines in the older devices but leave the newer devices untouched?
No problem @cnr and thanks for the context. We have a plan to add “env files” to the UI, which would suit this use case and others where you would want to put say a CA cert or something a long those lines.
I will chat to our team and see if there is an easy way around this, but can’t guarantee we will get it fixed very quickly, so for now the current recommendation is to use the base64 method unfortunately.
@shaunmulligan how is the plan to support “env files” coming along? How I understand this, it would allow me to have a config file for my service which I can edit in the dashboard? Would love to see this feature.
There is no timeline currently to implement “env files” but we are aware how useful it would be (for us internally too!). This thread is attached to our internal discussions so we will make sure to let you all know when it does get released!
I wrote