18:03:35 <Eighth_Doctor> #startmeeting FESCO (2022-03-01) 18:03:35 <zodbot> Meeting started Tue Mar 1 18:03:35 2022 UTC. 18:03:35 <zodbot> This meeting is logged and archived in a public location. 18:03:35 <zodbot> The chair is Eighth_Doctor. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:03:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:03:35 <zodbot> The meeting name has been set to 'fesco_(2022-03-01)' 18:03:47 <Eighth_Doctor> #meetingname fesco 18:03:47 <zodbot> The meeting name has been set to 'fesco' 18:03:54 <Eighth_Doctor> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mboddu, tstellar, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 18:03:54 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mboddu mhroncok nirik sgallagh tstellar zbyszek 18:03:58 <nirik> morning 18:04:00 <zbyszek> .hello2 18:04:01 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl> 18:04:15 <Eighth_Doctor> .hello ngompa 18:04:16 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com> 18:04:16 <tstellar> .hello tstellar 18:04:19 <zodbot> tstellar: tstellar 'Tom Stellard' <tstellar@redhat.com> 18:04:23 <mhroncok> .hello churchyard 18:04:24 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com> 18:04:45 <nirik> .hello kevin 18:04:46 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com> 18:05:24 <Eighth_Doctor> #topic init process 18:05:59 <Eighth_Doctor> so we have a couple of things 18:06:09 <Eighth_Doctor> one of them is Ben Cotton (he/him)'s favorite item... 18:06:26 <Eighth_Doctor> #topic #2764 F36 incomplete changes: 100% complete deadline 18:06:30 <bcotton> .hello2 18:06:31 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com> 18:06:31 <Eighth_Doctor> .fesco 2764 18:06:37 <zodbot> Eighth_Doctor: Issue #2764: F36 incomplete changes: 100% complete deadline - fesco - Pagure.io - https://pagure.io/fesco/issue/2764 18:07:43 <Eighth_Doctor> what's left on the table? 18:08:15 <nirik> shall we do em one by one? 18:08:53 <bcotton> so a couple of them have been updated. let me update the issue text real quick 18:08:54 <nirik> I guess left is dnstls, llvm14, java17, dnf recommends, glibc32 and no ifcfg 18:09:13 <mhroncok> dnf recommends is ON_QA bt was not edited out 18:09:36 <zbyszek> Yeah, dnf recommends seems to be good, a workaround is in place. 18:10:07 <zbyszek> dnfovertls is the first on the list: there's some issues open, and it's on my todo list for this week. 18:10:22 <zbyszek> I don't have more information right now. 18:11:13 <bcotton> zbyszek: we're a week past the contigency deadline on that one. does it seem likely to be ready? 18:11:17 <nirik> is it just bugfixing? or the issues are implemeting it? 18:11:32 <bcotton> in an ideal world, we're producing an RC a week from now 18:11:37 <zbyszek> Just bugfixes. 18:12:13 <sgallagh> Sorry I'm late; didn't get the notification :-( 18:12:14 <nirik> I'd say move it to ON_QA then... 18:12:35 <zbyszek> nirik: ack. 18:12:39 <Eighth_Doctor> the nm ifcfg change should be straightforward to implement, I think? 18:12:56 <Eighth_Doctor> we already got cloud-init ported to use NM directly now, so there's no blockers I can think of 18:13:46 <mhroncok> however, we should not be implementing the changes at this point 18:14:17 <Eighth_Doctor> it looks like there's an MR on upstream NM for the packaging? 18:14:26 <Eighth_Doctor> wait, why is it there instead of in src.fp.o? 18:14:32 <mhroncok> LLVM 14 does not appear to be in rawhide, nor in dist git -- tstellar any news there? 18:14:55 <tstellar> mhroncok: We're doing builds release candidate builds in COPR and waiting for the upstream final release to do builds in koji. 18:15:36 <mhroncok> and the listed deadline is final freeze 18:15:42 <mhroncok> so we are on track I guess 18:15:54 <mhroncok> the Java thing was done, wasn't it? 18:15:59 <Eighth_Doctor> yes 18:16:08 <Eighth_Doctor> that switchover happened and was merged a few weeks ago, I think? 18:16:41 <mhroncok> https://bugzilla.redhat.com/show_bug.cgi?id=2024265#c9 indicates it indeed was 18:17:49 <nirik> so sounds like glibc32 and no ifcfg are in danger here? 18:17:50 <Eighth_Doctor> I'd say it probably just needs to be set to ON_QA then 18:19:13 <mhroncok> glibc32 I'd defer (again) 18:19:15 <zbyszek> $ javac --version 18:19:15 <zbyszek> javac 17.0.2 18:19:41 <mhroncok> ifcfg I'd defer as well, if the changes are not at least committed at this point 18:19:42 <Eighth_Doctor> I'm inclined to give the NM folks a bit of leniency and reach out to them this week and get it sorted out 18:19:51 <zbyszek> So I think it's indeed the default now. There's a lot of FTBFS bugs, but maybe that's OK unless we need to rebuild those packages for other reasons. 18:19:57 <mhroncok> (but I won't fight you on that) 18:20:13 <Eighth_Doctor> especially since we went through a bunch of work to remove the remaining ifcfg-rh deps in default setups 18:20:24 <Eighth_Doctor> that stuff already landed last week 18:21:31 <Eighth_Doctor> since the ifcfg-rh plugin isn't used by default on new installs anyway, the risk is much lower 18:21:35 <nirik> I'd be ok with giving a few more days... 18:21:50 <nirik> but I wouldn't want it holding up RC's 18:21:56 <Eighth_Doctor> for sure 18:22:08 <mhroncok> they would need to requesta freeze exception and at that point I assume that's up on qa if they'll accept it 18:22:11 <Eighth_Doctor> I'll reach out to the NM folks and see if I can move things along today or tomorrow 18:22:19 <mhroncok> I'd rtaher not land that after beta 18:22:25 <Eighth_Doctor> I agree 18:22:25 <zbyszek> Can we set a deadline, this Friday, for the split to go in? So that people can start testing it on the weekend? 18:22:31 <Eighth_Doctor> yeah 18:22:35 <Eighth_Doctor> I'm fine with that 18:22:47 <mhroncok> I'd say the deadline is make it to beta 18:23:08 <mhroncok> it dosn't really matter if they do it today if they won't get qack 18:23:32 <Eighth_Doctor> works for me 18:23:41 <Eighth_Doctor> I can reach out to NM folks and get it done asap 18:24:20 <mhroncok> should we summarize? 18:24:56 <Eighth_Doctor> yeah 18:25:19 <mhroncok> I can do that 18:25:26 <Eighth_Doctor> 👍️ 18:26:18 <zbyszek> 👍️ 18:26:25 <mhroncok> DNS over TLS - set ON_QA... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/52c469461e94f50053ec1408579cc0f82de7d4e8) 18:26:41 <mhroncok> sounds good? 18:26:42 <Eighth_Doctor> mhroncok: yup 18:26:43 <Eighth_Doctor> +1 18:26:49 <zbyszek> yp 18:26:51 <zbyszek> yup 18:27:19 <zbyszek> +1 18:27:19 <nirik> +1 18:27:51 <mhroncok> tstellar: ? 18:28:24 <sgallagh> +1 18:28:34 <mhroncok> oh hi 18:28:38 <mhroncok> #agreed (+5,0,-0) DNS over TLS - set ON_QA; LLVM 14 - is on track; java-17-openjdk as system JDK in F36 - set ON_QA; glibc32 build adjustments - defer to f37; No ifcfg by default - OK if it makes the beta release, defer to f37 otherwise 18:29:11 <sgallagh> I said hello above, but it probably got lost in the noise :) 18:29:23 <mhroncok> yeah, I've missed you 18:29:31 <sgallagh> I missed you too ;-) 18:30:01 <mhroncok> :) 18:30:02 <Eighth_Doctor> we lurve you Stephen Gallagher :) 18:30:05 <Eighth_Doctor> ❤️ 18:30:41 <Eighth_Doctor> anyway... now onto the next (and last) topic... 18:31:09 <Eighth_Doctor> #topic #2766 Change proposal: Make pkexec and pkla-compat optional 18:31:18 <Eighth_Doctor> .fesco 2766 18:31:19 <zodbot> Eighth_Doctor: Issue #2766: Change proposal: Make pkexec and pkla-compat optional - fesco - Pagure.io - https://pagure.io/fesco/issue/2766 18:31:42 <Eighth_Doctor> so I'm pretty much now in the camp that we should reject this Change as it is 18:32:00 <mhroncok> I haven't got time to investigate or to read all the discussion yet, sorry 18:32:31 <Eighth_Doctor> has anyone else had a chance to look over it? 18:33:40 <zbyszek> I agree with mitr: leaving pkexec out is OK, but splitting out polkit-pkla-compat is risky and doesn't have much benefit. 18:33:46 <sgallagh> I did, briefly. 18:34:06 <sgallagh> I was just about to type exactly what zbyszek just wrote. 18:34:30 <tstellar> zbyszek: Is it still risky if it's Required by polkit instead of Recommends? 18:35:20 <Eighth_Doctor> it wouldn't be, but it would also be pointless 18:35:40 <zbyszek> tstellar: the "not much benefit" part is bigger than the "risky". Maybe even "risky" is not the right word. "Encourages-people-to-use-javascript" is the phrase I was looking for. 18:35:54 <Eighth_Doctor> polkit-pkla-compat requires polkit, and polkit requiring it just means we added more metadata for no change on disk 18:35:55 <zbyszek> Also what Eighth_Doctor said. 18:36:02 <nirik> do we have a sense of how many packages actually should depend on pkexec? 18:36:22 <zbyszek> nirik: anything that provides policy files 18:36:30 <Eighth_Doctor> it's pretty pervasive in GNOME and Plasma 18:36:45 <salimma> late to chime in, but even if polkit still requires it, that means we can start adding dependencies on pkexec now right? 18:36:51 <salimma> (if pkexec is split out) 18:37:00 <Eighth_Doctor> I only know of one case we deliberately switched away and that's in Calamares because the Polkit maintainer refused to expose the Qt theme variable 18:37:01 <tstellar> zbyszek: If we agree that eventually we want to remove these packages (don't know if we do), then splitting and moving to requires would be a good first step. It would give time to update other packages without breaking anything. 18:37:16 <zbyszek> tstellar: no, removing is not an option, and not a goal. 18:37:24 <Eighth_Doctor> I actually think kdesu and gtksu are worse than pkexec, tbh 18:37:24 <salimma> I guess we can also make those packages req: /usr/bin/pkexec and not change the packaging yet 18:37:29 <nirik> 29 packages it looks like 18:37:38 <tstellar> zbyszek: ok 18:38:11 <zbyszek> I.e. you need *some* mechanism to escalate privileges, in particular from graphical sessions, and polkit is *the* way to do this. 18:39:27 <zbyszek> Proposal: approve the split of pkexec out, but not the polkit-pkla-compat part 18:40:03 <sgallagh> +1 18:40:23 <nirik> I am not sure it's worth it... 18:40:47 <Eighth_Doctor> I don't think it's worth it 18:40:49 <zbyszek> (I guess that if Timothée and Jan still want to do the other part, we can discuss it separately. The two parts are logically seperate and independent.) 18:40:51 <Eighth_Doctor> either 18:40:59 <nirik> so this will help the subset of users who want polkit installed, but not pkexec? thats going to be very very small I would think. 18:41:33 <tstellar> nirik: isn't it the opposite? It would help users that want pkexec but not polkit. 18:41:35 <Eighth_Doctor> in practice, it's basically zero 18:41:45 <Eighth_Doctor> you can't have pkexec without polkit 18:42:09 <Eighth_Doctor> pkexec allows you to use polkit to do privileged execution filtered through polkit rules 18:43:11 <mhroncok> if we are to significantly change the scope of the proposal in either way, I prefer to do it asynchronously, and give a change to the change onwers and others to contribute to that discussion 18:43:14 <zbyszek> Well, pkexec is suid, and even though it's tiny, you might not want to have it installed if you're only using polkit via dbus. 18:43:26 <zbyszek> mhroncok: OK 18:43:31 <nirik> tstellar: pkexec needs polkit... The orig idea for this was to split pkexec (suid root) out so people could remove it, but in practice thats really hard to do IMHO 18:44:22 <nirik> hard in the sense that so many things depend on pkexec (like gvfs)... but I guess it would help the server case perhaps? 18:44:34 <tstellar> nirik: OK. 18:44:58 * Eighth_Doctor shrugs 18:45:52 <nirik> so, how about reject for now and ask them to provide more cases where it's usefull/desired? 18:46:20 <Eighth_Doctor> I'd be cool with that 18:46:49 <nirik> or just punt and ask them to revise? 18:47:05 <zbyszek> +1 for punt and … 18:47:16 <Eighth_Doctor> it's an F37 change, right? 18:47:19 <Eighth_Doctor> so we have time 18:48:41 <Eighth_Doctor> so we can do either, I'm fine with that 18:51:39 <Eighth_Doctor> Proposal: Punt this back to the Change authors to elaborate on the cases where it makes sense to implement splitting out pkexec. Splitting out polkit-pkla-compat is undesirable for security reasons and thus is rejected. 18:52:14 <tstellar> +1 18:52:15 <zbyszek> Hmm, if we're punting, I'd just let Change owners elaborate on both parts. 18:52:36 <zbyszek> I mean: we're asking them to elaborate, but rejecting part of the proposal already. 18:52:41 <Eighth_Doctor> I'd rather give a firm no on the second 18:52:49 <Eighth_Doctor> it's very clear from upstream and discussion that it's a bad idea 18:53:00 <zbyszek> Eighth_Doctor: I don't think it's clear at all. 18:53:52 <Eighth_Doctor> https://pagure.io/fesco/issue/2766#comment-783367 18:54:08 <Eighth_Doctor> that comment is a pretty ringing endorsement for "don't split it out" 18:54:53 <zbyszek> It's an endoresement for not splitting it out. But it's not saying "undesirable for security reasons". 18:54:58 <zbyszek> It's much more nuanced than that. 18:55:44 <Eighth_Doctor> > I would be 100% opposed to removing polkit-pkla-compat on upgrades; silently opening up restrictive security configuration is just not worth it IMO. 18:55:54 <zbyszek> ... Because the js mechanism remains in place. If we were deciding between the two mechanisms, things would be very very different. But sadly we're not. 18:56:14 <Eighth_Doctor> right, but the rules are implemented in mutually exclusive ways 18:56:19 <Eighth_Doctor> stuff either ships pkla or js 18:56:35 <zbyszek> Yeah, and the proposal explicitly states that on upgrades, pkla-compat would be preserved. 18:56:43 <Eighth_Doctor> not having both means polkit fails open in one scenario or another 18:56:53 <Eighth_Doctor> zbyszek: but having it weak installed is a _horrible_ idea 18:57:00 <Eighth_Doctor> because if someone removes it, it won't come back, ever 18:57:13 <Eighth_Doctor> because the changes in DNF means it never comes back and all that fails open 18:57:31 <Eighth_Doctor> if someone does a so-called "minimal install" from the netinstall, similar consequences 18:57:41 <Eighth_Doctor> it's basically a bad idea across all dimensions 18:58:30 <Eighth_Doctor> if it were purely up to me, I'd honestly flat out reject this whole Change 18:58:30 <zbyszek> Eighth_Doctor: so this could in theory cause an issue, but I think that it'd be very very contrived. You'd need a permissive policy in js, that is then mitigated by pkla, *and* remove the package. 18:58:38 <Eighth_Doctor> it's security theater that actually is fairly harmful 18:59:02 <Eighth_Doctor> zbyszek: Polkit fails open by default, not closed, you need a rule to block by default first 18:59:05 <Eighth_Doctor> nobody has that 18:59:56 <zbyszek> Hmm, so maybe I misunderstood how the rules combine. I'll check before the next vote :]]] 18:59:57 <sgallagh> I don't think we actually need to debate this here. 19:00:14 <sgallagh> We all agree that this is not ready for F36, so let's leave it to the experts to solve it for F37+ 19:01:44 <Eighth_Doctor> Stephen Gallagher: +1 19:01:53 <zbyszek> sgallagh: It's targeted at F37. 19:02:18 <sgallagh> That should read as “F37 or later” 19:03:31 <Eighth_Doctor> does someone want to wordsmith a proposal? 19:03:53 <mhroncok> no proposal is fine as well BTW :) 19:04:27 <Eighth_Doctor> well, no proposal means... what? we do this again next week? 19:04:46 <mhroncok> that lead snowehere, ok .) 19:04:46 <nirik> but hopefully with more info from proposal owners? 19:05:10 <bcotton> the meetings will continue until proposals improve? 19:05:15 <mhroncok> :) 19:05:17 <Eighth_Doctor> :D 19:05:44 <Eighth_Doctor> speaking of which... this is long overdue 19:06:16 <Eighth_Doctor> Proposal: Punt this to next week 19:07:38 <zbyszek> +1 19:07:41 <nirik> +1 19:07:51 <mhroncok> +1 19:08:51 <Eighth_Doctor> +1 19:11:16 <Eighth_Doctor> #agree This is punted until next week (+5, 0, -0) 19:11:28 <Eighth_Doctor> phew, now we're done with this, so... 19:11:29 <Eighth_Doctor> #topic Next week's chair 19:11:34 <Eighth_Doctor> who wants to do this? 19:12:19 <zbyszek> I can. 19:12:23 <sgallagh> I would prefer not to, but if no one else is going to volunteer, I guess I will 19:12:42 <Eighth_Doctor> #action zbyszek will chair next meeting 19:12:48 <sgallagh> Thanks zbyszek :) 19:12:51 <Eighth_Doctor> #topic Open Floor 19:13:04 <Eighth_Doctor> is there anything anyone wants to bring up before I end the meeting? 19:13:29 <Eighth_Doctor> going once.... 19:13:39 <zbyszek> I can say that I upgraded to F36, and it seems very smooth. 19:13:45 <mhroncok> Conan Kudo++ 19:14:02 <zbyszek> Firefox crashes when I move the window adjacent to the screen border, but I've (mostly) learnt not to do that. 19:14:09 <mhroncok> thanks for the meeting and all the meetings that didn't happen :) 19:14:10 <Eighth_Doctor> going twice......... 19:14:25 <zbyszek> And I'm testing automatic restart because of this. It seems all fixed now. 19:14:33 <Eighth_Doctor> I've been neck-deep in debugging SDDM stuff in F36 :o 19:14:38 <Eighth_Doctor> but it's otherwise fine 19:14:59 <sgallagh> I just upgraded to F36 this morning. So far, so good 19:15:03 <zbyszek> And we have almost no upgrade conflicts. 19:15:12 <sgallagh> Just the mlocate thing 19:15:13 <Eighth_Doctor> wow 19:15:25 <Eighth_Doctor> lol yeah, but that should be fixed soonish given fast track 19:15:39 <sgallagh> ack 19:16:02 <Eighth_Doctor> well, with that lovely note, all good things must come to an end, so... 19:16:05 <Eighth_Doctor> #endmeeting