Secret auto-generation grep pattern doesn't match arbitrary naming #32

Closed
opened 2020-11-01 16:37:40 +00:00 by decentral1se · 7 comments
Owner

For foodsoft app, I ran the pattern when I didn't get anything auto-generated:

➜  foodsoft (master) ✔ cat .envrc.sample | grep "PASSWORD.*VERSION" 
# No results :(

But I have:

export DB_PASSWD_VERSION=v1
export DB_ROOT_PASSWD_VERSION=v1
export SHARED_LISTS_DB_PASSWD_VERSION=v1
export SMTP_PASSWD_VERSION=v1
export SECRET_KEY_BASE_VERSION=v1

Culture war over PASSWD/PASSWORD aside (😹) it seems like the SECRET_KEY_BASE_VERSION would always be left out. I think we need to exted this logic. Anything with a line ending of =v1? Maybe too brittle...

For foodsoft app, I ran the pattern when I didn't get anything auto-generated: ``` ➜ foodsoft (master) ✔ cat .envrc.sample | grep "PASSWORD.*VERSION" # No results :( ``` But I have: ``` export DB_PASSWD_VERSION=v1 export DB_ROOT_PASSWD_VERSION=v1 export SHARED_LISTS_DB_PASSWD_VERSION=v1 export SMTP_PASSWD_VERSION=v1 export SECRET_KEY_BASE_VERSION=v1 ``` Culture war over PASSWD/PASSWORD aside (😹) it seems like the `SECRET_KEY_BASE_VERSION` would always be left out. I think we need to exted this logic. Anything with a line ending of `=v1`? Maybe too brittle...
Author
Owner

Anything with a line ending of =v1? Maybe too brittle...

Oh darn, that would also include the configs too. Woops.

> Anything with a line ending of =v1? Maybe too brittle... Oh darn, that would also include the configs too. Woops.
Author
Owner
Time for https://mikefarah.gitbook.io/yq/?
Owner

it seems like the SECRET_KEY_BASE_VERSION would always be left out

Yep, also e.g. MEDIAWIKI_SECRET_KEY_VERSION.

My plan was to make sure all the env vars had SECRET in the name, then change the grep call to SECRET.*VERSION... but then we'd still be missing the instructions on how to generate each kind of password.

Possibly SECRET.*PASSWORD.*VERSION uses pwqgen and SECRET.*KEY.*VERSION uses pwgen -n 64 1?

Or we just default to pwgen.. for everything and lose semi-human-communicable passwords..

Also fine for a yml format to happen, still don't have momentum to solo that at present.

> it seems like the `SECRET_KEY_BASE_VERSION` would always be left out Yep, also e.g. `MEDIAWIKI_SECRET_KEY_VERSION`. My plan was to make sure all the env vars had `SECRET` in the name, then change the `grep` call to `SECRET.*VERSION`... but then we'd still be missing the instructions on how to generate each kind of password. Possibly `SECRET.*PASSWORD.*VERSION` uses `pwqgen` and `SECRET.*KEY.*VERSION` uses `pwgen -n 64 1`? Or we just default to `pwgen..` for everything and lose semi-human-communicable passwords.. Also fine for a `yml` format to happen, still don't have momentum to solo that at present.
Author
Owner

Also fine for a yml format to happen, still don’t have momentum to solo that at present.

Ah, I meant, parsing the compose*.yml files for the secret names instead of the .envrc.sample files? As a way to grab the exact position by parsing and then do a transformation there.

My plan was to make sure all the env vars had SECRET in the name, then change the grep call to SECRET.*VERSION... but then we’d still be missing the instructions on how to generate each kind of password.

Sounds good then actually! Just using some sort of naming convention like this. I actually need that SECRET_KEY_BASE thing to be 30 characters long, I think. I know also the Gitea secrets need to be a specific length. That seems hard to thread down to auto-generation... maybe with comments!? Haha....uhhhhh, =v1 # length: 30?

> Also fine for a yml format to happen, still don’t have momentum to solo that at present. Ah, I meant, parsing the `compose*.yml` files for the secret names instead of the `.envrc.sample` files? As a way to grab the exact position by parsing and then do a transformation there. > My plan was to make sure all the env vars had SECRET in the name, then change the grep call to SECRET.*VERSION... but then we’d still be missing the instructions on how to generate each kind of password. Sounds good then actually! Just using some sort of naming convention like this. I actually need that `SECRET_KEY_BASE` thing to be 30 characters long, I think. I know also the Gitea secrets need to be a specific length. That seems hard to thread down to auto-generation... maybe with comments!? Haha....uhhhhh, `=v1 # length: 30`?
Owner

Ah, I meant, parsing the compose*.yml files for the secret names instead of the .envrc.sample files?

Oh yeah that works -- guess same issue about length applies tho

I actually need that SECRET_KEY_BASE thing to be 30 characters long, I think. I know also the Gitea secrets need to be a specific length. That seems hard to thread down to auto-generation... maybe with comments!? Haha....uhhhhh, =v1 # length: 30?

Yeah this seems the good kind of evil, hopefully an easy migration to eventual yaml format, too.

> Ah, I meant, parsing the `compose*.yml` files for the secret names instead of the `.envrc.sample` files? Oh yeah that works -- guess same issue about length applies tho > I actually need that `SECRET_KEY_BASE` thing to be 30 characters long, I think. I know also the Gitea secrets need to be a specific length. That seems hard to thread down to auto-generation... maybe with comments!? Haha....uhhhhh, `=v1 # length: 30`? Yeah this seems the good kind of evil, hopefully an easy migration to eventual yaml format, too.
Author
Owner

...=v1 # length=30 + PASSWORD/KEY distinction in generation! 🙉

`...=v1 # length=30` + `PASSWORD/KEY` distinction in generation! 🙉
Author
Owner

Solved in #33.

Lots of bash hair pulling but I guess I am just learning.

Solved in https://git.autonomic.zone/coop-cloud/abra/pulls/33. Lots of bash hair pulling but I guess I am just learning.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
2 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/abra#32
No description provided.