IRC Meetings

We try to meet once a month on the 2nd Tuesday of the month, in #apparmor on oftc.net

If there are reasons to move the time or date we will, and announcements will be sent out to the apparmor mailing list

Current year meeting Logs are linked off of the month agenda title.

ping before meeting: georgiag, mbelair, rlee287, sbeattie, sarnold, cboltz, iskunk

Next Meeting - IRC Meeting, 18:00 UTC, Tue Mar 11, 2025

announcement: new 4.1 beta released upstream
policy layout continued. How to handle /etc/apparmor.d and subdirs
- jj: write-up first draft of proposal
file policy rule order consistency. perms first or last (continued)
rlee287: AppArmor utils currently using features beyond Python 3.5
- AppArmor Python utils contain Python f-strings (3.6) and datetime.datetime.fromisoformat (3.7) and possibly other things too
  - f-strings would be easy enough to remove, but fromisoformat would need a polyfill
  - How do we want to approach complications like a potential need to polyfill newer Python library features?
  - If we decide to polyfill we could perhaps polyfill the required cgitb functionality forward for Python 3.13
- Alternative to polyfilling: reconsidering Python 3.5 as the baseline for the utils (specifically)
- I'm in favor of sticking to Python 3.5 and not splitting the minimum version requirements (or at most Python 3.6 of OpenSUSE Leap, if we must split)
rlee287: Review of a draft CONTRIBUTING.md (MR link https://gitlab.com/apparmor/apparmor/-/merge_requests/1457)
- Documents versions of GCC, Python etc.
- Profile testing instruction stuff (written as part of a Canonical effort to have more AppArmor profiles, but also stuff that we'd want other profile contributors to observe)
request to use file extension on profile names (maybe .apparmor) to make it easier for external tooling to know/understand what the files are for.
- rlee287: I propose .aaprof
- new profiles would be asked to use new syntax
- develop plan for migrating profile file names (already an issue)
  - do we want to rename abstractions as well?
  - potentially use symlinks and auto depdup
  - other suggestions?
rlee287: proposal for re"actual_regex" syntax to allow for things like re"/proc/[1-9][0-9]*/[^/]+" r using the full (non-backtracking) regex expressiveness while keeping the existing AARE usage as-is
- Quoting of AAREs already allowed so this is a minimal syntax change
- Not proposing prioritization of adding this feature, merely proposing a syntax to get feedback

IRC Meeting, 18:00 UTC, Tue Feb 18, 2025

IRC Meeting, 18:00 UTC, Tue Jan 14, 2025

apparmor-4.1 beta, and other release plans
cboltz: merge lastlog2 support
roddhjav: selinux play machines

IRC Meeting, 18:00 UTC, Tue Nov 12, 2024

policy layout continued. How to handle /etc/apparmor.d and subdirs
- jj: write-up first draft of proposal
file policy rule order consistency. perms first or last (continued)
rlee287: proposal for backwards and forwards compatibility policy, formed at The Hague sprint: use of the toolchain versions of the oldest supported ESM release (Xenial as of the time of writing), i.e. GCC 5.x, Python 3.5, Linux 4.15
rlee287: (if time) steps involved to help Debian, Alpine, etc. package the AppArmor 4.x series (Debian first, as Alpine currently has a libapparmor build failure that would need to be fixed first)
anything else?
cbolts MR:1282, MR:1324