19:00:02 #startmeeting FESCO (2022-01-03) 19:00:02 Meeting started Mon Jan 3 19:00:02 2022 UTC. 19:00:02 This meeting is logged and archived in a public location. 19:00:02 The chair is zbyszek_. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 19:00:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:02 The meeting name has been set to 'fesco_(2022-01-03)' 19:00:02 #meetingname fesco 19:00:02 The meeting name has been set to 'fesco' 19:00:02 #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mboddu, tstellar, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 19:00:02 #topic init process 19:00:02 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mboddu mhroncok nirik sgallagh tstellar zbyszek zbyszek_ 19:00:12 .hello2 19:00:13 zbyszek_: Sorry, but user 'zbyszek_' does not exist 19:00:28 .hello churchyard 19:00:29 mhroncok: churchyard 'Miro Hrončok' 19:00:33 .hello zbyszek 19:00:34 zbyszek_: zbyszek 'Zbigniew Jędrzejewski-Szmek' 19:00:39 .hello tstellar 19:00:40 tstellar: tstellar 'Tom Stellard' 19:01:14 .hello2 19:01:15 decathorpe: decathorpe 'Fabio Valentini' 19:02:50 Just four of us? 19:02:53 seems so 19:03:38 hey 19:03:40 .hello ngompa 19:03:41 Eighth_Doctor: ngompa 'Neal Gompa' 19:03:52 So that's quorum, let's start. 19:03:59 #topic meeting time 19:04:21 not sure if we can determine the time with just 5 of us 19:04:29 but curious to see the results 19:04:40 https://whenisgood.net/fesco-2021-december/results/h2xch99 are the results so far 19:05:14 that's better than last time? 19:05:19 and the results are in UTC, correct? 19:05:31 UTC, yes. 19:05:47 better, but only 6 people incl. bcotton have responded 19:05:49 decathorpe: only six "votes" so far. I assume we'll go down to zero slots very quickyl. 19:06:20 Eighth_Doctor: please fill it out. 19:06:39 Anyway, we can't decide with just 5 of us, so let's move to the next topic. 19:06:52 #topic #2711 F36 Change: Enable fs-verity in RPM 19:06:52 .fesco 2711 19:06:54 zbyszek: Issue #2711: F36 Change: Enable fs-verity in RPM - fesco - Pagure.io - https://pagure.io/fesco/issue/2711 19:07:11 I'm going to need to drop after 30 minutes today (still on holiday). 19:09:17 hi (not sure if I could talk in this meeting) 19:09:24 robertosassu: you can 19:09:28 robertosassu: hi, thanks for joining. 19:09:37 hi everyone 19:09:54 * mhroncok has not yet checked the discussion on the list after the holidays 19:10:07 I´m working on the PGP keys/signatures patch set 19:10:24 which would help both this feature and DIGLIM 19:11:36 robertosassu: can you say a bit how the PGP sigs could be used with fs-verity? 19:11:48 (per file pgp signatures?) 19:11:59 yes 19:12:13 I understood there is already support for signatures in rpm for fsverity 19:12:21 but in PKCS#7 format 19:13:01 I don´t remember now the data structure, but we would need to differentiate the two types of signatures 19:13:19 the PGP verification will be very similar to the PKCS#7 one 19:13:36 I´m introducing similar functions, so that we just need a switch() 19:14:12 the idea would be to sign the same data structure 19:14:31 except that for PGP, rpm would use its own key, passed likely by the build service 19:15:10 it should be a small change in the rpm source code 19:15:33 robertosassu: thanks. This could be useful. 19:15:53 and at the same time, we could do IMA appraisal of RPM headers 19:16:08 with the existing Fedora keys 19:16:27 I will mention both use cases in the patch set 19:17:10 My biggest problem with both fs-verity and your proposal is that I don't see the "big picture" of how this is all supposed to work together. 19:17:38 ok 19:17:57 actually the two features would work in a different way 19:18:00 I know that the parts that are being proposed now are building blocks for future more complicated schemes 19:18:19 this feature proposes to add signatures in the RPM headers 19:18:46 This is OK, in particular when we are talking about adding features that have no significant cost when not actively used, 19:19:08 but starts being problematic when we're talking about adding something that'll be actively supported by the distro. 19:19:31 ok, so enforcement with this feature will be done by fsverity itself, or IMA (also IPE, not yet accepted) 19:19:51 the rpm plugin installs signatures for each file 19:20:07 taken from the RPM headers 19:20:45 (I am not sure this gets us anywhere here) 19:21:12 I think we should continue the discussion on the mailing list… 19:21:49 yes, probably emails would be easier 19:21:59 I'm not sure the mailing list discussion is very productive at the moment :( 19:22:00 but otherwise, I agree 19:22:32 complex security features like this seem to be very poorly understood and there's a lot of conflating with other concepts 19:23:02 I think we can assume that this all material for F37… Making changes to multiple low-level components within a months seems unrealistic. 19:23:03 only reason I understand it well is because I've gotten some grounding by folks working on fsverity in Fedora for the past year or so 19:23:33 I think it's reasonable to get the infra and userspace stuff shipped in F36 19:24:07 but the kernel part is doomed, as I don't think the patches were proposed for Linux 5.17 19:24:31 no, at least for DIGLIM there is no immediate plan of acceptance 19:24:52 unless that happens and it gets accepted by the relevant subsystem maintainer upstream, it's unlikely to be enabled for F36, and that would push it to F37 19:25:43 given that DIGLIM is mostly self-contained, there would be a chance to ship it with Fedora even if it is not accepted by upstream? 19:25:53 robertosassu: yeah, getting the kernel patches accepted is the most important part. 19:26:00 No, I don't think this is likely. 19:26:23 could the feature be accepted before the patches are accepted? 19:26:30 maybe it would help with the acceptance 19:26:45 in upstream 19:26:52 right, and upstream acceptance is mandatory for Fedora features requiring kernel enablement 19:27:00 The feature could be accepted, if/when we know that the kernel parts are on their way. 19:27:11 (we will loose quorum in 3 minutes) 19:27:13 ok 19:27:21 thanks for the explanation 19:27:27 Yeah, let's continue this on the mailing list. 19:27:37 robertosassu: thanks for coming 19:27:39 #topic #2713 F36 Change: Make Rescue Mode Work With Locked Root 19:27:40 .fesco 2713 19:27:41 zbyszek: Issue #2713: F36 Change: Make Rescue Mode Work With Locked Root - fesco - Pagure.io - https://pagure.io/fesco/issue/2713 19:27:42 welcome 19:28:04 bye 19:28:34 So… I commented on the ticket. Any other opinions? 19:28:56 robertosassu: we can do conditional acceptance 19:29:03 we've done it for kernel features before 19:29:23 not toher opinions by me yet, sorry 19:29:28 *no other 19:30:04 I think if it's not okay for normal fedora, we should remove it from FCOS too 19:30:29 from a security perspective, there is no functional difference between FCOS and Fedora 19:30:45 zbyszek: I think you're probably the best informed person wrt/ this topic, so I agree with you ;) 19:31:16 zbyszek: my opinion is that I'll go with whatever we do if we consistently apply it 19:31:27 if we don't like this solution, then we need to rip it out of FCOS too 19:31:34 because it's already there 19:31:39 FCOS: I agree. 19:31:47 *Eighth_Doctor 19:32:08 the whole reason this change was proposed was that we discovered it was done in FCOS and everyone seemed fine with it 19:32:27 but if we're not fine with it, then we need to fix that 19:32:58 Eighth_Doctor: right. 19:33:49 I need to drop now. 19:33:51 OK, so… do we want to vote on this now? (I'd prefer not, and wait for more votes in the ticket.) 19:34:03 tstellar: ack, see you next week. 19:34:28 I don't care one way or another 19:34:58 we can no longer vote anyway 19:35:04 Yeah, let's wrap this up. 19:35:23 I'll skip the next topic, since we can't vote anyway. 19:35:29 #topic Next week's chair 19:35:39 I wnated to talk about tlp a bit 19:35:43 even without voting 19:35:47 #undo 19:35:47 Removing item from minutes: 19:36:06 #topic TLP 19:36:16 .fesco 2725 19:36:17 zbyszek: Issue #2725: tlp package deliberately breaks power-profiles-daemon package - fesco - Pagure.io - https://pagure.io/fesco/issue/2725 19:36:24 yeah this seems obviously against the rules :/ 19:36:34 this package is very against the rules :( 19:36:57 ok, it seems it is, but how is this urgent? 19:37:09 I mean, it is this way for months, apparently 19:37:25 it's not installed by default, is it? 19:37:26 so now they come to fesco and we need to decide it via fast track? 19:37:52 Fabio Valentini (decathorpe): it's not installed by default, but the power-profiles-daemon mask is new 19:38:01 that's how the issue was detected in the first place 19:38:26 https://src.fedoraproject.org/rpms/tlp/c/4432f18ccc1e21f82afb18eefc11ebdbb2f5d033 19:38:59 it's also calling `systemctl enable`, which we don't allow either 19:39:40 I mean, should we strive to initiate a discussion between the reporters and the maintainrs? 19:40:37 I agree that fast-track seems unnecessary, if just uninstalling the package is a viable workaround. 19:40:45 maybe, though hadess apparently tried 19:43:06 apparently they did, but I think we should give them a chance to respond to the ticket 19:43:18 honestly, I think this should be discussed on the devel list instead of fesco 19:43:34 and also, having Plasma crash because of this is pretty bad 19:43:47 I don't know if the same problem would also happen with GNOME 19:44:06 (I kinda don't want to find out on my computers, I like having working power management) 19:44:20 Eighth_Doctor: so I think Plasma needs to be fixed independently of the changes in tlp. 19:44:37 It must not crash just because an unrelated dbus service is not active. 19:45:03 well, powerprofilesctl is what causes it to come down 19:45:05 but sure 19:45:40 Also powerprofilesctl, a triple backtrace because a service is not active. It needs to be fixed to print a single-line error message. 19:46:12 fundamentally, this issue was only discovered last month after a bunch of triaging on RHBZ 19:46:22 s/triaging/troubleshooting/ 19:48:01 Hmm, 'powerprofilesctl foobar' just … returns 0. 19:48:36 Also 'powerprofilesctl -h'. 19:49:33 Anyway, let's move on. Eighth_Doctor: would it be OK to take down the fast-track designation? 19:49:44 sure 19:49:54 thanks 19:50:04 I would personally want this taken care of quickly, because I think hadess is going to go nuclear if we don't 19:50:18 and I'd rather not have him go nuclear on us 19:50:34 that should not be our motivation, should it? 19:50:57 That would not be power-conserving, contrary to the goals of both power-profiles-daemon and tlp ;) 19:51:50 #info we'll drop fast-track for now 19:51:55 #topic Next week's chair 19:51:57 mhroncok: well I'd like this fixed for Plasma users, but that's _my_ primary motivation 19:52:07 understood 19:52:13 Volunteers? 19:52:27 I have an important hink next day morning, so I'd rather not 19:52:33 but technically, I should be available 19:52:43 s/hink/thing/ 19:52:55 * mhroncok makes multiple typos in single words :( 19:53:23 I'm on-call next week at work, so I'd rather not 19:53:48 I'm not sure if decathorpe is still with us, or just awfully quiet 19:54:15 #action zbyszek will chair next meeting 19:54:15 #topic Open Floor 19:54:26 zbyszek: thanks 19:55:10 I assume that if y'all will get bored with me as chair, somebody will volunteer :) 19:55:22 I hope there's nothing for open floor. I'll close in a minute. 19:55:56 zbyszek++ 19:55:56 mhroncok: Karma for zbyszek changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:56:20 #endmeeting