[07:44] 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] 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. [12:49] jslarraz: OK thank you, I didn't notice there were another fixes (without CVEs) being bundled in the `-esm` version === chris14_ is now known as chris14 [18:22] hi security, apparmor question [18:22] I have "abi ," in the first line of a "modern" apparmor profile [18:22] but bionic doesn´t like that [18:22] Found unexpected character: '<' [18:22] 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] remove the line, I mean [19:31] ahasenack: afaik you need to remove the abi line for bionic. jjohansen, can you confirm if there's any workaround? [19:47] ahasenack: to make it compatible we would need to cherry pick a patch back to bionic and do an SRU [19:48] its possible. All the patch does is ignore the ABI line so the profile can be parsed [19:48] jjohansen: and I can just remove the abi declaration for bionic, right? No need to add anything else? [19:48] to replace it? [19:49] ahasenack: yeah, I can just drop the ABI line [19:49] or stick a comment in front of it [19:49] # [19:51] will the comment make it be ignored where the abi statement actually means something? [19:51] or is it like include vs #include [19:51] (where both actually include something) [19:54] it will be ignored [19:54] ok, so where abi makes sense, I should keep it [19:54] tl;dr really use two different profile files [19:55] we did think about supporting #abi like include but decided against it [19:55] agreed [20:08] well it seemed like a good idea at the time with only 5 year support time frames [20:09] and we had planned ahead far enough to drop the ignore abi parsing into 2.13 [20:09] but now? [20:10] I meant the concept of using # for comments, except if they start with "include" :) [20:10] don't extend that to other exceptions like "abi" :) [20:10] yeah, its janky [20:12] no, where we are going is better conditionals and the ability to add some dummy parsing in policy [20:12] if !parser_supports(XXXX) { [20:12] ignore rule=^.*,$ [20:12] } [20:13] so that we can add some basic parsing to the base includes on how to ignore rule changes [20:14] it will start simple, but we need it, so we can keep policy unified [20:14] I would SRU that if I could, but the changes necessary to make the conditionals work, is too much [20:15] well maybe [20:15] we need to do something with these longer support windows [20:15] its something we will have to look at when it lands [20:18] these conditionals look like a big change [20:18] well, conditionals are actually already supported, but they are uhmm limited [20:19] so the base [20:19] if ... { } [20:19] in bionic? [20:19] is already in bionic [20:20] I still have to try to load this profile I'm working on on xenial [20:20] currently having problems launching a xenial vm [20:20] actually they are in lucid [20:21] found something funny in bionic's python3.6 because of this profile. It was denying /sbin/ldconfig when uuid was imported [20:21] and I was like huh? [20:21] so yeah, in bionic, python3 -c "import uuid" triggers ldconfig :) [20:22] would love a "if bionic" conditional :) [20:25] it exists, you can use it in the rules blocks of profiles but not with variables [20:25] if $var { [20:25] } [20:25] $var is a boolean var you define it in the preamble section like other variables [20:25] $var=false [20:25] $var=true [20:26] hm [20:26] so one way would be to generate this profile dynamically in postinst perhaps, detecting where I am, and setting var accordingly [20:26] is what you mean? [20:27] I don't suppose that var can be set dynamically based on conditions in the environment [20:27] 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] do I *need* the abi rule in later apparmor? Like focal+ all the way up to NN? [20:28] so unfortunately it won't work for abi rules, but you can use it for other rules [20:28] no its value can't be dynamic based on environment, what the parser supports, or what the kernel supports [20:28] we want to fix all that [20:29] yes, you will need the abi rule in future apparmor [20:29] ok [20:30] 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