[01:46] aaronprisk[m]: using sudo with apt source results in the downloaded files having the wrong owner though [01:46] so that doesn't seem like a good idea [01:47] it's fine as a workaround for now, I guess, but... [01:48] if your users aren't going to steal your token and use it elsewhere, you could set the files world readable [01:48] then any user could apt source [02:09] if all related infrastructure supports that (and doesn't revert the permissions on updates/changes or whatever) [02:10] "it's fine as a workaround for..." <- chmod 640 90ubuntu-advantage [02:10] chgrp adm 90ubuntu-advantage [02:10] make sure you're in adm group [02:10] apt source No sudo! [02:13] ViatonWidz[m]: but will that survive upgrades of whatever package drops that file there? [02:16] Debian policy is for modified config files in /etc/ to remain unchanged during updates. [02:16] you can reinstall the ubuntu-advantage-tools package to verify [02:16] perhaps the pro tool would reset the owners/permissions if you eneable or disable other services [02:21] SERVICE ENTITLED STATUS DESCRIPTION... (full message at ) [02:22] livepatch won't modify that file [02:22] note the week old timestamp :) [02:22] livepatch is installed via a snap, and then it downloads kernel modules itself [02:26] why would livepatch modify an auth file? It's the uaclient that created and touches. And enabling the livepatch service didn't modify the file at all. But as I mentioned to JanC, reinstalling the ubuntu-advantage-tools package also doesn't alter it. [02:27] hmm, maybe I misunderstood what you're trying to say [02:28] if you want to see if the pro command will modify the owner, group, or permissions of the apt configuration file that pro added, test via modifying the esm-apps or esm-infra service [02:28] those actually use apt [02:28] it's not only what happens now, but also what will happen in the future :) [02:29] if you find a way to test that, please let me know :) [02:29] if the goal is to make that official, better add test cases for it :) [02:30] to make sure that any changes to all these tools in the future won't mess with ownership/permissions (or even make those proposed changes the default?) [02:32] OOOOh it did! it did change the perm back to 0600. [02:32] Bad pro violating Debian policy like that! But I'm not gonna disable the services anytime soon so I'm not sure when I'd run into that issue. [02:32] we discussed making the more open permissions the default and decided against it; we can't assume that every user on everybody's system can be trusted with the tokens [02:33] sarnold: but with group permissions that could work [02:33] JanC: maybe; it's a change from 'adm can read logs' to 'adm can read logs and also use up your machine licenses' [02:34] maybe the logs already have the token? hah [02:34] it could be another group if necessary [02:36] (you could reuse the sudo group, as those people get access to it anyway, but that seems semantically wrong) [02:40] or alternatively APT could somehow be allowed to read it even when not run as root (or it could call sudo itself only to read that file but not to download?) [02:40] strong NACK on that one :) [02:40] picking groups is just bikeshedding, everybody loves a good bikeshedding [02:42] not having all of APT run as root would actually be a security improvement in itself too :) [02:42] sure, that's why it uses _apt to download files, if it can [02:44] maybe that all just needs to be improved then :) [02:44] but that would be a major change to apt, I suppose [02:44] I've been begging for a rust rewrite for a few years [02:45] rust wouldn't exactly fix all the possible issues [02:45] no [02:45] but it'd do wonders for the 30-year-old C++ish code === Zesues9 is now known as Zesues [06:30] good morning [06:54] where is mr cola? lol [06:54] hi lotuspsychje. [06:54] morning gonix === EriC^ is now known as EriC^^ [12:28] Evening lotuspsychje!