| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 907363: Add zuul-tenant-conf-check role/job https://review.opendev.org/c/zuul/zuul-jobs/+/907363 | 00:13 | |
| @morucci:matrix.org | Hi there, do we have a tool that can decrypt a Zuul secret assuming we have access to zookeeper and the zuul.conf ? | 08:08 |
|---|---|---|
| @tristanc_:matrix.org | fbo: using `zuul export-keys` and https://opendev.org/zuul/zuul/src/branch/master/tools/decrypt_secret.py should work | 12:08 |
| @tristanc_:matrix.org | * fbo: using `zuul-admin export-keys` and https://opendev.org/zuul/zuul/src/branch/master/tools/decrypt\_secret.py should work | 12:09 |
| @morucci:matrix.org | tristanC: From my understanding, I don't think those commands are compatible regarding the data format. export-keys outputs all privates keys into a json file (zookeeper dump). All private keys are still encrypted via the keystore password. However decrypt_secret.py expects a fs path to the clear private key of the project hosting the secret.yaml. | 12:43 |
| @tristanc_:matrix.org | Indeed, the password is checked but not used by the export-keys command. Perhaps https://opendev.org/opendev/system-config/src/branch/master/doc/source/zuul.rst#secrets needs to be updated too? | 13:37 |
| @fungicide:matrix.org | fbo: tristanC: maybe https://docs.opendev.org/opendev/system-config/latest/zuul.html#secrets is closer? | 14:34 |
| @fungicide:matrix.org | oh, nevermind, that's what you found, just the published html version | 14:35 |
| @fungicide:matrix.org | but it does cover using jq to extract the key material from the export | 14:36 |
| @tristanc_:matrix.org | fungi: it seems like this no longer works since the key materials are encrypted with the master Zuul password, and the exported copies are not decrypted. | 15:06 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 907363: Add zuul-tenant-conf-check role/job https://review.opendev.org/c/zuul/zuul-jobs/+/907363 | 15:40 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 906320: WIP Finish circular dependency refactor https://review.opendev.org/c/zuul/zuul/+/906320 | 16:07 | |
| @fungicide:matrix.org | > <@tristanc_:matrix.org> fungi: it seems like this no longer works since the key materials are encrypted with the master Zuul password, and the exported copies are not decrypted. | 16:43 |
| aha, thanks. yes sounds like it would need to include an extra step of decrypting the export first | ||
| @morucci:matrix.org | fungi: tristanC could it be valuable to update tools/decrypt_secret.py or even add a zuul-admin command for that purpose (handling the whole process of: extracting the encrypted private key from zk, then decrypt the private key, then decrypt the secrets from a given file) ? | 17:31 |
| @jim:acmegating.com | i don't think there should be an easy/supported way to do that, so i don't think it's appropriate for zuul-admin. updating tools/decrypt_secret would be okay i think. the encrypted content of repository data belongs to the users, not the zuul admins. | 17:39 |
| @raaar:matrix.org | > <@jim:acmegating.com> there are a mixture of threads and processes in the executor; most merge operations happen in their own process | 18:05 |
| If I'm reading the code correctly, the process_worker argument is not passed inside the _mergeChange method (which performs the actual merge): https://opendev.org/zuul/zuul/src/branch/master/zuul/merger/merger.py#L1233 | ||
| So, when the [worspace_merger.mergeChanges](https://opendev.org/zuul/zuul/src/branch/master/zuul/executor/server.py#L1700) is invoked from inside an AnsibleJob instance -- it ends up being executed by the same thread started by the j[ob worker thread running inside the executor process.](https://opendev.org/zuul/zuul/src/branch/master/zuul/executor/server.py#L1095-L1099) | ||
| @jim:acmegating.com | raaar: i do agree that thread contention is not something that could be excluded as a potential cause (though it may itself be a symptom of something else) | 18:22 |
| @fungicide:matrix.org | > <@jim:acmegating.com> i don't think there should be an easy/supported way to do that, so i don't think it's appropriate for zuul-admin. updating tools/decrypt_secret would be okay i think. the encrypted content of repository data belongs to the users, not the zuul admins. | 18:35 |
| agreed, it's fine as an example of how to do it, e.g. for extreme disaster recovery situations, while still generally discouraged. we don't need to (and shouldn't) provide an "easy button" for it, but if we're going to include an example then it's a good idea to keep it working | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 23:43 | |
| - [zuul/zuul] 906320: Finish circular dependency refactor https://review.opendev.org/c/zuul/zuul/+/906320 | ||
| - [zuul/zuul] 907506: Update web ui for dependency refactor https://review.opendev.org/c/zuul/zuul/+/907506 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 907363: Add zuul-tenant-conf-check role/job https://review.opendev.org/c/zuul/zuul-jobs/+/907363 | 23:56 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!