Secret name generation only reads env vars #464
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/organising#464
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I was to change the secret names in the matrix recipe and stumbled across this:
This should not work. According this configuration every secret should have the same name in the end.
So I discovered that the secret names are note generated from
name: ${STACK_NAME}_db_password_${SECRET_DB_PASSWORD_VERSION}
which should be the way, but only from the secret version env. So changingSECRET_REGISTRATION_SHARED_SECRET_VERSION
toSECRET_REGISTRATION_VERSION
will change the generated secret name.This is very confusing and should be fixed.
Note: even the secret names differ, they contain all the same secret...
Wow, what a bug 🤯 Good you caught this... adding to critical board.
Secret name generation from version env variable.to Secret name generation only reads env varsI think
abra app secret ls
is also affected by this and would need to be tested when changes are made.I reopen this, because there is still an inconstancy that produces bugs.
I tried to deploy matrix version
5.0.0+v1.93.0
and this compose produces problems:When I run
abra app secret ls
the secrets are named as follows:matrix_example_com_registration_shared_secret_v1
matrix_example_com_macaroon_secret_key_v1
But when I try to deploy the apps I got the following error:
"service synapse: secret not found: matrix_example_com_macaroon_v1"
"service synapse: secret not found: matrix_example_com__registration_v1"
secretRemoteName := fmt.Sprintf("%s_%s_%s", app.StackName(), secretName, val.Version)
Why not generate the
secretRemoteName
from the composename
variable:name: ${STACK_NAME}_registration_${SECRET_REGISTRATION_VERSION}
?@moritz oof yeh, that looks like another edition of this bug alright 😬 Don't have time to tackle this right now but please if anyone feels free to resolve it, go ahead! There are some unit tests & integration tests which cover that code AFAIR.
Bug = we're now generating the secret names by the key (e.g.
registration_shared_secret
) and not thename: ${STACK_NAME}_registration_${SECRET_REGISTRATION_VERSION}
which is actually a horrific bug. Critical fix candidate 😬Working on this yesterday & today, getting closer to wrapping my head around it again...
I implemented a kind of centralised function
ReadSecretsConfig
in coop-cloud/abra#356 which I now realise is doing too much and covering two cases (1) you have the app 2) you don't have the app). So, I just need to break that into two functions (I think!). In case 1, we just need to read thename: ...
as we have the${STACK_NAME}
available. In 2) we still need to construct the proper name via thesanitisedAppName
passed in from the user. WIP...Will write docs about intended functionality so as to avoid getting lost again in the middle of an implementation...
Case 1)
Case 2)
Keep running into a brick wall on this one sadly, see coop-cloud/organising#535 (comment). Giving up for now.
coop-cloud/abra#391 landed, gonna take another swing at this today hopefully.
@p4u1 I've run into a potential issue with the implementation in coop-cloud/abra#391
In
I think this can lead to confusion and sorrow with recipe maintainers. E.g.
7b1b5c37ed
when originally the secret key was calledregistration_shared_secret
and the name wasname: ${STACK_NAME}_registration_${SECRET_REGISTRATION_VERSION}
.Is there a way we can not create a dependency between the secret key and name?
@decentral1se I added more comments to the code in coop-cloud/abra#392 to better explain, how the length modifier gets added to the secret. This should explain, why it should not be a potential problem.
Woe. I am still seeing this on latest abra
main
:and yet, on the server:
Where
backup-bot-two_foo_bar_com_restic_repo_v1
is the output fromabra app secret ls backup-bot-two.foo.bar.com
@3wordchant ouch. Just took another gander, can you confirm you're including
compose.secret.yml
? I assume latestbackup-bot-two
commit? Bitta churn in the repo, so maybe stuff got moved around in between the deployment altho unsure if this is a new depoy or not. Could you get us some--debug
output? Thanks. /cc @p4u1I can't reproduce it. Creating new backup-bot-two app from the latest commit, uncommenting
and inserting the secrets. Deploy with the latest commit of abra works for me.
Tearing down the deployment and redeploying worked, thanks for help @decentral1se @moritz, unsure exact cause of what I was seeing but pushing past it for now.