16:01:54 <geppetto> #startmeeting fpc
16:01:54 <zodbot> Meeting started Thu Jun 17 16:01:54 2021 UTC.
16:01:54 <zodbot> This meeting is logged and archived in a public location.
16:01:54 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:54 <zodbot> The meeting name has been set to 'fpc'
16:01:55 <geppetto> #meetingname fpc
16:01:55 <geppetto> #topic Roll Call
16:01:55 <zodbot> The meeting name has been set to 'fpc'
16:01:59 * limburgher here
16:02:23 <tibbs> Hey, folks.
16:02:58 <decathorpe> hello o/
16:03:00 <geppetto> #chair limburgher
16:03:00 <zodbot> Current chairs: geppetto limburgher
16:03:02 <geppetto> #chair tibbs
16:03:02 <zodbot> Current chairs: geppetto limburgher tibbs
16:03:05 <geppetto> #chair decathorpe
16:03:05 <zodbot> Current chairs: decathorpe geppetto limburgher tibbs
16:03:08 <geppetto> Hey
16:03:41 <carlwgeorge> .hello2
16:03:42 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
16:04:50 <tibbs> Supposedly my power is going to be out for a few hours today, but it was supposed to be off two hours ago and it's still on.
16:05:22 <decathorpe> tibbs: is that the famous Texas grid that can handle neither hot nor cold?
16:05:34 <tibbs> This is a scheduled repair outage.
16:05:41 <tibbs> They just picked a really dumb time to do it.
16:06:12 <decathorpe> I'm not really sure if that's better. :)
16:06:29 <geppetto> #chair carlwgeorge
16:06:29 <zodbot> Current chairs: carlwgeorge decathorpe geppetto limburgher tibbs
16:06:32 <limburgher> My guess is it's a dumb time to prevent a dumber outage. Buit IDK.
16:06:43 <limburgher> s/Buit/But/g
16:07:33 <geppetto> #topic Schedule
16:07:37 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/2WUXCXEWN46FRVRNH3ZYAOXZQE7RW7DD/
16:07:57 <geppetto> So, again … nothing really changed
16:08:07 <geppetto> we have some tickets open but they are all waiting on things.
16:08:09 <geppetto> No new tickets
16:08:27 <geppetto> I'll be OOO again next week
16:08:29 <tibbs> I know there were some.
16:08:54 <geppetto> tibbs: something you wanted to discuss?
16:09:12 <tibbs> I just saw a couple of requests for static UID allocation.
16:09:26 <tibbs> And there was that exception request for the compiler flags thing.
16:10:17 <tibbs> One of the UID ones concerned me, I wonder i the argument used couldn't be used to justify every UID being made static.
16:10:36 <decathorpe> I think you mean fpc 1075, 1076, and 1078?
16:11:21 <geppetto> .fpc 1075
16:11:22 <zodbot> geppetto: Issue #1075: Requesting guidelines exception to drop -Wp,-D_GLIBCXX_ASSERTIONS from mame package - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1075
16:11:23 <geppetto> .fpc 1076
16:11:24 <zodbot> geppetto: Issue #1076: Requesting a static UID/GID for sddm for Fedora Kinoite - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1076
16:11:27 <geppetto> .fpc 1078
16:11:28 <zodbot> geppetto: Issue #1078: Allocation of gids for "hardware access groups" - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1078
16:11:58 <tibbs> I think the final comment in 1075 is reasonable, but I don't know the best way to get something to happen.
16:12:29 <tibbs> It's the usual "upstream thinks Fedora is dumb for forcing these flags to be enabled, and we don't particularly care about code quality".
16:12:33 <decathorpe> though "reading one element past the end of an array is a standard practice in C++" sounds terrifying
16:12:56 <tibbs> Though that could be perceived as unfair, since I suppose they must care about something, just not what we care about.
16:12:59 <limburgher> :facepalm:
16:13:35 <tibbs> Anyway, I don't know enough to say any more, and it would be great if someone who really understands could try to work with them.  But I don't know  how to make that happen.
16:13:38 <geppetto> I think having a reference to one past an array is fine?
16:13:44 <geppetto> But reading … no.
16:14:06 <geppetto> I can see the performance thing, if it's measurable
16:14:36 <geppetto> but kind of worried about "our code is broken, but we're pretty sure it's ok"
16:15:17 <decathorpe> well, if users are aware that "do not read untrusted data with this program" ... :shrug:
16:15:45 <geppetto> it's mame … about the only thing it handles for most users is random blobs of data downloaded from the internet
16:16:01 <decathorpe> perfect! :D
16:16:12 <tibbs> What data is trusted, though?  "Do not run this code on any machine which has data you care about or which is connected to the Internet" doesn't seem like particularly useful software.
16:16:29 <tibbs> I guess it's all theoretical until someone cooks up an exploit.
16:16:59 <decathorpe> still, software security isn't really under the purview of FPC, is it?
16:17:27 <tibbs> Only tangentially.
16:17:46 <tibbs> But compiler flags are, and they are using "don't care about security" as justification for turning them off.
16:18:22 <limburgher> Couldn't they, and this is just a thought....
16:18:25 <limburgher> ...patch?
16:18:28 <geppetto> I guess throw this to GCC maintainers?
16:19:25 <decathorpe> Why not. Maybe they can clear up some of the confusion?
16:19:26 <tibbs> Jakub was pinged in the ticket, but I assume there's a better way to get someone to have a look.
16:24:20 <tibbs> Anyway, 1076 was a request for static UID/GID.  But I don't know what Fedora Kinoite is, and the argument basically says that UIDs in built ostree images are random, so anything that persists state needs a static allocation.
16:24:45 <decathorpe> Kinoite is to Fedora KDE as Silverblue is to Fedora Workstation
16:24:48 <tibbs> And that argument bothers me somehow, because, well, lots of things persist state in var.
16:25:13 <geppetto> It seems like ostree should solve that problem?
16:25:54 <geppetto> But I guess what is in ostree is somewhat constrained?
16:26:05 <geppetto> So it's not like everything can request a static uid
16:26:16 <tibbs> That's my thinking, but the other argument seems to be "well GDM gets a fixed UID, so any other display manager should get one".
16:26:30 <geppetto> to be fair … that seems fair
16:26:33 <decathorpe> I wonder. The snippet from the gdm.spec that was linked is not conditional to ostree based systems
16:27:16 <tibbs> I think gdm gets one because either someone just patched setup without asking for approval, or it was done back before anyone cared.
16:27:41 * decathorpe runs git blame
16:28:15 <limburgher> Maybe now's a good ime to revoke gdm's?
16:28:17 <decathorpe> that snippet was last changed 13 years ago.
16:28:24 <limburgher> t^
16:28:42 <tibbs> We don't usually revoke because who knows what breaks.
16:28:50 <limburgher> Fair.
16:29:13 <tibbs> But my understanding is that we still have to be restrictive in handing them out, because the space is still quite limited.
16:29:50 <tibbs> But if the argument is that anything which could be built into an ostree image and persists state in /var needs a static allocation, then... that's everything that allocates a UID.
16:30:44 <decathorpe> tibbs: base OSTree image contents are usually quite limited ... and they probably contain only very few services. but display managers need to be in there, so sddm is a better candidate than most, I think
16:31:43 <geppetto> yeh, I think I'm +1 … if gnome gets a static uid then it seems fair for kde to get one
16:31:58 <geppetto> I think it's also ok to let stuff in a base ostree image get one too, as a rule
16:32:11 <tibbs> But what defines "base"?
16:32:21 <tibbs> I thought you could build your own and do what you liked.
16:32:23 <geppetto> Saying that I'd have thought ostree might have work around this by now.
16:32:36 <geppetto> tibbs: Only stuff Fedora ships?
16:32:43 <geppetto> That seems reasonable to me
16:32:53 <decathorpe> tibbs: no ... there's only three official branches OSTree as far as I know. Workstation, Kinoite, and CoreOS
16:33:02 <tibbs> "official"
16:33:13 <tibbs> So you can't do your own thing?
16:33:23 <decathorpe> well if you do unofficial stuff you're on your own anyway
16:33:26 <tibbs> Or if you do, too bad if you run into this UID problem on your own?
16:33:38 <tibbs> That's really not how it's supposed to work.
16:33:55 <geppetto> tibbs: AIUI you layer stuff on top which doesn't use the same stuff
16:34:06 <carlwgeorge> i'm also fine with sddm getting a static uid, since gdm gets one
16:36:01 <lucab> Tim (siosm) is offline today, but the general problem is that system users without a static UID get a random one built into /etc/passwd when the OS is assembled. The random choice may be different between two runs, though, which brings issue when moving from one ostree commit to the next one.
16:36:26 <tibbs> I just can't support this without understanding how that argument doesn't apply to every single package which allocates a UID.
16:36:49 <decathorpe> tibbs: because if you install RPM packages on top of OSTree system, they're handled correctly
16:36:56 <decathorpe> this only applies to stuff that's part of the base system
16:37:12 <lucab> and yes, there are several workarounds at multiple levels, and as siosm mentioned it boils down to pinning UIDs somewhere (in spec, or in the ostree build side)
16:37:13 <tibbs> But "base system" isn't something we get to define.
16:37:39 <decathorpe> tibbs: no, but looking at the history of things, they're only getting smaller over time.
16:38:46 <decathorpe> I also wouldn't propose to give that stuff a blanket "you're getting a static UID". but sddm is a good candidate, and if gdm already has one, assigning one to sddm makes sense.
16:38:49 <lucab> indeed, it mostly affects packages in the "base system", which is a fuzzy definition depending on the specific flavor, but it's a finite smallish subset of "all Fedora packages"
16:39:02 <carlwgeorge> and not all of base, just things that need a uid and also persistent state
16:39:16 <tibbs> decathorpe: But that argument then applies to all display managers.
16:39:57 <decathorpe> how many of those are still in use on Fedora? two?
16:40:23 <decathorpe> and if somebody else comes and asks for a UID, we can always say no ...
16:40:25 <tibbs> If it's packaged, it's in use.
16:40:53 <decathorpe> on OSTree based systems? I doubt it
16:41:04 <carlwgeorge> we can allow sddm and kept the policy case by case
16:41:55 <lucab> I can'
16:42:13 <lucab> t speak for siosm, but I think the request was for a one-off expection
16:42:15 <geppetto> If one of the other major desktops have a third display manager I'm kind of fine with allocating a third uid
16:42:37 <tibbs> Everything is a one-off exception, but all of the arguments seem to apply to any number of packages.
16:42:51 <geppetto> But at least a couple reuse the gdm/kde ones
16:43:03 <lucab> I know there is work ongoing to close that ostree gap by bridging to systemd-sysusers to solve the general case, but the whole picture is not yet in place
16:43:23 <decathorpe> but there is no OSTree based system that uses a DM other than GDM or SDDM? those are the only two the argument currently applies to.
16:43:48 <tibbs> So how can you fairly accept one and deny the next one?  There has to be some consistency in decisions, and it seems the only way to be consistent here is to simply allow every one that is requested.  Which is fine, but isn't the space finite?  How much do we care?
16:45:09 <carlwgeorge> random thought that is probably flawed, but could we have all login managers share uid 42, and just say fedora doesn't allow starting more than one at a time?
16:46:39 <carlwgeorge> hmm, that would prevent installing at the same time, too, we probably don't want that
16:46:55 <geppetto> I thought about that … but I'd assume QA would be unhappy that they couldn't install a bunch at once and have them be isolated?
16:47:19 <geppetto> I'm happy with it, if the package owners are too
16:47:29 <tibbs> There are probably loads of implications of sharing UIDs that we don't want to get into, I imagine.
16:47:51 <geppetto> But while uids are limited … they aren't that limited … we can treat this like mtas over nfs and just give them all one, I think.
16:48:21 <geppetto> again, I'd like it to be better … but just giving them one seems the best option.
16:48:48 <carlwgeorge> agreed
16:48:51 <tibbs> We do have more than 200 these days, don't we?
16:49:28 <tibbs> It's kind of sad that this is still even a consideration, really.
16:50:19 <carlwgeorge> while looking at this, i noticed a typo on that page, pr submitted
16:52:08 <tibbs> Anyway, I guess there isn't any reasonable option even though I think this is a pretty big fail somewhere.
16:52:58 <decathorpe> it needs to be hard-coded somewhere, and if that's a given, why not make it consistent between all Fedora variants :shrug:
16:53:29 <limburgher> Yeah, if we have to do something suboptimal, let's do it the best way possible.
16:53:36 <tibbs> decathorpe: Again, that argument applies to any package at all
16:54:01 <geppetto> We haven't talked about 1078 much … but that also seems like a +1
16:54:21 <geppetto> Anyone objecting strongly enough to -1 either of the uid allocations?
16:54:24 <decathorpe> tibbs: I'm sorry, but I don't understand your argument at all. maybe it's the language barrier, or maybe I'm just tired.
16:54:50 <decathorpe> all three tickets can have my +1 vote, FWIW
16:54:58 <tibbs> My argument is simply that any package that allocates a UID could be built into an ostree image.
16:55:36 <tibbs> The argument that Fedora isn't doing it doesn't work because we shouldn't disadvantage anyone that isn't Fedora from building these things.
16:56:14 <decathorpe> if somebody else builds stuff, they can hardcode UIDs all they want, though?
16:57:10 <tibbs> You mean they have to patch and rebuild the packages?  That's disadvantaging anyone that isn't Fedora.  "Yeah, only we get to do that for things we want to ship" is a pretty terrible thing to say.
16:57:48 <geppetto> I kind of see what you are saying … but that's ostree's problem.
16:58:00 <tibbs> Well all of this seems to be ostree's problem.
16:58:00 * decathorpe is quiet now
16:58:16 <geppetto> They can fix ostree, or change the uid allocation with their changes … or whatever
16:58:41 <geppetto> not having what Fedora ships work is a significantly bigger goal, I think
17:00:13 <geppetto> So we all +1 for the uids, at least?
17:00:26 <tibbs> Ostree's problem becomes Fedora's problem, but "official" fedora stuff can come to us to get a fix.  And that's far from fair.  We have always tried not to do stuff like that.  It's academic until some out-group person actually asks us to solve the problem, but if it does come to that I hope we would do the right thing.
17:00:52 <geppetto> I'm not sure what we have the power to fix though
17:01:09 <geppetto> And, from experience, I know that doing out of tree stuff is far from simple
17:01:32 <geppetto> So them having to change uid allocation isn't going to be their bigger problem
17:02:51 <tibbs> Anyway, I'll +1 all three but it's going to be tough to find any argument against any request that comes up in the future.
17:03:14 <geppetto> Anyway we are at time … I'll mark the uid ones as approved
17:03:22 <limburgher> Yep
17:03:44 * geppetto realizes we were in the schedule topic this entier time … oh well
17:03:51 <geppetto> #endmeeting