1 IRC_meeting_2024 11 12

John Johansen edited this page 2024-11-12 19:26:31 +00:00

(10:00:46 AM) jjohansen: rlee287, georgiag, cboltz, sbeattie, sarnold, mbelair, iskunk: meeting time
(10:01:13 AM) rlee287: Hello
(10:01:18 AM) ***cboltz hides
(10:02:08 AM) jjohansen: first up: I don't have the policy layout write-up/doc yet so that discussion needs to get bumped another month
(10:03:17 AM) jjohansen: next up: 4.1-beta2, should land this week. We still have a couple bug fixes to land but, I think we have patches for all except maybe one issue I am still chasing
(10:04:05 AM) jjohansen: we can release the beta without that fix, atm I am not even sure its a real issue, or a bug in the regression test suite
(10:04:35 AM) cboltz: which issue?
(10:04:56 AM) jjohansen: it is a failure on upstream kernels with unix_socket_pathname
(10:05:35 AM) jjohansen: I have a set of fixes already for unix_socket_pathname tests, that address test issues
(10:05:49 AM) jjohansen: this one remains to be figured out
(10:06:24 AM) jjohansen: I also have some fixes for deleted, and unix_server tests, that I need to send MRs for
(10:07:44 AM) jjohansen: like I said I am investigating but I don't think this particular test should stop beta2, I will try to get it fixed but plan to release the beta this week regardless. If it isn't fixed I will add a release note
(10:08:24 AM) jjohansen: cboltz: also I have not filed a gitlab issue for it yet. I will get around to it
(10:09:06 AM) cboltz: no hurries - doing the actual fix is more important than paperwork ;-)
(10:09:17 AM) jjohansen: rlee287: you wanted to discuss a proposal for backwards compat. Are you ready, or should we bump it?
(10:10:30 AM) rlee287: I think we can talk about it now, as we created the proposal at the in-person meetings (though I don't necessarily have the historical knowledge to drive the conversation by myself)
(10:10:57 AM) jjohansen: okay. rlee287 you have the floor
(10:12:50 AM) rlee287: I wanted to write down a backwards compatibility policy so that we can scope out things like which language features in C, C++, Python can be allowed in the codebase
(10:13:03 AM) rlee287: And to have a more solid reference point for other things like userspace policy handling of kernel LSM hook semantics changes over time
(10:13:17 AM) rlee287: I started looking at this because of apparmor_parser build failures on Ubuntu Trusty (14.04)
(10:14:20 AM) rlee287: In-person we (Canonical AppArmor side) reached a tentative proposal of supporting up to the toolchains and kernel versions of Ubuntu Xenial (16.04)
(10:14:35 AM) rlee287: GCC 5.x, Python 3.5, Linux 4.15
(10:14:59 AM) rlee287: So I wanted to ask for thoughts on this from other people here
(10:15:27 AM) rlee287: Once we reach a decision we should document this (so that we have something to point to if e.g. someone sends in an MR using C++17 features)
(10:15:56 AM) rlee287: And to have a basis for CI testing on older systems
(10:16:10 AM) rlee287: So: thoughts?
(10:16:36 AM) cboltz: is this policy about keeping old releases compatible, or about keeping master compatible with the old toolchain?
(10:16:58 AM) jjohansen: I will note that the kernel has its own set of requirements. Eg. your recent patch that used initialized a stack variable after a label triggered a report from the kernel test infrastructure. So this discussion is the user space components only
(10:17:29 AM) rlee287: Keeping master compatible with the older toolchains, because we may want to package the latest AppArmor for use on an older system
(10:17:47 AM) jjohansen: cboltz: no formal policy but, yes we have had a loose policy of trying to keep ~10 year or more capatability
(10:18:00 AM) jjohansen: python has been an exception, because well python ...
(10:18:01 AM) rlee287: jjohansen mentioned something about the snap tooling on the Canonical side vendoring apparmor
(10:18:14 AM) jjohansen: yes it does now, so does lxd
(10:19:09 AM) jjohansen: we have also tried to keep the library, and policy as compatible as possible
(10:19:31 AM) cboltz: indeed , python 3.5 is indeed a bit ;-) old - OTHO, I'm not sure if there are enough new features to require a newer version
(10:19:36 AM) jjohansen: the policy abi, helps with that so that the parser can make adjustments based on kernel changes
(10:20:25 AM) jjohansen: C/C++ side I have been limiiting to C++11 features
(10:20:38 AM) cboltz: as long as our CI (also?) uses old-enough versions and reports usage of too-new things, this sounds doable
(10:20:54 AM) rlee287: When was the policy abi stuff introduced?
(10:21:09 AM) cboltz: IIRC with 3.0
(10:21:16 AM) rlee287: OK
(10:21:32 AM) jjohansen: uhmm, so abi rules in 3.0. Though the were front run in 2.13 and and backported to 2.12
(10:21:50 AM) jjohansen: the 2.13, 2.12 version are just to parse and ignore
(10:22:24 AM) jjohansen: but abi via the feature file has existed since I think 2.8
(10:22:39 AM) jjohansen: which is about ~2009
(10:22:53 AM) rlee287: C/C++ side: I saw that libapparmor's automake setup checks for C99 (and not C11), but since we are using C++11 for the parser, it would seem logical to me to allow C11 in libapparmor as well
(10:23:08 AM) jjohansen: previously the expectation was policy on the system would pin the abi, and everything in the namespace would use the same abi
(10:23:09 AM) rlee287: Unless GCC 5.x (or whatever toolchain we settle on) supports C++11 but not C11 for some reason
(10:23:17 AM) jjohansen: this generally wasn't done
(10:25:02 AM) jjohansen: rlee287: so yes we need to go through and check that. The reality is more complicated. In that we were forced by newer tool chains to change exception handling
(10:25:23 AM) jjohansen: but that is something we don't use a lot. Generally we are not using C11 features
(10:26:11 AM) jjohansen: but if everything pans out we should update automake to use C11
(10:26:58 AM) rlee287: IIRC I coded a C version check for C11 into one of my MRs in order to conditionally allow static_assert
(10:27:35 AM) rlee287: And it would be a nice-to-have to use C atomics instead of GCC extensions for refcounting
(10:27:42 AM) jjohansen: sure
(10:28:15 AM) rlee287: Could you elaborate a bit on the exception handling point?
(10:30:36 AM) jjohansen: C++ simplified what is returned by the exception, and can be handled by the exception handler, it deprecated the older ability to specify the exception object, and newer tool chains removed it
(10:30:59 AM) jjohansen: so while we strive to be backward compatible we also have to build on current tool chains
(10:31:33 AM) rlee287: I see
(10:32:38 AM) jjohansen: in the end, like with say python the current tool chain will win because we need to be compatible with the dominant use case
(10:32:57 AM) jjohansen: we just do our best to be backwards compatible
(10:33:19 AM) ***georgiag is here
(10:37:25 AM) jjohansen: so rlee287 I do think its a good idea to document what we are trying to be compatible with. I am happy with the targets already discussed
(10:37:45 AM) jjohansen: I think the next step is making sure the CI is doing the testing and get it documented
(10:38:28 AM) rlee287: Yep
(10:39:35 AM) jjohansen: next up: how to help debian, and alpine and other distros update to more recent apparmor
(10:40:15 AM) jjohansen: basically I think we need to step up and update packages for them and propose them, within the methods provided by the distro
(10:40:52 AM) jjohansen: the distro maintainers are not doing the update so it falls on us to try and step up and help them where we can
(10:41:11 AM) jjohansen: Ubuntu side, this is something we should be doing for debian regardless
(10:41:40 AM) rlee287: Alpine currently has a libapparmor build failure right now which would need to be addressed first
(10:41:47 AM) jjohansen: jamie used to do it, but when he moved to a new job that stopped
(10:41:53 AM) jjohansen: yes
(10:42:03 AM) jjohansen: and we need to get that fixed
(10:42:39 AM) jjohansen: I agree we start with debian, but addressing the alpine build failure is something we should be taking seriously
(10:43:02 AM) jjohansen: also, the need for down streams to have properly signed packages
(10:43:11 AM) jjohansen: I plan to look at that this week
(10:43:45 AM) jjohansen: see if I can't beat the maintainer script we use to use the gitlab api correctly
(10:44:31 AM) Talkless [~Talkless@mail.dargis.net] entered the room.
(10:44:56 AM) minimal: re: alpine, it is on 3.1.7 currently which is labelled as the current stable release
(10:45:14 AM) minimal: so am confused by "the distro maintainers are not doing the update so it falls on us to try and step up and help them where we can"
(10:47:48 AM) jjohansen: minimal: so, two things. 1 its not just alpine, eg. debian hasn't been updating. 2. making current releases even non-stable available for testing on those distros is important, otherwise we won't get reports of breakage, and the stable won't be ready
(10:47:55 AM) jjohansen: but you raise a good point
(10:48:15 AM) jjohansen: it is time we get a 4.x stable
(10:48:26 AM) rlee287: Is the 4.0.x series labelled as something in between stable and beta currently?
(10:48:52 AM) jjohansen: 4.0 - was explicitly stated to be a short lived release
(10:48:57 AM) minimal: ok, but 4.0.x is explicitly labelled as a "short-lived releases" and 4.1 is a BETA
(10:48:59 AM) jjohansen: we have not released 4.1 yet
(10:49:13 AM) jjohansen: 4.1 is wayyyyy behind schedule
(10:49:14 AM) minimal: so you expect Alpine to update to a Beta?
(10:49:34 AM) georgiag: @rlee287: it is labeled as development https://gitlab.com/apparmor/apparmor/-/wikis/home#userspace
(10:49:53 AM) jjohansen: no, I want to make sure we have a Beta package available for Alpine, and Debian, ...
(10:50:26 AM) jjohansen: I want people to be able to feed info back to us so that when we have the next release, it will work for them
(10:50:29 AM) minimal: ah, packaged yourselves, ok
(10:50:59 AM) jjohansen: this will also help with down stream, who obviously don't have a lot of time
(10:51:25 AM) jjohansen: I get that we don't either, and can't do it for everyone. But we can do a little better than we have been
(10:51:45 AM) minimal: I'd looked at 4.0.x in the past to package locally for Alpine, saw the "short lived release" statement and didn't progress
(10:51:57 AM) jjohansen: understandable
(10:52:43 AM) jjohansen: generally speaking, I would like to see us to a package for fedora, and the fedora derivatives as well
(10:53:04 AM) jjohansen: that is a step needed for us to request fedora to enable in their kernel
(10:53:13 AM) jjohansen: well enable as an option
(10:53:26 AM) jjohansen: so it can be selected at boot
(10:53:52 AM) jjohansen: upstream stacking has also almost progressed far enough that we can co-exist with selinux
(10:53:55 AM) cboltz: IIRC there's a fedora spin for games that already uses AppArmor by default
(10:54:01 AM) jjohansen: I want to make sure we are ready for that
(10:54:18 AM) jjohansen: yep, and I think we look there for a start
(10:56:07 AM) jjohansen: for those interested the fedora derivative that is using apparmor is Nobara
(11:00:08 AM) jjohansen: okay, so I think we are in agreement we need to do better. I will take an action item to look into the alpine linux build failure more and I am looking for volunteers on the debian, and fedora packaging side
(11:00:35 AM) jjohansen: if I don't get that, well I might voluntold someone on the Canonical side :)
(11:00:55 AM) jjohansen: do we have anything else to discuss
(11:01:43 AM) cboltz: you skipped the topic of file rules with permissions first - was that intentional?
(11:02:02 AM) cboltz: (I like the current way, so - no hurry ;-)
(11:02:02 AM) jjohansen: yep :)
(11:02:19 AM) rlee287: So the list of distros we have in mind is Debian, Alpine, and Fedora? Are there others we'd want to look at, or are those three the big ones we'd have the resources to look at
(11:02:39 AM) jjohansen: so I am for switching, and just didn't think we had anything to add this month, that wasn't already discussed
(11:04:00 AM) jjohansen: rlee287: arch, but the arch maintainer has been keeping up, except for the signing issue with the current release. So atm I think we fix that at see where how arch is doing
(11:04:16 AM) rlee287: OK
(11:04:16 AM) jjohansen: also people should feel free to make suggestions
(11:05:06 AM) jjohansen: for other distros. Ideally we should have at least one for each major packaging format, and provide a reference package, so that down streams can run with it
(11:05:33 AM) jjohansen: debian and ubuntu are close enough that it makes sense to feed the ubuntu packaging to debian
(11:06:23 AM) jjohansen: while suse and fedora both use rpm, they have diverged enough that I think having a fedora rpm separate from the suse one is worth while
(11:06:47 AM) jjohansen: then we have the alpine, arches, and if someone really wants gentoo
(11:07:18 AM) jjohansen: I am sure there are ones I am missing, but that I think that is a good starter list
(11:07:44 AM) cboltz: re openSUSE and Fedora - I'm quite sure Nobara doesn't use the openSUSE packages ;-)  (but didn't check)
(11:08:38 AM) jjohansen: right, I figure we could look at what they did and compare against suse, see what can be updated, or synchronized
(11:09:06 AM) jjohansen: Ideally, I would like the diff to be as small as possible but we will just have to look at it and see
(11:11:05 AM) jjohansen: next meeting is scheduled for Dec 10, @18:00 utc
(11:11:10 AM) jjohansen: I think that is everything, so I think its time to call meeting adjourned
(11:11:13 AM) jjohansen: thanks everyone
(11:11:14 AM) cboltz: looks like Nobara sources are at https://github.com/Nobara-Project/rpm-sources/tree/main/baseos
(11:11:17 AM) cboltz: I have two more topics, both about open MRs
(11:11:33 AM) jjohansen: haha, you should have spoken sooner
(11:11:35 AM) jjohansen: :)
(11:11:39 AM) jjohansen: cboltz: go
(11:11:46 AM) cboltz: https://gitlab.com/apparmor/apparmor/-/merge_requests/1324 - is there any reason why it isn't merged yet (besides needing another rebase)?
(11:13:16 AM) jjohansen: yes. I haven't had time to give it a review, and I specifically asked maxim not to merge until I did. Last time I looked there were a couple of specific issues I wanted addressed
(11:14:00 AM) cboltz: that MR also fixes aa-notify for openSUSE, therefore it would be nice if you do that review soon ;-)
(11:14:03 AM) jjohansen: it will come, I am not in a hurry on it because this feature will not be backported to 4.1 and I have been trying to address the 4.1 issues so we can get the beta out
(11:14:20 AM) cboltz: (currently I need to have test-aa-notify patched away locally)
(11:14:23 AM) jjohansen: okay, so I guess that raises the priority some
(11:14:34 AM) jjohansen: ack
(11:14:39 AM) cboltz: :-)
(11:14:43 AM) cboltz: next one:
(11:14:46 AM) cboltz: https://gitlab.com/apparmor/apparmor/-/merge_requests/1282 - do you really think reading the sqlite database directly is bad enough to introduce the pain of parsing the formatted date?
(11:15:06 AM) jjohansen: yes
(11:15:31 AM) jjohansen: especially when parsing the date can be done via lib or calling external tool
(11:16:22 AM) cboltz: the problem is that with the libraries included in python base I got interesting[tm] results - and pandas has a very big on-disk footprint which I'd also like to avoid
(11:16:36 AM) jjohansen: I have a real (admittedly maybe irrational) fear of messing around with an external tools internal format
(11:16:53 AM) jjohansen: understandable
(11:17:16 AM) cboltz: well, we parsed /var/log/wtmp before, which is even a custom and arch-dependent binary format
(11:17:24 AM) cboltz: in comparison, sqlite3 is boring and easy ;-)
(11:17:33 AM) jjohansen: what about an apparmor lib interface? that just calls the C lib used by date?
(11:18:03 AM) jjohansen: funny you should point to part of why I have said fear
(11:18:25 AM) cboltz: that sounds like more overhead than I'd like to have ;-)
(11:18:25 AM) jjohansen: :)
(11:18:37 AM) jjohansen: understandable
(11:19:47 AM) cboltz: also, I think that it's very unlikely that lastlog2 will change its internals - well, at least until it hits the date limit of 64 bit, but let's fix that when it becomes an issue ;-)
(11:19:51 AM) jjohansen: so, how about I poke a few people to see if they care at all
(11:20:52 AM) cboltz: I won't stop you ;-)
(11:21:24 AM) cboltz: but if the answer takes too long, I'd say we can merge the MR as is (using sqlite) - and if someone submits a better way, we can always switch
(11:22:59 AM) jjohansen: okay
(11:23:10 AM) jjohansen: alright meeting really adjourned