Saturday, 2021-07-24

*** dviroel is now known as dviroel|out00:05
tristanCcorvus: i think it's better to use access token since the owner can disable it when needed, e.g. if it leaks00:32
tristanCbut can i add login/password option to the gerritbot if you prefer00:33
corvustristanC: how do you disable the token/session?  and couldn't the same be done from a token that the bot got itself?  (you'd just need to kill the session and also change the pw, right?)00:36
tristanCcorvus: i think through , let me check00:39
tristanCcorvus: it seems like homeserver does not set refresh token, but calling disable the token01:00
tristanCor simply logout to disable a single token01:01
tristanCcorvus: clarkb: what's the issue with issuing an access_token for the bot?01:03
opendevreviewTristan Cacqueray proposed opendev/system-config master: Run matrix-gerritbot on eavesdrop
corvustristanC: just that it's an extra manual step after creating the account01:08
tristanCwe can make it automatic by calling the login endpoint before the deployment, like register curl -XPOST -d "user password" /_matrix/client/r0/login | jq -r ".access_token"01:12
corvustristanC: but we only want to do that once, so then we'd need to find a place to store it.  i think it's better either to have the bot itself do it, or do it manually.  i'd rather not write something like that in ansible01:14
tristanCcorvus: i'm not sure what you are referring to by session token, at least with the server i got a single access_token after login and used it without issue or expiry since then01:16
corvustristanC: exactly -- that's the token for that device session01:16
corvusevery time you make a new one, you get a new device showing up in the room01:17
corvusthe token is the for that device's session01:17
tristanCcorvus: how can the bot close the session then?01:18
tristanCoh i see in the backlog you are suggesting the bot should keep a state. that's certainely an option, but that makes it more complicated01:27
corvustristanC: yeah, we don't want to close the session; eavesdrop has to keep the state anyway to know when to sync from, so it's easy.  gerritbot doesn't need that, and i'm not sure it's worth adding state management just for that.01:30
tristanCon the other hand i don't think password and access_token are equivalent since a password can create many access_token01:30
corvustristanC: they aren't equivalent in that way, but they are equivalent in terms of access01:31
corvusit's not the case that an access token gives you a restricted set of functions (that was the context for the earlier discussion)01:32
tristanCcorvus: i think an access token can't change password01:32
tristanCcorvus: for eavesdrop it could check the timestamp of the log files to know if the initial sync is enough or if it needs to ask for more01:33
corvusokay.  i don't think that matters in this case though.01:33
corvustristanC: that would be much harder to implement correctly.  it would still require de-duplication to handle the edge cases.01:34
fungiwhy is the ability to change the password a risk? ultimately we would delete the account if wee needed to revoke its access, and that would invalidate any tokens it created anyway regardless of the password for the account11:33
tristanCfungi: then you need admin privilege to delete the account. I mean it's probably not a risk for opendev, but it seems safer to use access_token for bots instead of login/password13:00
fungibut then you need to use the account to create a token13:05
tristanCfungi: how are the bot account currently created?13:18
fungia sysadmin adds it to our homeserver13:28
fungione of our sysadmins with admin credentials i mean13:29
fungimy point was if you have admin control of the homeserver and can dedicate an account to each bot, then the tokens bring no additional security they just add another step for the admin provisioning the credentials13:30
fungiwe can delete a bot's account as easily as we can revoke its token13:30
tristanCwhich is why i think it's better to use access_token for bot or automated process, so that non admin user can safely use them13:37
fungii don't understand, then the bot account still needs to be accessed by someone/something14:24
fungiif the account exists only to supply a single token then the account and the token are equivalent from a risk standpoint14:24
fungitokens make sense if you have multiple processes sharing a single account but when there's only one token to an account it's not really anything other than an added hassle14:25
fungiyou can invalidate the account as effectively as you can invalidate the token it issued14:26
fungieither the process is "create account, generate token with account, supply token to application" or it's "create account, supply account credentials to application, application obtains token itself"14:33
fungithe former is less work for the administrator, the latter is more useful to users who want to reuse the same account for other activities14:34
fungisince we don't plan to reuse bot accounts for anything else, the first option is preferable for our use case, but perhaps not preferable for more general uses of the software where users may not be able to dedicate an account to the application14:35
*** gibi is now known as gibi_pto14:54
fungiclarkb: so much for theories about divergence bloat, the mirror.fedora volume ended up at 85% of its new quota when caught up completely14:54
opendevreviewTristan Cacqueray proposed opendev/system-config master: Run matrix-gerritbot on eavesdrop
tristanCfungi: i'd rather support the more general uses and avoid handling username/password in the bot process. In the last PS of ^ I made the access token creation part of the bot deployment.15:13
tristanCi think this provides a better separation of concern and that makes the bot stateless15:27
fungii'm rebooting the gitea load balancer now19:22
fungilooks like it's back up19:24
fungii can browse repos again19:24
fungirebooting the gerrit server next19:25
fungiand it's back up but the service is still starting19:26
fungiactually the container didn't start on boot but i've started it manually 19:27
fungiaha, it's set in docker-compose.yaml to "restart: always" for the mariadb container but there's no restart directive for the gerrit container19:28
fungianyway, it's back up now19:29
fungi#status log Completed restart of all servers for CVE-2021-33909 and CVE-2021-33910 (among other lower-priority vulnerabilities)19:32
opendevstatusfungi: finished logging19:32
fungiinfra-root: ^19:33
fungii'm semi-around all weekend, so if anyone spots problems i'm happy to look into them19:35
fungiotherwise going back on silent running now19:35
clarkbfungi: thanks!20:25

Generated by 2.17.2 by Marius Gedminas - find it at!