[01:46] <JanC> aaronprisk[m]: using sudo with apt source results in the downloaded files having the wrong owner though
[01:46] <JanC> so that doesn't seem like a good idea
[01:47] <JanC> it's fine as a workaround for now, I guess, but...
[01:48] <sarnold> if your users aren't going to steal your token and use it elsewhere, you could set the files world readable
[01:48] <sarnold> then any user could apt source
[02:09] <JanC> if all related infrastructure supports that (and doesn't revert the permissions on updates/changes or whatever)
 "it's fine as a workaround for..." <- chmod 640 90ubuntu-advantage
[02:10] <ViatonWidz[m]> chgrp adm 90ubuntu-advantage
[02:10] <ViatonWidz[m]> make sure you're in adm group
[02:10] <ViatonWidz[m]> apt source <packagename> No sudo!
[02:13] <JanC> ViatonWidz[m]: but will that survive upgrades of whatever package drops that file there?
[02:16] <ViatonWidz[m]> Debian policy is for modified config files in /etc/ to remain unchanged during updates.
[02:16] <ViatonWidz[m]> you can reinstall the ubuntu-advantage-tools package to verify
[02:16] <sarnold> perhaps the pro tool would reset the owners/permissions if you eneable or disable other services
[02:21] <ViatonWidz[m]> SERVICE          ENTITLED  STATUS    DESCRIPTION... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/1eea7701118c5c5b1116f91c3dfdb1fba19fdcc2>)
[02:22] <sarnold> livepatch won't modify that file
[02:22] <sarnold> note the week old timestamp :)
[02:22] <sarnold> livepatch is installed via a snap, and then it downloads kernel modules itself
[02:26] <ViatonWidz[m]> 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] <sarnold> hmm, maybe I misunderstood what you're trying to say
[02:28] <sarnold> 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] <sarnold> those actually use apt
[02:28] <JanC> it's not only what happens now, but also what will happen in the future  :)
[02:29] <sarnold> if you find a way to test that, please let me know :)
[02:29] <JanC> if the goal is to make that official, better add test cases for it  :)
[02:30] <JanC> 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] <ViatonWidz[m]> OOOOh it did! it did change the perm back to 0600. 
[02:32] <ViatonWidz[m]> 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] <sarnold> 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] <JanC> sarnold: but with group permissions that could work
[02:33] <sarnold> 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] <sarnold> maybe the logs already have the token? hah
[02:34] <JanC> it could be another group if necessary
[02:36] <JanC> (you could reuse the sudo group, as those people get access to it anyway, but that seems semantically wrong)
[02:40] <JanC> 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] <sarnold> strong NACK on that one :)
[02:40] <sarnold> picking groups is just bikeshedding, everybody loves a good bikeshedding
[02:42] <JanC> not having all of APT run as root would actually be a security improvement in itself too  :)
[02:42] <sarnold> sure, that's why it uses _apt to download files, if it can
[02:44] <JanC> maybe that all just needs to be improved then  :)
[02:44] <JanC> but that would be a major change to apt, I suppose
[02:44] <sarnold> I've been begging for a rust rewrite for a few years
[02:45] <JanC> rust wouldn't exactly fix all the possible issues
[02:45] <sarnold> no
[02:45] <sarnold> but it'd do wonders for the 30-year-old C++ish code
[06:30] <lotuspsychje> good morning
[06:54] <gonix> where is mr cola? lol
[06:54] <gonix> hi lotuspsychje.
[06:54] <lotuspsychje> morning gonix 
[12:28] <wez> Evening lotuspsychje!