19:04:11 <zbyszek> #startmeeting FESCO (2022-01-10)
19:04:11 <zodbot> Meeting started Mon Jan 10 19:04:11 2022 UTC.
19:04:11 <zodbot> This meeting is logged and archived in a public location.
19:04:11 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:04:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:04:11 <zodbot> The meeting name has been set to 'fesco_(2022-01-10)'
19:04:11 <zbyszek> #meetingname fesco
19:04:11 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mboddu, tstellar, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
19:04:11 <zbyszek> #topic init process
19:04:11 <zodbot> The meeting name has been set to 'fesco'
19:04:11 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mboddu mhroncok nirik sgallagh tstellar zbyszek
19:04:20 <mboddu> .hello mohanboddu
19:04:22 <StephenGallagher> .hello sgallagh
19:04:23 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
19:04:25 <zbyszek> .hello2
19:04:26 <zodbot> StephenGallagher: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
19:04:29 <Eighth_Doctor> .hello ngompa
19:04:31 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
19:04:34 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
19:04:35 <dcantrell> .hello2
19:04:37 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
19:04:38 <tstellar> .hello tstellar
19:04:40 <zodbot> tstellar: tstellar 'Tom Stellard' <tstellar@redhat.com>
19:04:41 <decathorpe> .hello2
19:04:42 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
19:04:46 <nirik> morning
19:05:10 <mhroncok> .hello churchyard
19:05:11 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
19:05:38 * zbyszek counts
19:06:04 <nirik> .hello kevin
19:06:05 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
19:06:14 <zbyszek> We're missing ... no we're all here.
19:06:16 <mhroncok> full house?
19:06:27 <zbyszek> So let's jump to everyone's favourite topic!
19:06:28 <StephenGallagher> Too soon
19:06:33 <zbyszek> #topic meeting time
19:06:56 * nirik guesses we have 0 overlapping times, since that always seems to happen
19:07:20 <zbyszek> #info https://whenisgood.net/fesco-2021-december/results/h2xch99
19:08:14 <zbyszek> Eighth_Doctor: any chance you could reconsider Monday or Tuesday 18:00 UTC?
19:08:17 <StephenGallagher> There you go again, Conan Kudo , always causing trouble ;-)
19:08:24 <mboddu> Haha :)
19:08:43 <Eighth_Doctor> 18:00 UTC is when the KDE SIG meeting happens (1pm US/ET)
19:09:09 <mhroncok> we are all here now
19:09:17 <nirik> can they perhaps move it ?
19:09:20 <Eighth_Doctor> since I chair that meeting, it would be a problem for me to not be there
19:09:20 <StephenGallagher> Which day?
19:09:27 <Eighth_Doctor> Mondays
19:09:30 <Eighth_Doctor> it happens right before this one :)
19:09:39 <StephenGallagher> What about Tuesday?
19:10:01 <Eighth_Doctor> that slot just opened up this week going forward
19:10:02 <Eighth_Doctor> so I guess we can do that
19:10:08 <StephenGallagher> \o/
19:10:19 <StephenGallagher> It's a New Year's miracle!
19:10:23 <Eighth_Doctor> at least until OKD WG shifts again :)
19:10:25 <mhroncok> wow
19:10:35 <nirik> impressive.
19:10:43 <nirik> 🎆
19:10:48 <zbyszek> 18:00 UTC Tuesdays it is!
19:10:52 <Eighth_Doctor> being in as many SIGs/WGs as I'm in, it's very hard to do scheduling
19:11:08 <StephenGallagher> Have you ever considered not burning yourself out?
19:11:17 <zbyszek> #agree FESCO meetings will take place on Tuesday 18:00
19:11:51 * StephenGallagher says without a trace of irony
19:11:51 <zbyszek> #topic #2711 F36 Change: Enable fs-verity in RPM
19:11:51 <zbyszek> .fesco 2711
19:11:52 <zodbot> zbyszek: Issue #2711: F36 Change: Enable fs-verity in RPM - fesco - Pagure.io - https://pagure.io/fesco/issue/2711
19:12:35 <zbyszek> FWIW, I haven't had any time to spend on this… I'm in the same spot at a week ago.
19:13:05 <nirik> I feel like these things need some kind of goal/use cases they would be actually on/used for...
19:13:28 <Eighth_Doctor> Stephen Gallagher: yes, trying to reduce really hard
19:13:29 <nirik> providing the tools is nice, but without using them, it's work we don't know does any good...
19:13:45 <mhroncok> > Are there some test runs with numbers to show before/after data for both the RPM size and installed FS usage? -- The Change owners are currently collecting this data and will be releasing it in the coming weeks.
19:13:53 <mhroncok> was this posted somewhere, or is it still TBD?
19:14:01 <nirik> I don't recall seeing it.
19:14:18 <tstellar> nirik: I agree with that.
19:14:58 <zbyszek> proposal: punt until next week?
19:15:17 <dcantrell> +1
19:15:18 <Eighth_Doctor> I poked the change proposers
19:15:59 <zbyszek> OK, we'll keep revisiting this.
19:16:06 <zbyszek> #topic #2713 F36 Change: Make Rescue Mode Work With Locked Root
19:16:06 <zbyszek> .fesco 2713
19:16:07 <zodbot> zbyszek: Issue #2713: F36 Change: Make Rescue Mode Work With Locked Root - fesco - Pagure.io - https://pagure.io/fesco/issue/2713
19:17:17 <dcantrell> I do not like this proposal.  It feels like a classic fix the symptom and not the problem type thing
19:17:28 <mhroncok> "I'm leaning towards not rushing this and delaying to F37"
19:17:31 <Eighth_Doctor> Michel Alexandre Salim, michel-slm: pretty ping
19:17:36 <mhroncok> (one of the chnage owners)
19:17:52 <mhroncok> Eighth_Doctor: salimma maybe?
19:18:08 <mhroncok> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LOISWGKNQZXN33WPDQX3QJYC7ZC77T4N/
19:18:12 <Eighth_Doctor> as one of the change owners, my feeling on it is that if we don't like it, we should remove it from everywhere it's already implemented
19:18:49 <decathorpe> zbyszek: do you have a short version of what would be required to solve this in a better way?
19:18:57 <Eighth_Doctor> the solution came from FCOS
19:19:29 <decathorpe> ngompa: I agree, if this is something we don't want, then it shouldn't be used anywhere ... but does FESCo even have "jurisdiction" over FCOS?
19:19:36 <Eighth_Doctor> yes
19:19:41 <zbyszek> decathorpe: depends on how comprehensively we want to solve it
19:19:48 <Eighth_Doctor> SIGs and WGs are underneath FESCo
19:19:51 <decathorpe> (they use so many special processes that I'm not even sure)
19:19:58 <Eighth_Doctor> yeah :/
19:20:11 <Eighth_Doctor> from a governance perspective, they answer to us
19:20:19 <Eighth_Doctor> but in practice...? 🤷‍♂️
19:20:36 <zbyszek> decathorpe: the simplest case is when the machine is booting but get stuck somewhere in early boot. We would need to adjust the pam stack and/or login binary to support logging in as other users.
19:20:57 <zbyszek> I think we should allow a configurable user group to allow, and then make wheel allowed.
19:21:07 <Eighth_Doctor> that makes sense to me
19:21:16 <zbyszek> (Or we could create a new separate group, but I don't think it's worth the trouble.)
19:21:17 <decathorpe> I mean, that should probably already solve a large part of the problem
19:21:17 <nirik> well, we give spins/labs/editions pretty wide lattitude in deciding what is right for their use case... I'm not sure this is something worth fighting over with FCOS if they feel it's in their users best interests.
19:21:48 <nirik> yeah, that approach seems much better than just allowing *
19:21:51 <Eighth_Doctor> nirik: so then by that logic we could ship the RPM, then every spin could ship it anyway, effectively bypassing us
19:22:05 <Eighth_Doctor> I'd rather not establish that as a model
19:22:06 <zbyszek> But to solve this comprehensively, we'd need to provide login also in the initramfs. This is more complicated, because we want to make sure that the password cannot be attacked offline too easily.
19:22:21 <nirik> the rpm?
19:22:24 <Eighth_Doctor> I vaguely recall seeing that implemented somewhere else before, but I don't remember where
19:22:46 <Eighth_Doctor> by pulling in /etc/passwd and /etc/shadow into the initramfs and setting up initramfs pam login
19:23:31 <Eighth_Doctor> nirik: the Change adds an rpm to systemd that gets pulled in with the dracut rescue config package
19:25:04 <zbyszek> There are at least two issues with the initrd: the initrd might "leak" and then an offline attack on the password might be possible. With argon and the other new hashing methods this is less of a problem.
19:25:41 <zbyszek> But if possible, it'd be nice to slap TPM2 encryption on top, to close this attack avenue more completely.
19:25:49 <tstellar> Sorry, I have to drop off now.
19:26:07 <zbyszek> Then there's a practical problem of how to update password in the initrd when users change their passwords.
19:26:59 <zbyszek> In the current model with dracut, we can't really regenerate initrds on demand, so we'd be stuck with the old passwords until the initrd is regenerated.
19:27:21 <mhroncok> that's not very nice
19:27:50 <zbyszek> With the new approach that we're developing with sysexts, it might be possible to store the passwords as one sysext that is shared between initrds, and then *that* could be updated fairly easily.
19:27:57 <nirik-libera> bah... internet outage here. ;(
19:28:51 <zbyszek> But some plumbing would be necessary… I think we'd be able to say something more concrete in a few months.
19:29:42 <StephenGallagher> What about systems with purely-enterprise accounts?
19:29:46 <mhroncok> let's reject the proposal as is and wait for zbyszek and co. brings in a few months?
19:30:15 <zbyszek> I wouldn't want to block other people from working on proposals.
19:30:37 <mhroncok> well, that's based on what salimma has said on devel
19:30:46 <zbyszek> StephenGallagher: I don't understand. What are "purely-enterprise accounts" ?
19:31:17 <StephenGallagher> zbyszek: Consider a system installed with no root user and user accounts provided by a FreeIPA/Active Directory domain
19:31:26 <StephenGallagher> There are no active users in /etc/passwd in that case
19:32:12 <zbyszek> StephenGallagher: ah, ok. I guess that that case falls into the first category I described above: if it boots up enough to join the domain, some group of users can be allowed to log in.
19:32:27 <StephenGallagher> (The answer "disallow disabled root in this case" is valid, but it needs to be considered)
19:32:34 <zbyszek> But if it breaks before that, only the root account can be used.
19:33:34 <StephenGallagher> Well, in that example it would need to boot enough for SSSD to start.
19:33:43 <StephenGallagher> Which is definitely post-initrd
19:33:46 <mhroncok> StephenGallagher: not having *any* local user account sounds like a problem even now, what if network needs to be configured etc.?
19:33:56 <Eighth_Doctor> can sssd even be used in initramfs?
19:34:16 <zbyszek> Eighth_Doctor: there is no difference between the initramfs and "normal" systems.
19:34:16 <dcantrell> it can, but you have to call it initramfsss
19:34:26 <StephenGallagher> dcantrell: +1
19:34:27 <zbyszek> dcantrell: nice!
19:34:37 <Eighth_Doctor> lol
19:34:48 <Eighth_Doctor> zbyszek: well, there kinda is: can we even get services to start that early?
19:34:52 <StephenGallagher> It can, but it's needlessly complex
19:35:06 <mhroncok> :D
19:35:33 <zbyszek> People have this notion that it's different, but that hasn't been true for the last few years.
19:35:34 <StephenGallagher> As I said, the answer "don't allow root to be disabled when enterprise login is enabled" is a perfectly valid one.
19:35:40 <StephenGallagher> I just want it on the record.
19:36:02 <Eighth_Doctor> then we need to force a valid root credential, right?
19:36:12 <zbyszek> Dracut initrds install systemd, and use it to start various services, and apart from the fact that the root filesystem is tmpfs not e.g. ext4, for services there really isn't any difference.
19:36:51 <StephenGallagher> Conan Kudo: What do you mean? Please define "valid" and "credential" in that sentence :)
19:36:58 <zbyszek> and "force"!
19:37:08 <Eighth_Doctor> lol
19:37:16 <Eighth_Doctor> meaning anaconda can't let people install without setting a root password
19:37:34 <StephenGallagher> Right
19:37:49 <Eighth_Doctor> that would have repercussions for Workstation too, because we don't configure enterprise login until we reboot into the installed environment
19:37:58 <Eighth_Doctor> we'd have to assume enterprise login
19:38:04 <zbyszek> Well, maybe. I'd prefer if it just recommended setting a password.
19:38:18 <zbyszek> Like it does with weak passwords: "press DONE twice".
19:38:36 <Eighth_Doctor> we could also pull a YaST and have Anaconda default to copying the user password to root
19:38:43 <dcantrell> NO
19:38:54 <Eighth_Doctor> lol
19:38:57 <dcantrell> so for the record, all those kinds of customizations are handled by install classes in anaconda
19:39:18 <dcantrell> yast does other hilarious and fun things the last time I looked at it, like letting you pick what representation format you wanted in /etc/fstab.  sure, why not
19:39:25 <StephenGallagher> Maybe I should rephrase my suggestion.
19:39:53 <StephenGallagher> Anaconda must require either a root user or a non-root administrator account if Enterprise Login is enabled.
19:39:55 <zbyszek> dcantrell: I'm all for equal representation and diversity in the fstab
19:40:28 <StephenGallagher> Not me, I'm a curmudgeon when it comes to my filesystems
19:40:44 <zbyszek> StephenGallagher: but why would we want to force this? So far this hasn't really been a problem, afaik.
19:41:19 <mhroncok> exactly
19:41:25 <mhroncok> it's not a new problem
19:41:26 <zbyszek> If it turns out that people install systems with Enterprise Login and never successfully manage to join the domain, then we want to force that.
19:41:39 <zbyszek> *we would want
19:43:01 <zbyszek> I imagine that there are for example kickstarted enterprise setups that "just work", and they might be fine without the root password. And if something goes wrong, just reimagine the machine from scratch.
19:43:12 <StephenGallagher> True enough
19:43:19 <StephenGallagher> I may be overthinking the problem
19:43:31 <StephenGallagher> In any case, I made sure it's on the table. Let's move on :)
19:44:06 <mhroncok> yes please :)
19:44:36 <zbyszek> So... to make this more constructive: maybe Neal and the other change owners and I and some other people from systemd side could have a meeting and discuss what options we have.
19:44:47 <zbyszek> I don't think we can solve this here.
19:45:30 <mhroncok> +100
19:45:34 * nirik nods
19:45:54 <StephenGallagher> agreed
19:46:17 <zbyszek> #action zbyszek to set up a meeting with Change owners to discuss alternative approaches
19:46:25 <zbyszek> #topic #2717 Blender 3.0.0 on Fedora 35
19:46:25 <zbyszek> .fesco 2717
19:46:26 <zodbot> zbyszek: Issue #2717: Blender 3.0.0 on Fedora 35 - fesco - Pagure.io - https://pagure.io/fesco/issue/2717
19:46:55 <mhroncok> not much to do here
19:47:01 <zbyszek> Agreed.
19:47:03 <mhroncok> I don'T undesrtand why this happened :(
19:47:13 <StephenGallagher> I'm rather annoyed by this, personally
19:47:23 <decathorpe> ugh, this one ... I wonder why bother with opening a Fesco ticket but then push the "push the stable" button anyway?
19:47:37 <StephenGallagher> This is literally the exact scenario for which Modularity was invented.
19:48:09 <dcantrell> StephenGallagher: heh
19:48:33 <StephenGallagher> That wasn't a joke
19:48:39 <nirik> :( yeah, asking and then just pushing it stable isnt nice.
19:48:57 <StephenGallagher> If that had been done in F36 only and then made into a module for F34/F35, everyone would have been happy.
19:49:09 <StephenGallagher> Or if Blender was distributed as a Flatpak...
19:49:25 <zbyszek> Or in a COPR
19:49:35 <StephenGallagher> Pretty much any of the tools we have except the one this packager used :-/
19:49:39 <zbyszek> Or as a compat package: blender-next :)
19:49:51 <nirik> so many choices.
19:50:12 <StephenGallagher> I'm not sure I'm annoyed enough to require an epoch-bump downgrade, but I'm close
19:50:23 <dcantrell> ugh
19:50:25 <zbyszek> Have there been complaints from users?
19:50:49 <dcantrell> on this or just in general?  :)
19:51:04 <dcantrell> (I have not specifically seen any complaints about this issue)
19:51:23 <nirik> I'd say we should admonish the maintainer to not do that kind of thing again and leave it... but I am not sure how much breakage is happening or unhappy users...
19:52:16 <dcantrell> why is this actually needed in F35?
19:52:20 <Eighth_Doctor> so far nobody screamed
19:52:22 <dcantrell> is it just to be current?
19:52:31 <StephenGallagher> dcantrell: Exactly the reasoning given
19:52:48 <mhroncok> "as the benefit will be to keep up to date with upstream."
19:52:50 <dcantrell> then I say we strike this and tell the maintainer to keep it in rawhide for now
19:53:10 <mhroncok> strike as in revert and bump epoch?
19:53:11 <nirik> dcantrell: what do you mean by 'strike this' there?
19:53:17 <decathorpe> it involved multiple soname bumps and that should be red flags for stable branches already ...
19:53:22 <mhroncok> that's breaking it twice
19:53:28 <dcantrell> this was all done in a side tag, right?
19:53:35 <mhroncok> yes
19:53:39 <mhroncok> but it is in stable
19:53:47 <mhroncok> the side tag was merged
19:53:48 <dcantrell> so can't all that just be dropped before being pushed to users?
19:53:51 <zbyszek> -1, I don't think we should force a revert unless there's ongoing breakage for users.
19:53:52 <dcantrell> oh, that part I missed
19:53:52 <StephenGallagher> Right, they merged it in without waiting for our reply
19:53:59 <mhroncok> dcantrell: it already has been pushed t users
19:54:09 <dcantrell> oh, well this is a stupid conversation then
19:54:21 <dcantrell> +1 to giving the maintainer a "stern talkin' to" to not do this again
19:54:23 <mhroncok> things liek this happen all the time,e xcept for asking fesco
19:54:26 <mhroncok> *like
19:54:29 <StephenGallagher> Like I said, I'm not quite at the point of demanding a reversion, but I'm very unhappy with this.
19:54:42 <dcantrell> stable shouldn't be for chasing upstream for the sake of chasing upstream, especially with ABI breaks
19:54:44 <mhroncok> my impression is that the maintainer read music's comment, approached fesco and assumed that's all that was needed
19:55:26 <mhroncok> if they would have not asked us, we would not even know
19:55:41 <dcantrell> though forcing a revert and epoch bump does leave a permanent mark and reminder as to what not to do (see bind and dhcp)
19:55:51 <zbyszek> StephenGallagher or nirik: could one of you maybe write a mail to luya?
19:56:13 <mhroncok> it makes me sad, especially the fact that they went ahead and *manually* pushed the update after receiving negative feedback and before waiting for our reply
19:56:21 <Eighth_Doctor> I'm pretty sure bind's epoch number is a mistake
19:56:27 <Eighth_Doctor> since that number is ridiculously high
19:56:31 <mhroncok> but I've seen provenpackagers done worse for packages they don't even maintain
19:56:33 <dcantrell> Eighth_Doctor: it has a very hilarious history
19:56:47 <dcantrell> I'm happy to share the story with you the next time we meet in person or whatever
19:56:56 <Eighth_Doctor> for sure
19:57:00 <nirik> zbyszek: sure.
19:57:05 <Eighth_Doctor> I'm curious
19:57:15 <nirik> or just update the ticket with it?
19:57:22 <dcantrell> mhronhok: a lot more should be proven before provenpackagers become provenpackagers
19:57:36 <zbyszek> I thought it'd be better to do this offline, and not in the public ticket.
19:57:41 <StephenGallagher> nirik: Thanks. I'm pretty sure I couldn't maintain a civil tone writing that.
19:57:48 <StephenGallagher> zbyszek: +1
19:57:54 <nirik> ok
19:57:57 <zbyszek> #action nirik to write a mail to the maintainer
19:58:00 * nirik adds to the todo
19:58:16 <zbyszek> OK, and now, the *second* favourite topic of everyone here!
19:58:22 <zbyszek> #topic Next week's chair
19:58:26 <dcantrell> do the packaging guidelines explain what stable updates are for?  need clarification?
19:58:35 <zbyszek> dcantrell, yeah they do quite well
19:58:48 <dcantrell> zbyszek: ahh, ok, so they are just "README encoded" then
19:58:55 <mhroncok> that's tuesday 18 UTC
19:59:20 <StephenGallagher> Are any of the US members going to be absent for the Day of Service?
19:59:21 <mhroncok> I can chair the next meeting
19:59:31 <mhroncok> StephenGallagher: that's next meeting?
19:59:38 <StephenGallagher> Oh wait.
19:59:41 <zbyszek> dcantrell: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
19:59:46 <StephenGallagher> No, because now we are meeting on Tuesdays :)
19:59:51 <StephenGallagher> That's next Monday.
19:59:58 <mhroncok> :)
20:00:11 <zbyszek> We put a lot of polish into those docs.
20:00:17 <dcantrell> zbyszek: yep, definitely looks like README encoding
20:00:49 <zbyszek> #action mhroncok will chair the next meeting (Tuesday!)
20:00:59 <zbyszek> #topic Open Floor
20:01:00 <decathorpe> tomorrow? or next ween?
20:01:02 <decathorpe> *week?
20:01:05 <mhroncok> next week
20:01:15 <decathorpe> oh good. just wanted to be sure
20:01:15 <decathorpe> :D
20:01:19 <mhroncok> who updates the calendar?
20:01:23 <mhroncok> I can update the wiki
20:01:34 <StephenGallagher> I think I can update the calendar.
20:01:36 * StephenGallagher checks
20:02:52 <StephenGallagher> Yes, I can do it
20:03:03 <zbyszek> Anything for open floor?
20:03:31 <zbyszek> If not, I'll close in a minute
20:03:53 <decathorpe> I have nothing, I am an emtpy shell
20:03:56 <mhroncok> zbyszek++
20:04:24 <zbyszek> I'm an empty shell too. It's late.
20:04:32 <zbyszek> #endmeeting