1 IRC_meeting_2024 10 08

John Johansen edited this page 2024-10-08 19:55:26 +00:00

(11:02:16 AM) jjohansen: cboltz, sbeattie, rlee287, mbelair, georgiag, sarnold, iskunk: meeting time
(11:02:54 AM) ***cboltz hides
(11:04:53 AM) rlee287: hello
(11:06:37 AM) jjohansen: so first up, policy layout
(11:07:03 AM) jjohansen: I have not had time to work on the proposed document so, will have to kick this item to next month
(11:11:15 AM) ***georgiag is here
(11:11:35 AM) cboltz: I have two topics around python modules
(11:11:39 AM) jjohansen: next up is leading vs. trailing permissions default
(11:12:15 AM) cboltz: jjohansen: I can wait until your topics are done
(11:12:39 AM) jjohansen: cboltz: ack
(11:13:00 AM) jjohansen: I don't have much to add to the current topic and propose kicking it to next month too
(11:13:17 AM) jjohansen: next topic 4.1-beta2
(11:14:21 AM) jjohansen: its just a matter of doing the work to get it out the door, when? When I can find time to do it, or if someone else does the work
(11:14:58 AM) jjohansen: cboltz: alright you are up
(11:15:33 AM) cboltz: first one is the "ttkthemes" module which is now needed by aa-notify
(11:16:03 AM) cboltz: the problem is that it isn't packaged for openSUSE - which is solvable, but I wonder if other distros have packages for it
(11:16:18 AM) cboltz: or if it would make sense to switch to a better available module
(11:16:55 AM) jjohansen: ubuntu does package it, I haven't looked at other distros yet
(11:17:19 AM) jjohansen: as for better modules, proposals, and/or patches welcome
(11:18:44 AM) jjohansen: tk does have some advantages/disadvantages over gtk/qt
(11:19:08 AM) jjohansen: I know maxim spent some time on a gtk version and decided to stick with tk
(11:19:31 AM) jjohansen: tkthemes really are required to make tk look any where near descent
(11:20:01 AM) jjohansen: however tk does work without theming
(11:20:14 AM) mbelair: @cboltz Honestly I used tk for sake of simplicity. It is somewhat annoying to use gtk for daemonized apps, which is the case of aa-notify
(11:20:27 AM) jjohansen: so the themeing part could be made optional in the code and a suggests
(11:20:53 AM) cboltz: sounds good :-)
(11:21:14 AM) jjohansen: I will also state that gtk has been very bad at breaking abis, and tossing out forward/backwards compatibility
(11:21:16 AM) cboltz: (I might still package python3-ttkthemes, but it would soften the issue)
(11:21:23 AM) jjohansen: making it a poor choice
(11:21:39 AM) cboltz: indeed, that sounds funny[tm]
(11:22:01 AM) jjohansen: cboltz: making it optional so the dependency can be a suggests?
(11:22:17 AM) cboltz: yes
(11:22:32 AM) jjohansen: I agree, doing that makes sense
(11:22:58 AM) jjohansen: I think we are going to hit the themeing problem on more than just suse
(11:23:48 AM) jjohansen: we will see if we can't get a patch doing that soon
(11:24:17 AM) jjohansen: we (being royal variety, and not necessarily me ;-) )
(11:24:48 AM) jjohansen: okay cboltz next topic
(11:24:48 AM) mbelair: I will do it, it should not be too hard
(11:24:49 AM) cboltz: I just had a look at gui.py (the only file that imports ttkthemes), and making it optional is probably boring and doable with two if conditions
(11:25:15 AM) mbelair: yes, there should be no issue with that
(11:25:19 AM) jjohansen: thanks mbelair
(11:26:17 AM) cboltz: thanks mbelair 
(11:26:35 AM) mbelair: No problem :)
(11:26:53 AM) cboltz: so we can probably jump to the next python module - cgitb (which we use to get useful bugreports) will be dropped in python 3.13
(11:27:09 AM) cboltz: https://gitlab.com/apparmor/apparmor/-/issues/447 lists some alternatives a quick search brought up
(11:27:49 AM) cboltz: very quick testing shows that on my laptop, I already have rich.traceback installed
(11:27:59 AM) cboltz: or the others, I'd need to check if they are packaged
(11:28:20 AM) cboltz: feedback is welcome - do you have any preferences what we should use?
(11:28:50 AM) cboltz: s/^or/for/
(11:30:26 AM) jjohansen: I really don't have a preference, I think we need to do some testing and see what is available for various distros. What kind of dependencies will be introduced
(11:30:35 AM) jjohansen: we can dump that info in the issue
(11:30:41 AM) jjohansen: and go from there
(11:35:18 AM) jjohansen: cboltz: anything else?
(11:35:54 AM) cboltz: just a quick info about a not-so-quick topic ;-)
(11:36:10 AM) jjohansen: okay, have at it
(11:36:31 AM) cboltz: maybe you've seen my draft MR where I start to store profiles with "foo//bar" keys instead of [profile][hat]
(11:36:56 AM) cboltz: the final goal of this change is to support nested childs in aa-*
(11:37:10 AM) cboltz: but it's probably not a big surprise that this will take time
(11:37:22 AM) jjohansen: no surprise at all :)
(11:38:32 AM) cboltz: also, as usual, I found more side quests ;-) than expected - for example, !1359 is one I considered worth to be split out
(11:39:21 AM) cboltz: there are also some smaller issues I'll probably keep in !1360 because splitting them out isn't worth the effort (and/or would cause merge conflicts later)
(11:40:26 AM) cboltz: long-term goal is to get rid of the "aa" dict in aa.py, and only using active_profiles as profile storage
(11:40:46 AM) cboltz: needless to say that I expect a few surprises until we are there ;-)
(11:41:03 AM) cboltz: I guess that's enough as a quick overview
(11:43:51 AM) cboltz: ok, maybe one addition: if someone wants to do a _quick_ review ("on the general direction" or so), that's welcome - but you should expect quite some more commits in this MR
(11:45:20 AM) georgiag: this MR being 1360, right? 
(11:45:30 AM) cboltz: right
(11:45:57 AM) georgiag: thanks
(11:46:29 AM) jjohansen: okay, thanks cboltz, /me someone will give it a quick review
(11:46:40 AM) jjohansen: does anyone else have something to discuss
(11:46:48 AM) rlee287: Asking for clarification on a previously-punted topic: what is the work that still needs to be done before releasing 4.1-beta2?
(11:49:10 AM) jjohansen: well
(11:49:10 AM) jjohansen: 1. need to make a 4.1 branch, beta1 was done off of master but since then commits have landed that will not go into 4.1
(11:50:00 AM) jjohansen: 2. need to go through master and see if there are commits that should be picked to 4.1 (also 4.0, 3.1, 3.0, 2.13 but those aren't required for release)
(11:50:08 AM) jjohansen: 3. work on the release notes
(11:51:04 AM) jjohansen: 4. the whole release process dance, which is more than cutting the release tarball on github
(11:52:02 AM) jjohansen: its not like its tons of work, it just isn't as high of a priority as some of the other stuff I am trying to do atm
(11:52:13 AM) rlee287: I see, thanks for clarifying
(11:52:36 AM) georgiag: it would be good if we fixed ee1a5e6e18b1d59390085cc51dc702e9692f0162 before 4.1-beta2, either by reverting or figuring out what's wrong... i havent been able to yet :S
(11:53:55 AM) jjohansen: georgiag: sorry I know there are issues there but do you have a bug or issue in particular?
(11:54:45 AM) georgiag: that one breaks pam tests and inet mediation tests too
(11:54:55 AM) georgiag: I didn't create a gitlab issue for it yet
(11:56:31 AM) jjohansen: georgiag: can you create the issue please. I will try and look give it a cursory look today
(11:57:11 AM) georgiag: will do
(11:57:37 AM) cboltz: looking at the commits in master since beta1, I wonder - are there really things we don't want in beta2 (besides the broken commit you just mentioned)? My (quick) impression is that most commits look like fixes or small improvements
(11:57:55 AM) cboltz: the biggest changes are probably in aa-notify, but IIRC that has a freeze exception anyway
(11:59:02 AM) cboltz: so unless there's something you absolutely don't want, I just do the branch from current master
(12:00:25 PM) jjohansen: cboltz: yes there is definitely stuff that should not be picked. At this point I am not even sure the aa-notify stuff should be picked, being its mostly functional improvements and not bug fixes
(12:01:16 PM) jjohansen: we really need to get our release down to freeze and then bug fixes
(12:01:55 PM) jjohansen: being a beta its not so bad, but generally beta should mean the features are there
(12:02:15 PM) jjohansen: dropping features in late means more betas, and later release
(12:03:05 PM) jjohansen: I would like to get the release out the door asap
(12:03:26 PM) jjohansen: I am willing to take feedback/opinions on what should go in
(12:03:52 PM) cboltz: yeah, known method from Novell times ;-)  From my quote collection:     And as Novell has shown with the packager: it's never too late for a beta, to add new features ;-)     [Marcel Hilzinger in opensuse]
(12:04:00 PM) jjohansen: the aim again is to have more smaller releases
(12:04:11 PM) jjohansen: so a 4.2 early next year
(12:04:13 PM) cboltz: that was when a new package manager (!) was introduced in 10.1 beta4 ;-)
(12:04:49 PM) jjohansen: hahaha, yeah I remember that one :-)
(12:05:16 PM) cboltz: on the positive side - all the other software in that release was very stable and well-tested
(12:05:19 PM) gast0n left the room (quit: Ping timeout: 480 seconds).
(12:05:33 PM) cboltz: which was a good thing, because installing updates was ... a bit broken or so
(12:06:05 PM) cboltz: (try to install updates with a broken updater... ;-)
(12:06:29 PM) jjohansen: yeah, that is a quite generous "a bit"
(12:07:21 PM) jjohansen: alright is there anything else to discuss?
(12:08:30 PM) cboltz: nothing from me, except "have fun deciding which zgrep MR you prefer" ;-)
(12:09:05 PM) roddhjav: Well, speaking of untested stuff ;). What is your plan about adding tunables like in: https://gitlab.com/apparmor/apparmor/-/merge_requests/1088
(12:12:33 PM) cboltz: I like the idea to get these tunables upstream
(12:13:21 PM) cboltz: as you found out, it's probably a good idea to do small MRs so that discussions don't block everything ;-)  - and yes, I'm aware that this means lots of MRs
(12:14:31 PM) jjohansen: so I don't have a plan because I haven't thought about those yet :)
(12:15:47 PM) roddhjav: cboltzYes, I will close this PR and start a new one, short, with the tunable that are the most obvious only.
(12:18:30 PM) cboltz: looking at all the XDG_*_DIR variables reminds me that it would be nice to have a way to reset/clear a variable (instead of just being able to add something to it) - but that's another can of worms
(12:19:10 PM) jjohansen: generally I don't have a problem with finer tunables, especially if they build on top of existing ones
(12:19:27 PM) cboltz: (most of the XDG_DIR paths don't match what I use - but that's just a personal preference, not a complaint about these variables ;-)
(12:20:06 PM) jjohansen: but I also have concerns about @{libs}, and @{bin} and we need to think of ways to tighten those
(12:21:03 PM) roddhjav: How can we tighten them?
(12:22:27 PM) jjohansen: that is a good question :)
(12:22:42 PM) jjohansen: some of the answer is better conditional support
(12:23:41 PM) jjohansen: but also making sure we don't clump different types of libs together, eg. python_libs don't belong with system libs ...
(12:24:41 PM) jjohansen: I need to spend some time looking at it, to give some feedback
(12:25:00 PM) jjohansen: I should note we also have to goal of folding in the apparmor/profiles/extras
(12:25:35 PM) jjohansen: well and the current apparmor/profiles project
(12:26:00 PM) jjohansen: and then splitting all that back out, some policy updates can be done async to the rest of the project
(12:26:35 PM) jjohansen: getting all that to happen is going to take a bit, and making sure the profiles actually have value
(12:26:51 PM) jjohansen: eg. Ubuntu's cups profile is just about useless
(12:27:19 PM) jjohansen: it just provides too much access, and because of that could not block cupstastraphy
(12:28:17 PM) jjohansen: generally speaking we need to work on cleaning up and tightening, providing knobs for all the profiles we have
(12:30:29 PM) roddhjav: I agree about splitting profiles and apparmor itself. For that matter, I think shipping one unique package with all (~2000) profiles is not a good idea, and they should be splitted too (see https://github.com/roddhjav/apparmor.d/issues/464) 
(12:31:29 PM) jjohansen: having all profiles together in a repo, is a separate issue from how they are packaged and shipped
(12:32:38 PM) roddhjav: I will start with a new PR with tunable (without @{bin} and @{lib}) and we can consider the future of profile later
(12:32:48 PM) jjohansen: and you have to figure out inter-profile dependency for splitting
(12:33:23 PM) jjohansen: but yes, some of the profiles will be shipped in packages. Eg. I think on ubuntu cups will continue to ship its profile
(12:34:44 PM) roddhjav: Agreed. It is easier to work with all profiles in the same repo. Meanwhile shipping only one package lead to breakage. But managing profile dependencies is a pain...
(12:35:34 PM) jjohansen: yes it is, sounds like an opportunity for some tooling
(12:35:41 PM) rlee287: Do profile dependencies only show up explicitly via includes, or is it more complicated than that
(12:35:58 PM) jjohansen: its more complicated
(12:36:31 PM) jjohansen: there are ipc rules, x rules, etc that depend on another profile
(12:36:52 PM) roddhjav: It is more about things such  direct Px, peer label in dbus, ptrace...
(12:37:03 PM) jjohansen: technically even file rules can, though that hasn't been implemented yet
(12:38:01 PM) rlee287: right
(12:39:28 PM) jjohansen: the parser can extract the info, its a matter of abstracting it and outputting the dependency graph
(12:41:57 PM) Talkless left the room (quit: Remote host closed the connection).
(12:42:06 PM) cboltz: the python code should also be able to do that - the thing you'd need to add is to "look" at the rules you are interested in (exec rules, peer= etc.)
(12:43:57 PM) roddhjav: This sound doable
(12:46:15 PM) jjohansen: anything else to discuss
(12:49:04 PM) jjohansen: okay, lets call it meeting adjourned