[07:44] <jslarraz> Hey sdeziel, regarding iperf3 updates, they include fixes for different vulnerabilities as you can see from the USNs. The reasoning here is that iperf3 is a universe package and as such, security fixes are devoted to Ubuntu Pro (-esm). However, as fix for CVE-2023-38403 was already provided by Debian, we wanted to make it also available to all
[07:44] <jslarraz> Ubuntu users. In summary, the update in `-security` includes the fix for CVE-2023-38403, while the update in `-esm` include the fix for both CVE-2023-38403 and the issue published by upstream in their advisory https://downloads.es.net/pub/iperf/esnet-secadv-2023-0002.txt.asc
[07:44] -ubottu:#ubuntu-security- iperf3 before 3.14 allows peers to cause an integer overflow and heap corruption via a crafted length field. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38403>
[12:49] <sdeziel> jslarraz: OK thank you, I didn't notice there were another fixes (without CVEs) being bundled in the `-esm` version
[18:22] <ahasenack> hi security, apparmor question
[18:22] <ahasenack> I have "abi <abi/3.0>," in the first line of a "modern" apparmor profile
[18:22] <ahasenack> but bionic doesn´t  like that
[18:22] <ahasenack> Found unexpected character: '<'
[18:22] <ahasenack> is there a way to make it "compatible" with bionic, so I could use the same profile in all releases? Or I really have to remove it when building the package for bionic?
[18:22] <ahasenack> remove the line, I mean
[19:31] <georgiag> ahasenack: afaik you need to remove the abi line for bionic. jjohansen, can you confirm if there's any workaround?
[19:47] <jjohansen> ahasenack: to make it compatible we would need to cherry pick a patch back to bionic and do an SRU
[19:48] <jjohansen> its possible. All the patch does is ignore the ABI line so the profile can be parsed
[19:48] <ahasenack> jjohansen: and I can just remove the abi declaration for bionic, right? No need to add anything else?
[19:48] <ahasenack> to replace it?
[19:49] <jjohansen> ahasenack: yeah, I can just drop the ABI line
[19:49] <jjohansen> or stick a comment in front of it
[19:49] <jjohansen> #
[19:51] <ahasenack> will the comment make it be ignored where the abi statement actually means something?
[19:51] <ahasenack> or is it like include vs #include
[19:51] <ahasenack> (where both actually include something)
[19:54] <jjohansen> it will be ignored
[19:54] <ahasenack> ok, so where abi makes sense, I should keep it
[19:54] <ahasenack> tl;dr really use two different profile files
[19:55] <jjohansen> we did think about supporting #abi like include but decided against it
[19:55] <ahasenack> agreed
[20:08] <jjohansen> well it seemed like a good idea at the time with only 5 year support time frames
[20:09] <jjohansen> and we had planned ahead far enough to drop the ignore abi parsing into 2.13
[20:09] <jjohansen> but now?
[20:10] <ahasenack> I meant the concept of using # for comments, except if they start with "include" :)
[20:10] <ahasenack> don't extend that to other exceptions like "abi" :)
[20:10] <jjohansen> yeah, its janky
[20:12] <jjohansen> no, where we are going is better conditionals and the ability to add some dummy parsing in policy
[20:12] <jjohansen> if !parser_supports(XXXX) {
[20:12] <jjohansen>    ignore rule=^.*,$
[20:12] <jjohansen> }
[20:13] <jjohansen> so that we can add some basic parsing to the base includes on how to ignore rule changes
[20:14] <jjohansen> it will start simple, but we need it, so we can keep policy unified
[20:14] <jjohansen> I would SRU that if I could, but the changes necessary to make the conditionals work, is too much
[20:15] <jjohansen> well maybe
[20:15] <jjohansen> we need to do something with these longer support windows
[20:15] <jjohansen> its something we will have to look at when it lands
[20:18] <ahasenack> these conditionals look like a big change
[20:18] <jjohansen> well, conditionals are actually already supported, but they are uhmm limited
[20:19] <jjohansen> so the base
[20:19] <jjohansen> if ... { }
[20:19] <ahasenack> in bionic?
[20:19] <jjohansen> is already in bionic
[20:20] <ahasenack> I still have to try to load this profile I'm working on on xenial
[20:20] <ahasenack> currently having problems launching a xenial vm
[20:20] <jjohansen> actually they are in lucid
[20:21] <ahasenack> found something funny in bionic's python3.6 because of this profile. It was denying /sbin/ldconfig when uuid was imported
[20:21] <ahasenack> and I was like huh?
[20:21] <ahasenack> so yeah, in bionic, python3 -c "import uuid" triggers ldconfig :)
[20:22] <ahasenack> would love a "if bionic" conditional :)
[20:25] <jjohansen> it exists, you can use it in the rules blocks of profiles but not with variables
[20:25] <jjohansen> if $var {
[20:25] <jjohansen> }
[20:25] <jjohansen> $var is a boolean var you define it in the preamble section like other variables
[20:25] <jjohansen> $var=false
[20:25] <jjohansen> $var=true
[20:26] <ahasenack> hm
[20:26] <ahasenack> so one way would be to generate this profile dynamically in postinst perhaps, detecting where I am, and setting var accordingly
[20:26] <ahasenack> is what you mean?
[20:27] <ahasenack> I don't suppose that var can be set dynamically based on conditions in the environment
[20:27] <jjohansen> the conditionals are capable of a bit more, but atm they can't be used in the preamble section, so not with the abi rule, around var definitions, ...
[20:28] <ahasenack> do I *need* the abi rule in later apparmor? Like focal+ all the way up to NN?
[20:28] <jjohansen> so unfortunately it won't work for abi rules, but you can use it for other rules
[20:28] <jjohansen> no its value can't be dynamic based on environment, what the parser supports, or what the kernel supports
[20:28] <jjohansen> we want to fix all that
[20:29] <jjohansen> yes, you will need the abi rule in future apparmor
[20:29] <ahasenack> ok
[20:30] <jjohansen> it is what declares the set of features the profile was built around, so adding new features in the kernel doesn't break applications with policy that hasn't been updated yet