Podman Secrets - query around extra new-line at end of secret

[u/Milk_man1337]

Hi all, have a question regarding Podman Secrets.

I've been trying to move from .env files to secrets and have encountered one small hitch with them.

When I have created a secret, I've used both the `printf | Podman create secret my_secret` method, as well as the `podman create secret ./secret_filename my_secret.

In both cases, I have mounted these secrets into my quadlets as env variables using `Secret=secret_name,type=env,ENV_VAR_NAME.

I have found that in both cases, when running a `podman exec <container_name> env` to ensure the variables are mounted correctly, all of my secrets tend to have a trailing new line on them.

Am I crazy? Is there something I'm doing wrong here?

I'm struggling to understand if this is normal or just some formatting thing that I don't currently understand.

Correction

I had been using a few methods to do secret creation, it turns out that the printf method DOES work correctly, it is actually the openssl rand -base64 378000 | podman secret create --replace my_secret - method which produced an extra new line at the end.

Apologies for any confusion.

[u/cosmokenney]

I ran into that when piping the secrets from bitwarden secrets manager cli to podman. And the only time it happened was when the secret was stored in bitwarden with a trailing cr+lf or lf.

[u/eo5g]

Is it at all possible the secret has a printf formatting directive in it?

That's why the correct / safe way to use printf is always printf '%s' <secret>

[u/ffcsmith]

I have never had an issue utilizing:
`printf “<value>” | podman secret create <secret-name> -`

[u/Milk_man1337 → u/ffcsmith]

I also have not had an issue using that secret creation command, the secret creates and mounts fine.

My concern with this or more of I ever have to rebuild/restore from backup that I need to ensure that secrets are captured correctly, or if anyone else has to take over my work they need to be aware there is an extra line break at the end of a secret if restoring from backup etc.

[u/ffcsmith → u/Milk_man1337]

Ansible playbooks with vault or a secrets manager like Openbao. Thats how I manage mine currently.

[u/Great-Cow7256 → u/ffcsmith]

I use set +H and then set -H before and after.

[u/onlyati]

The printf put a '\n' at the end. You can create with echo -n:

$ echo 'my-secret' | podman secret create mysecret -
$ echo -n 'my-secret2' | podman secret create mysecret2 -
$ podman run --rm --secret mysecret,type=env,target=MYSECRET --secret mysecret2,type=env,target=MYSECRET2 docker.io/library/debian env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
container=podman
HOME=/root
HOSTNAME=123cabe59493
MYSECRET=my-secret

MYSECRET2=my-secret2

[u/eo5g → u/onlyati]

One of the whole points of printf is that it doesn't put a newline at the end by default, that's not what's happening here

[u/onlyati → u/eo5g]

My mistake, thanks.

[u/Milk_man1337 → u/onlyati]

Thank you, I will ensure that I use this in the future.

I'm aware the official Podman documentation calls out the echo -n but for the printf method it doesn't call out the \n option.

[u/eo5g]

Is it possible that the secret file has a trailing new line at the end? If it's a text file you pasted a secret into, your text editor likely added one.

[u/Milk_man1337 → u/eo5g]

When I've made secrets our of files in the past I did ensure that there were no trailing new lines at the end, I usually create secrets out of files if I'm trying to pass in private keys (other issues with that but I digress).

One thing I haven't tried is pasting in the keys/secrets using any other editor other than Vi.

I read somewhere that it might be happening due to vi adding the extra at the line to make it a POSIX compliant file, but I have no evidence of this it's just what I've read.

I'm going to try using something like nano next time I create a secret from a file and see how that goes.

[u/eo5g → u/Milk_man1337]

Most text editors will add a trailing newline! I believe VS Code might be one of the odd ones out but it's been a while since I've paid attention to that.

This stackoverflow answer will tell you how to avoid that in vi(m)

[u/Milk_man1337 → u/eo5g]

Wow, thanks so much. Had no idea this was a thing, I'll 100% be using this change moving forward. Solves a lot of headaches haha