bug in newline support?

[mreinstein]

here's a snippet from my .env file:

RETHINKDB_CA_CERT="-----BEGIN CERTIFICATE-----\nMIIDaTCCAlGgAwIBAgIEWKtniTANBgkqhkiG9w0BAQ0FADA2MTQwMgYDVQQDDCtC\nb3.........4ldPbbw11tG\n0mqNZVlsxA9EbfYy7g==\n-----END CERTIFICATE-----"
RETHINKDB_HOST=aws-us-east-1-portal.6.dblayer.com

on my osx machine, I'm able to load RETHINKDB_CA_CERT as an ssl cert string. However when I deploy this same .env file and code to a linux server, the newlines don't seem to work, and I get a message about it being an invalid cert. It looks like the newlines are possibly being replaced with spaces. straight from the log tail:

07/21 10:49 AM  -----BEGIN CERTIFICATE----- MIIDaTCCAlGgAwIBAgIEWKtniTANBgkqhkiG9w0BAQ0FA......== -----END CERTIFICATE-----
07/21 10:49 AM  Creating a pool connected to aws-us-east-1-portal.6.dblayer.com:17195
07/21 10:49 AM  boswell.ai web-service running at http://localhost:3001 =====
07/21 10:49 AM  Error: unable to verify the first certificate
                    at TLSSocket.<anonymous> (_tls_wrap.js:1098:38)
                    at emitNone (events.js:105:13)
                    at TLSSocket.emit (events.js:207:7)
                    at TLSSocket._finishInit (_tls_wrap.js:628:8)
                    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:458:38)
07/21 10:49 AM  npm ERR! code ELIFECYCLE

any ideas?

[maxbeatty]

The way we expand new lines isn't fancy (src) and only has a single test (src). Going back through issues and git history, I'm not sure what the original intended use case was for expanding new lines. #215 has some cert-specific parsing logic that you might be able to use.

I would suggest referencing the path to the cert and reading it in yourself in its original format as outlined here.

[mreinstein]

I would suggest referencing the path to the cert and reading it in yourself in
its original format as outlined here.

Actually I read this already. I searched all of the open and closed issues to see if this was an existing problem before opening. The problem is I already have all of my app's secrets in one place. I'm trying to avoid having several config files that aren't checked into source control. Easier to maintain apps, etc. Especially on a team.

[lukewlms]

We solved it this way, with newlines and JSON.parse:

in .env:

MY_KEY='-----BEGIN CERTIFICATE-----\nabcde...'

in server.ts:

myKey = JSON.parse(`"${process.env.MY_KEY}"`), // convert '\n'

And absolutely we want all our config to be outside source control and in a single file, per 12 Factor App.

[mreinstein]

We solved it this way, with newlines and JSON.parse

Cool 👍 I solved it with a similar approach. I replaced all \n characters with _ in the .env file(s), and then do a global string replace at run time after dotenv runs at the top of the app entry point.

we want all our config to be outside source control and in a single file, per 12 Factor Auth.

A nit, but I think you mean 12 factor app? https://12factor.net

Another nit, I couldn't find anything in 12 app about mandating all config being in a single file. That just happens to be a really nice way to keep all the secrets together in one place.

[lukewlms]

Yeah, agreed on both counts, corrected typo. Single file is about parsimony, not strict 12 Factor requirement.

[mreinstein]

We solved it this way, with newlines and JSON.parse

thanks for sharing your solution. The JSON.parse method might be a bit more elegant as you don't need to substitute special characters. Will def-o check that out!

@maxbeatty in the interests of closing/resolving this issue, I'm fine with either of the aforementioned workarounds. Perhaps a PR to explain this semi-common usecase and it's solutions?

[maxbeatty]

I think this discussion is fine. GitHub issues rank pretty well for Google searches. Writing a more detailed blog post may be best (e.g. "Why and how we use multiple line variables with dotenv")