| *** dviroel is now known as dviroel|out | 00:05 | |
| tristanC | corvus: i think it's better to use access token since the owner can disable it when needed, e.g. if it leaks | 00:32 |
|---|---|---|
| tristanC | but can i add login/password option to the gerritbot if you prefer | 00:33 |
| corvus | tristanC: 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 |
| tristanC | corvus: i think through https://matrix.org/docs/spec/legacy/#post-matrix-client-api-v1-tokenrefresh , let me check | 00:39 |
| tristanC | corvus: it seems like matrix.org homeserver does not set refresh token, but calling https://matrix.org/docs/spec/client_server/latest#post-matrix-client-r0-logout-all disable the token | 01:00 |
| tristanC | or simply logout to disable a single token | 01:01 |
| tristanC | corvus: clarkb: what's the issue with issuing an access_token for the bot? | 01:03 |
| opendevreview | Tristan Cacqueray proposed opendev/system-config master: Run matrix-gerritbot on eavesdrop https://review.opendev.org/c/opendev/system-config/+/800506 | 01:07 |
| corvus | tristanC: just that it's an extra manual step after creating the account | 01:08 |
| tristanC | we 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 |
| corvus | tristanC: 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 ansible | 01:14 |
| tristanC | corvus: i'm not sure what you are referring to by session token, at least with the matrix.org server i got a single access_token after login and used it without issue or expiry since then | 01:16 |
| corvus | tristanC: exactly -- that's the token for that device session | 01:16 |
| corvus | every time you make a new one, you get a new device showing up in the room | 01:17 |
| corvus | the token is the for that device's session | 01:17 |
| tristanC | corvus: how can the bot close the session then? | 01:18 |
| tristanC | oh i see in the backlog you are suggesting the bot should keep a state. that's certainely an option, but that makes it more complicated | 01:27 |
| corvus | tristanC: 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 |
| tristanC | on the other hand i don't think password and access_token are equivalent since a password can create many access_token | 01:30 |
| corvus | tristanC: they aren't equivalent in that way, but they are equivalent in terms of access | 01:31 |
| corvus | it'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 |
| tristanC | corvus: i think an access token can't change password | 01:32 |
| tristanC | corvus: 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 more | 01:33 |
| corvus | okay. i don't think that matters in this case though. | 01:33 |
| corvus | tristanC: that would be much harder to implement correctly. it would still require de-duplication to handle the edge cases. | 01:34 |
| fungi | why 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 account | 11:33 |
| tristanC | fungi: 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/password | 13:00 |
| fungi | but then you need to use the account to create a token | 13:05 |
| tristanC | fungi: how are the bot account currently created? | 13:18 |
| fungi | a sysadmin adds it to our homeserver | 13:28 |
| fungi | one of our sysadmins with admin credentials i mean | 13:29 |
| fungi | my 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 credentials | 13:30 |
| fungi | we can delete a bot's account as easily as we can revoke its token | 13:30 |
| tristanC | which is why i think it's better to use access_token for bot or automated process, so that non admin user can safely use them | 13:37 |
| fungi | i don't understand, then the bot account still needs to be accessed by someone/something | 14:24 |
| fungi | if the account exists only to supply a single token then the account and the token are equivalent from a risk standpoint | 14:24 |
| fungi | tokens 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 hassle | 14:25 |
| fungi | you can invalidate the account as effectively as you can invalidate the token it issued | 14:26 |
| fungi | either 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 |
| fungi | the former is less work for the administrator, the latter is more useful to users who want to reuse the same account for other activities | 14:34 |
| fungi | since 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 application | 14:35 |
| *** gibi is now known as gibi_pto | 14:54 | |
| fungi | clarkb: so much for theories about divergence bloat, the mirror.fedora volume ended up at 85% of its new quota when caught up completely | 14:54 |
| opendevreview | Tristan Cacqueray proposed opendev/system-config master: Run matrix-gerritbot on eavesdrop https://review.opendev.org/c/opendev/system-config/+/800506 | 15:05 |
| tristanC | fungi: 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 |
| tristanC | i think this provides a better separation of concern and that makes the bot stateless | 15:27 |
| fungi | i'm rebooting the gitea load balancer now | 19:22 |
| fungi | looks like it's back up | 19:24 |
| fungi | i can browse repos again | 19:24 |
| fungi | rebooting the gerrit server next | 19:25 |
| fungi | and it's back up but the service is still starting | 19:26 |
| fungi | actually the container didn't start on boot but i've started it manually | 19:27 |
| fungi | aha, it's set in docker-compose.yaml to "restart: always" for the mariadb container but there's no restart directive for the gerrit container | 19:28 |
| fungi | anyway, it's back up now | 19:29 |
| fungi | #status log Completed restart of all servers for CVE-2021-33909 and CVE-2021-33910 (among other lower-priority vulnerabilities) | 19:32 |
| opendevstatus | fungi: finished logging | 19:32 |
| fungi | infra-root: ^ | 19:33 |
| fungi | i'm semi-around all weekend, so if anyone spots problems i'm happy to look into them | 19:35 |
| fungi | otherwise going back on silent running now | 19:35 |
| clarkb | fungi: thanks! | 20:25 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!