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