18:01:44 <zbyszek> #startmeeting FESCO (2022-03-08) 18:01:44 <zodbot> Meeting started Tue Mar 8 18:01:44 2022 UTC. 18:01:44 <zodbot> This meeting is logged and archived in a public location. 18:01:44 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:01:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:44 <zodbot> The meeting name has been set to 'fesco_(2022-03-08)' 18:01:44 <zbyszek> #meetingname fesco 18:01:44 <zodbot> The meeting name has been set to 'fesco' 18:01:45 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mboddu, tstellar, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 18:01:45 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mboddu mhroncok nirik sgallagh tstellar zbyszek 18:01:47 <zbyszek> #topic init process 18:01:51 <zbyszek> .hello2 18:01:52 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl> 18:01:56 <dcantrell> .hello2 18:01:57 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com> 18:01:58 <mboddu> .hello mohanboddu 18:01:59 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com> 18:02:00 <nirik> morning 18:02:04 <mhroncok> .hello churchyard 18:02:04 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com> 18:02:06 <Eighth_Doctor> .hello ngompa 18:02:08 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com> 18:02:18 <zbyszek> That's quorum. 18:02:18 <sgallagh> .hello2 18:02:19 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 18:02:23 <zbyszek> quorum+1 18:02:27 <bcotton> .hello2 18:02:28 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com> 18:02:32 <tstellar_> .hello tstellar 18:02:33 <zodbot> tstellar_: tstellar 'Tom Stellard' <tstellar@redhat.com> 18:02:54 <zbyszek> Let's proceed then. 18:02:57 <zbyszek> #topic init process#topic #2766 Change proposal: Make pkexec and pkla-compat optional 18:03:00 <zbyszek> .fesco 2766 18:03:01 <zodbot> zbyszek: Issue #2766: Change proposal: Make pkexec and pkla-compat optional - fesco - Pagure.io - https://pagure.io/fesco/issue/2766 18:03:08 <zbyszek> There hasn't been any movement since last week. 18:03:25 <zbyszek> Should we punt again? 18:03:39 <dcantrell> yeah 18:03:43 <nirik> were we waiting to hear from submittors? 18:03:43 <mboddu> Yeah 18:03:59 <zbyszek> I'll reach out to them. 18:04:01 <Eighth_Doctor> yeah 18:04:02 <Eighth_Doctor> punt 18:04:07 <nirik> fine to wait then... 18:04:18 <zbyszek> #info we're waiting for more input from Change Owners. 18:04:24 <zbyszek> #topic #2768 Change proposal: Curl-minimal as default 18:04:24 <zbyszek> .fesco 2768 18:04:25 <zodbot> zbyszek: Issue #2768: Change proposal: Curl-minimal as default - fesco - Pagure.io - https://pagure.io/fesco/issue/2768 18:04:36 <zbyszek> The vote is at +1, 0, -2 18:04:52 <zbyszek> This is my change, and I'm here to answer any questions ;) 18:06:41 <mhroncok> I am not strictly against this, but I have not yet read all the feedback 18:06:45 <tstellar_> zbyszek: What sort of security threats does curl-minimal defend against? 18:06:58 <dcantrell> I don't think this adds much value, only confusion. 18:08:08 <zbyszek> tstellar_: It reduces the attack surface by reducing the number of protocols that are available for opening for example by following a link somewhere. 18:08:09 <dcantrell> If the concern is security risk for seldom used protocols, then we should just disable them in the curl package 18:08:47 <decathorpe> hi, sorry for being late o/ 18:08:47 <zbyszek> tstellar_: There *are* cases where you want to allow such protocols, but for 99% of users this is completely unnecessary and unused. 18:09:00 <tstellar_> zbyszek: Ok, so it's the case where the user doesn't know what protocol they are using. 18:09:02 <zbyszek> We don't want to disable them completely, because there are uses. 18:09:18 <zbyszek> For me personally, I care more about the minimization of dependencies. 18:09:22 <nirik> this seems like a lot of work for not too much gain really... 18:09:44 <zbyszek> I think it's a bit like telnet: we don't want to outlaw it, but pulling it into the default install in 2022 is not useful. 18:10:13 <dcantrell> if we're ok shipping these protocols in a package, then it should be fine for the main package. I don't see why we would want to create an additional curl package with some of the stuff turned off and another with everything on 18:10:17 <zbyszek> nirik: What work? The change is a few lines spread over a few packages… 18:11:22 <zbyszek> dcantrell: So you're basically saying that we should ship each and every tool in every installation, "if we are fine having it in the distro". 18:11:33 <nirik> I'm also not sure how many users know about dnf swap to change to the other version... they might just get confused that it conflicts. 18:11:42 <decathorpe> zbyszek: I wonder, which editions / spins would this even affect? I don't think that it's unlikely that for example Workstation will ship the "full" version by default anyway ... 18:12:23 <zbyszek> Hmm, so we could always try to make the message from curl better. E.g. even mention 'dnf swap … if you want the disabled protocol'. 18:12:36 <zbyszek> I don't know if that would be possible, but I assume so. 18:13:05 <dcantrell> I'm not saying that. Part of the job of a distribution is to provide a curated set of software with functionality we have enabled and made work together. If we are ok enabling seldom used protocols in a curl-full package, then we're saying it's ok to enable in the distribution. Providing another copy of the curl package with those things turned off is silly and is using packaging to work 18:13:11 <dcantrell> around what should either be a configuration option or loadable runtime plugins that can be subpackaged 18:13:19 <zbyszek> decathorpe: Why would workstation do this? I'm sure 99% of users don't care. 18:13:20 <dcantrell> I am not saying every single option in every package should be enabled 18:14:52 <decathorpe> Workstation was just an example. Do you know whether some Editions / Spins will default to curl-non-minimal? 18:15:09 <zbyszek> But security is a continuum, not a binary on/off thing. E.g. we have various tools that are useful, and even completely safe if used correctly, but we don't install them by default. 18:15:11 <tstellar_> I agree with what dcantrell is saying. It seems like it might be better to go upstream and move some of the legacy protocols into a module or something similar. That would fit much better into our packaging model. 18:15:17 <sgallagh> I think I mostly agree with dcantrell here. 18:16:01 <mboddu> Same here, I agree with dcantrell, it seems to add confusion and dont see the benefit 18:16:01 <zbyszek> But moving the protocols to a module wouldn't actually change much: you still need to decide which modules to install by default. 18:16:22 <sgallagh> What I'd prefer, I think is that we just turn those features off in the main `curl` package and then offer subpackages that enable specific protocols. 18:16:32 <sgallagh> So if someone REALLY needs them, they can install them explicitly. 18:17:03 <tstellar_> zbyszek: You could have a weak dependency on the module, so people who want smaller installs could have that. 18:17:05 <mhroncok> the swap nature of the packages also breaks standard dnf UX, doesn't it? if majority of the packages require curl(-minimal) it is likely to be installed on my system, when i later dnf install somethign that requires curl-full, dnf won't let me without allow erasing, right? 18:17:05 <zbyszek> sgallagh: but this is what we're doing, except that there's just one subpackage for all the modules. 18:17:06 <decathorpe> (or, if a package needs the protocol to work correctly, it can just Require the package for that module, without making the user jump through "dnf swap" or "--allowerasing" hhops) 18:17:34 <sgallagh> zbyszek: If nothing else, I think the naming should be reversed. 18:17:48 <sgallagh> We could have `curl` and `curl-legacy` or similar. 18:17:56 <sgallagh> To make it clear which is the PREFERRED package. 18:17:58 <mhroncok> @zbysek so the extened functionality is somehting you install on top fo the minimal package? 18:18:08 <mhroncok> s/zbysek/zbyszek/ 18:18:11 <sgallagh> (Or `curl-unsafe`, if we want to be opinionated) 18:18:32 <zbyszek> You're too fast for me, I can't type this quickly ;) 18:18:40 <zbyszek> I'll try to answer one by one: 18:19:00 <zbyszek> mhroncok: no, dnf swap is only one of the ways to get libcurl-full. 18:19:24 <mhroncok> what is the other way? 18:19:59 <zbyszek> In particular, the idea is that packages which want libcurl-full do 'Requires: libcurl-full', and no package does 'Requires: libcurl-minimal', but only 'Requires: libcurl'. And we have 'Suggests:libcurl-minimal' so that we get minimal by default. 18:20:13 <mhroncok> sure 18:20:16 <mhroncok> I get that part 18:20:17 <zbyszek> So --allow-erasing is never needed. 18:20:25 <mhroncok> but if I already ahve minimal installed 18:20:31 <mhroncok> and install a pakcage that requires full 18:20:39 <mhroncok> dnf will swap them for me? 18:20:48 <mhroncok> without bothering me with allow erasing? 18:20:53 <zbyszek> So that's a good question. I don't know. 18:20:56 <sgallagh> I don't think so... 18:21:03 <mhroncok> I think ti will fail 18:21:05 <sgallagh> In fact, I'm sure it doesn't 18:21:06 <mhroncok> *it 18:21:07 * nirik doesn't think so either 18:21:18 <mhroncok> but to be honest, I have not verified this assumption 18:21:19 <sgallagh> Because I had to work around that with the fedora-release editions 18:21:35 <mhroncok> however, fit his assumption is correct, the UX is bad 18:21:41 <mhroncok> *if this 18:21:52 <decathorpe> and it can't work in GUI package managers 18:22:05 <decathorpe> they will just throw their hands up :) 18:22:14 <mhroncok> if curl-full would be an additional package I would be +1 18:22:17 <sgallagh> zbyszek: So it's not possible to have these as plugins? They have to be compiled in? 18:22:23 <mhroncok> if it is a replaceent package, I am nto so sure 18:22:31 <sgallagh> mhroncok: My exact stance 18:22:38 <mhroncok> sorry for all the typos, I'm tired 18:22:42 <zbyszek> sgallagh: Plugins would be nicer, I think we all agree. But that's not how the code is organized upstream. 18:22:45 <nirik> I don't think upstream supports dlopening protocols/libs. 18:22:53 * decathorpe plays devil's advocate and mentions that curl-minimal could be in a curl:minimal module 18:23:16 <mhroncok> Am I allowed for a little brainstorming... 18:23:24 <dcantrell> curl is an active project, I would prefer to see work done upstream to support protocol plugins 18:23:28 * nirik looks at decathorpe 18:24:10 <zbyszek> Pfff, yes, it does not work without --allowerasing. 18:24:31 <zbyszek> Maybe it would be possible to add self-Obsoletes.\ 18:24:48 <mhroncok> what if -minimal and -full were co-installable (have files with distinct filenames) and there would be a thin wrapper under the real name that would prefer full if available, but fall back to minimal? 18:24:55 <sgallagh> zbyszek: Actually, I think I may know a trick to get it to be an addon package without needing plugins... 18:25:22 * zbyszek is listening 18:25:42 <mhroncok> it could evene be a posttransaction scriptlet instead of a wrapper, if we did not hate scriptlets 18:25:49 <sgallagh> In short form: install both of them to libexec and use symlinks 18:25:55 <mhroncok> yes 18:25:56 <nirik> perhaps we should just revisit this after rework and interested folks could do that out of band? ;) 18:26:00 <sgallagh> mhroncok: That's pretty much what I'm saying, yeah 18:26:02 <mhroncok> that is esentially what I am saying 18:26:13 <decathorpe> so ... alternatives? 18:26:22 <zbyszek> Bleh. 18:26:25 <sgallagh> More or less, yeah 18:26:27 <nirik> or env modules? 18:26:29 * mhroncok hates alternatives 18:26:38 <decathorpe> SCLs? 18:26:39 <mhroncok> but that would still be a better love story than dnf swap 18:26:43 <zbyszek> A postinstall scriplet should be OK, I guess. 18:26:56 <zbyszek> I'll talk it over with Kamil. 18:27:01 <mhroncok> not to steal this meeting 18:27:11 <sgallagh> Could probably be possible to do with a trigger too 18:27:16 <mhroncok> zbyszek: I will be ahppy to present a proof of concept of this to you and kamil 18:27:34 <zbyszek> mhroncok: thanks. Let's discuss this offline. 18:27:50 <zbyszek> Do we have agreement to punt this until the rework? 18:27:56 <mhroncok> yes 18:27:59 <zbyszek> Or does anyone want a vote now? 18:28:10 <sgallagh> Proposal: The Change is rejected as-is, but we welcome a revised proposal down the road. 18:28:16 <nirik> +1 18:28:22 <dcantrell> +1 18:28:39 <zbyszek> ack, +1 18:28:47 <mhroncok> +1 18:28:50 <decathorpe> +1 18:29:08 <zbyszek> mboddu: ? 18:29:09 <mboddu> +1 18:29:19 <zbyszek> #agreed The Change is rejected as-is, but we welcome a revised proposal down the road (+7, 0, 0) 18:29:35 <zbyszek> #action mhroncok to sent a proof-of-concept of improvement 18:29:44 <zbyszek> #topic Next week's chair 18:29:47 <mhroncok> zbyszek: please send me the changes you had planned for the current proposal, so i know how to build it twice 18:29:58 <mboddu> (FWIW, I like sgallagh initial proposal of curl-legacy) 18:30:41 <mhroncok> I cannot chair net week, we have a family visit, I might skip the meeting 18:30:51 <zbyszek> We're getting into bike-shedding territory. Some of those protocols are not legacy, just infrequently-used-with-a-generic-command-line-tool. 18:30:53 <sgallagh> I can do it, I think 18:31:04 <zbyszek> Calling them "legacy" is just misleading. 18:31:14 <zbyszek> E.g. there's nothing wrong with 'dict' speaking dict://. 18:31:29 <sgallagh> Yeah, the naming doesn't matter too much to me so long as it doesn't imply "complete-vs-stripped-down" as the current arrangement does. 18:31:35 <mboddu> zbyszek: Sure, but some other word that puts these less used protocols in another sub package 18:31:48 <zbyszek> sgallagh: but it's exactly what it is, no? 18:32:02 <zbyszek> It's like 'git' and 'git-all'. 18:32:15 <mhroncok> it-core :) 18:32:19 <mhroncok> git-core 18:32:29 <sgallagh> No, it's more like "everything you probably need" vs "a whole bunch of stuff almost no one cares about" 18:33:05 <zbyszek> mhroncok: the split in the package was done months ago… 18:33:07 <sgallagh> zbyszek: That's a bad example, because most people would install `git` because it provides the expected runtime 18:33:08 <nirik> curl-obscure? curl-niche? 18:33:24 <sgallagh> Whereas git-core is intentionally minimal for usage in things like CI 18:33:26 <salimma> ansible-core :) 18:33:43 <mhroncok> ack 18:33:54 <mboddu> Yeah, I know naming is hard, but the name here doesn't really matter 18:33:56 <mhroncok> stop the name bikeshed please :D 18:33:56 <sgallagh> I like `libcurl-niche`, actually 18:34:02 <sgallagh> It doesn't make any value judgements 18:34:12 <mhroncok> i like curl-cthulu 18:34:17 <zbyszek> Anyway, any volunteers for next week? 18:34:20 <mboddu> +1 for that ^^ 18:34:23 <sgallagh> curlthulu? 18:34:27 <mhroncok> :D 18:34:32 <mhroncok> stephen already volunteered 18:34:37 <mhroncok> it was lost in the bikeshed 18:34:38 <sgallagh> Yes, I did 18:34:59 <zbyszek> #action sgallagh will chair next meeting 18:35:07 <zbyszek> Thanks, I misparsed that. 18:35:09 <zbyszek> #topic Open Floor 18:36:02 <sgallagh> Bikeshedding for anyone who wants to stick around? ;-) 18:36:38 <zbyszek> OK, let's wrap the meeting up. 18:36:42 <zbyszek> #endmeeting