17:00:00 <mhayden> #startmeeting FESCO (2022-10-04)
17:00:00 <zodbot> Meeting started Tue Oct  4 17:00:00 2022 UTC.
17:00:00 <zodbot> This meeting is logged and archived in a public location.
17:00:00 <zodbot> The chair is mhayden. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:00 <zodbot> The meeting name has been set to 'fesco_(2022-10-04)'
17:00:07 <mhayden> #meetingname fesco
17:00:07 <zodbot> The meeting name has been set to 'fesco'
17:00:13 <mhayden> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:00:13 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok music nirik sgallagh zbyszek
17:00:17 <mhayden> #topic init process
17:00:22 <mhayden> .hi
17:00:23 <zodbot> mhayden: mhayden 'Major Hayden' <mhayden@redhat.com>
17:00:40 <nirik> morning
17:00:54 <music[m]> .hello music
17:00:55 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
17:01:04 <gotmax[m]> .hello gotmax23
17:01:04 <sgallagh> .hi
17:01:07 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
17:01:10 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:19 <mhroncok> .hello churchyard
17:01:20 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:02:22 <zbyszek> .hello2
17:02:23 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:02:24 <mhayden> i think we have 5 if i counted right
17:02:28 <mhayden> zbyszek makes 6!
17:02:54 <zbyszek> I'm a spare.
17:03:10 <mhayden> zbyszek: you're more than a spare to me
17:03:14 <bcotton> .hello2
17:03:14 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:04:02 <mhayden> okay, let's roll
17:04:04 <mhayden> #topic #2877 Change: SWIG 4.1.0
17:04:08 <zbyszek> mhayden: thank you
17:04:12 <mhayden> .fesco 2877
17:04:13 <zodbot> mhayden: Issue #2877: Change: SWIG 4.1.0 - fesco - Pagure.io - https://pagure.io/fesco/issue/2877
17:04:21 <mhayden> I put this on the agenda, but then the +1's came flying in
17:04:26 <mhayden> I think we have 7 there right now
17:04:51 <mhayden> not much to say here except thanks to everyone for taking a look at that one
17:04:56 <mhayden> anyone have any comments?
17:05:23 <mhayden> alrighty, moving right along
17:05:27 <mhayden> #topic  #2870 Change proposal: Replace DNF with DNF5
17:05:31 <mhayden> .fesco 2870
17:05:40 <zodbot> mhayden: Issue #2870: Change proposal: Replace DNF with DNF5 - fesco - Pagure.io - https://pagure.io/fesco/issue/2870
17:05:50 <mhayden> this was on last week's agenda but we ran short of time.
17:06:35 <gotmax[m]> They didn't really answer the questions/feedback
17:06:49 <mhayden> ah and i don't see jmracek here today
17:06:52 <zbyszek> My basic problem with this change is that I don't have the feeling that all the bits and pieces are enumerated and we have a plan how to handle them.
17:07:36 <zbyszek> Is it OK if the dnf4 and dnf5 are used in parallel on the same machine?
17:07:41 <mhayden> right. and there are questions about current dnf + dnf5 co-existing at the same time
17:08:03 <gotmax[m]> I think so. The history database just isn't synced.
17:08:06 <zbyszek> The history databases are not shared, iiuc, but basic quering of repodata and packages will work, right?
17:08:14 <nirik> yeah, the change had it completely replacing things... but apparently thats not the plan?
17:08:45 <gotmax[m]> So if foo depends on bar and you `dnf-3 install foo` and then `dnf5 remove foo`, if won't also remove bar.
17:08:47 <gotmax[m]> At least that's my understanding
17:09:19 <zbyszek> I tried dnf and dnf5 a pet container, and I'm getting slighlty different packages offered on upgrade. Not sure if that's a bug or something else.
17:10:00 <nirik> dnf5 has no module support, might be related?
17:10:04 <gotmax[m]> zbyszek: Did you have modular repos enabled?
17:10:09 <zbyszek> No, I don't do modules.
17:10:28 <gotmax[m]> Yes, but was the repo enabled?
17:10:41 <gotmax[m]> Modular filtering isn't implemented
17:10:45 <mhroncok> anyway...
17:10:48 <zbyszek> It was a copr package that dnf wanted to update, and dnf5 didn't. But the repo seemed to be enabled in both.
17:10:55 <mhroncok> waiting for jmracek to respond to all our questions?
17:11:13 <mhayden> i think so, mhroncok -- i was trying to gather up the questions that are missing answers
17:11:32 <mhroncok> ack
17:11:41 <mhayden> lots of people came in with lots of questions in the fesco ticket and i could see how that would be overwhelming
17:12:11 <mhayden> anyone here have some expertise/interest in this area who would want to cobble together the list of unanswered questions for jmracek?
17:12:43 <music[m]> I think I’m on the same page with others here. Basically, I want the Change to happen, and also I want to make sure that we don’t leave a bunch of workflows based on dnf broken with no obvious replacement ready, and I don’t think I understand yet what that means  procedurally-speaking.
17:12:46 <salimma> .hi
17:12:47 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
17:12:48 * nirik thinks it might be better to take those back to the list.
17:12:58 <mhayden> hello salimma 👋🏻
17:13:33 <mhayden> nirik: agreed, but i'm just trying to get a list of questions for jmracek to answer that are all in one place -- fesco ticket or mailing list or somewhere
17:14:11 <nirik> sure, that would be handy/good
17:14:13 <gotmax[m]> I think it's a problem that such a major change like this doesn't have a clear scope or clearly lay out the prereqs.
17:14:33 <zbyszek> Yes, and we've been in such places before, and it (sometimes) doesn't end well.
17:14:51 <mhayden> are we looking for phases of implementation here with specific actions/checkpoints in each? that could be a way to work through this
17:15:49 <zbyszek> A checklist would be nice.
17:16:00 <mhayden> i'm trying to remember back to dnf/yum transition -- i remember both of them running alongside each other for some time and that seemed to work well
17:17:09 <mhayden> okay, i'd suggest that jmracek provide a phased approach to bringing in DNF5 with actions/checkpoints in each
17:17:21 <zbyszek> mhayden: +1
17:17:30 <mhroncok> ack
17:17:41 <mhayden> oh should i do the propose thing? i'm still learning the ropes on this 🙃
17:18:05 <mhroncok> I don't think it is necessary to vote about this
17:18:37 <mhayden> okay, how about i summarize some of this and ask jmracek for a phased approach in the fesco ticket?
17:18:58 <zbyszek> ack
17:18:58 <gotmax[m]> What exactly do you mean by a phased approach?
17:19:13 <mhroncok> phase one: add dnf5 to the Fedora repos
17:19:38 <mhayden> what i would hope is dnf5 comes in via an orderly path with certain requirements to move forward to next steps
17:19:39 <zbyszek> mhroncok: that's also important because it'll give us a place to report issues.
17:19:42 <mhroncok> phase two: stop using modules in Fedora or implement modular support :D
17:19:53 <mhayden> yeah mhroncok has good examples there
17:20:13 * mhayden notes that this is helpful for our next topic, too
17:20:20 <mhroncok> step N-1: port all releng and infra work to the new API
17:20:25 <zbyszek> mhroncok: sadly, the plan is to implemnt it. We could actually be fixing real issues on this, but instead half a year of development will go into modular filtering. But things are as they are.
17:20:30 <mhroncok> step N: remove dnf4
17:20:39 <mhroncok> s/work/scripts/
17:20:41 * gotmax[m] nods
17:21:07 <gotmax[m]> Add the missing functionality to `dnf5 repoquery`
17:21:15 <mhroncok> while the current plan is: switch to dnf5, remove dnf4 asap
17:21:30 <mhroncok> I don't like that approach personally
17:21:33 <mhayden> right, we need that broken down into more pieces
17:21:53 <mhroncok> I've spoken with the RHEL software management product owner and they said they will try to work with the change owner here
17:22:11 <mhroncok> that was a week ago IIRC
17:22:32 <zbyszek> step N-2: document differences and new functionality in packager docs and user docs
17:22:53 <gotmax[m]> Yeah, I think it needs more testing and I'm also not sure it will actually be ready by then
17:22:54 <gotmax[m]> It's difficult to determine that without definite criteria
17:22:55 * nirik would like --refresh, but that might just be me
17:23:00 <mhayden> okay, i'll ask in the ticket for the change to have some phases/checkpoints
17:23:11 <mhayden> i mean, this change is *fairly* critical to the workings of Fedora
17:23:21 <gotmax[m]> `dnf5 repoquery --whatrequires`
17:23:23 <gotmax[m]> `dnf update`
17:24:01 <mhayden> #action mhayden to update #2870 with a request for phases/checkpoints
17:24:05 <mhayden> anything else on this one?
17:24:44 <gotmax[m]> Proper documentation for the new Python API also
17:24:45 * gotmax[m] will stop listing things now :)
17:24:51 <mhayden> gotmax[m]: 🫂
17:25:30 <mhayden> okay, moving on to the last topic
17:25:33 <mhayden> #topic #2865 Change: Strong crypto settings: phase 3, forewarning 2/2
17:25:37 <mhayden> .fesco 2865
17:25:38 <zodbot> mhayden: Issue #2865: Change: Strong crypto settings: phase 3, forewarning 2/2 - fesco - Pagure.io - https://pagure.io/fesco/issue/2865
17:25:49 <zbyszek> No change from last week?
17:26:00 <music[m]> (expression of general agreement with dnf5 discussion)
17:26:09 <mhayden> if i may, i'd like to kick off the discussion with a question: is removing SHA-1 support a worthwhile endeavor for Fedora?
17:27:04 <zbyszek> IMO, removing — no. But disabling in certain paths or warning about use in certains paths — yes.
17:28:09 <mhayden> what paths should still trust SHA-1?
17:28:10 <gotmax[m]> Yeah, it was rejected and they've gone back to the drawing board, but it sounds like there may be more to discuss
17:28:59 <zbyszek> mhayden: one obvious example is installation of packages from old releases.
17:29:33 <zbyszek> I guess this should be handled like self-signed certs in the browser, but without making it too difficult.
17:29:35 <mhayden> right. i don't know how common that would be, but that's one of them
17:29:52 <zbyszek> Also, DNSSEC, all over the place.
17:30:11 <mhayden> i think the issue we're up against is we either 1) break things that trust SHA-1 or 2) silently log things that trust SHA-1, nobody looks at that, and then we break things that trust SHA-1 later
17:30:11 <gotmax[m]> Even if user warnings/rpminspect warnings/logging/test days are not the most effective, it's better than nothing. At least, we'll have more data.
17:31:29 <gotmax[m]> Is there/can there be some sort of tracking bug for packages/use cases that still require SHA-1?
17:31:35 <zbyszek> So, should we just wait for another round from asosedkin?
17:31:57 <mhayden> zbyszek: likely so -- just trying to give asosedkin something to work with or some guidance
17:32:44 <salimma> zbyszek: yeah, dealing with old packages was a major pain for our internal c8->c9 migration
17:32:50 <salimma> not sure how common that would be among the Fedora userbase
17:33:08 <mhayden> so logging something, like a deprecation notice, would be the first choice. if that's not possible, do we keep SHA-1 for longer?
17:33:16 <zbyszek> gotmax[m]: that wasn't part of the of the Change plan, but I think we should have a tracker bug
17:33:31 <gotmax[m]> Rpmfusion's F36 release repo still uses SHA-1
17:33:40 <zbyszek> mhayden: essentially, I think it must be kept forever.
17:33:58 <mhayden> even with the security implications that brings?
17:34:24 <zbyszek> salimma: I don't think that "how common" is something worth thinking about. It should just be supported forever, but not used in places where it shouldn't.
17:34:31 <gotmax[m]> And other third party repos probably
17:34:31 <davide> as a datapoint, I can tell you the lack of SHA1 signed rpms in CentOS 9 was a massive pain to deal with at Meta
17:34:32 <davide> especially as it was done very late in the release cycle
17:34:41 <mhayden> i might give the `update-crypto-policies --set TEST-FEDORA39` command a try tomorrow on my workstation and see what I run into. i'm on F37 beta now.
17:35:03 <mhayden> davide: good point -- we'd need to give some lead time on this one for sure
17:35:10 <davide> whatever is decided for Fedora, I would recommend announcing any potential deprecation very loudly and very early so folks can start planning around it
17:35:11 <zbyszek> Just like cp1250 — it's not something that I'd ever want to use again, but if iconv or python stopped supporting it, that'd be a huge mistake.
17:35:31 <salimma> zbyszek: agreed
17:35:52 <salimma> Davide Cavalca was talking about exactly what I mentioned :)
17:36:15 <davide> we also found there are a lot of vendors that provide binary RPMs for hardware enablement stuff that are all still SHA1, and getting them to update them is often really hard
17:37:03 <salimma> oh, that would definitely bite on desktop. I bet the Dropbox RPM (which doesn't fully work anymore in F37 anyway) is SHA1. it's tagged 'fc21'
17:37:15 <mhayden> okay, so our suggestion back to asosedkin is to find a way to get something logged during SHA-1 trust events, somewhat like SELinux permissive mode?
17:37:50 <salimma> logging sounds good, yeah. can we leverage ABRT or something similar to collect the data, or is that too invasive?
17:38:22 <zbyszek> And also to implement per-application or per-process relaxing of the check. This has already been discussed a number of times, but without much response.
17:38:46 <mhayden> okay, i'll put some of that into the ticket
17:38:54 <zbyszek> salimma: I don't think we need to. We can ask people to report those issues in bugzilla.
17:39:02 <mhayden> #action mhayden to update 2865 with a summary from the meeting
17:39:13 <mhroncok> I ma afraid this will not be acceptable for the change owners :(
17:39:19 <mhayden> anything else on this one?
17:39:25 <mhroncok> s/ma/am/
17:39:45 <gotmax[m]> Tracking bug also
17:39:56 <mhayden> ah okay
17:40:30 <mhayden> alrighty, let's carry on with that one in the ticket
17:40:35 <mhayden> #topic Next week's chair
17:40:53 <mhayden> i am unavailable during next week's meeting time, so hopefully someone else can raise their hand for this 😉
17:41:42 <sgallagh> I am similarly unavailable (holiday where I am)
17:42:24 <mhroncok> I'll do it
17:43:10 <mhayden> #action mhroncok to chair next week's meeting 🪑
17:43:15 <sgallagh> Actually, that's a mistake. The holiday is the previous day. I should be able to attend.
17:43:17 <mhayden> thanks mhroncok! 👏🏻
17:43:40 <mhayden> #topic Open Floor
17:43:58 <mhayden> anyone have anything to raise?
17:43:58 <salimma> oh, Columbus Day
17:44:22 <sgallagh> Indiginous People's Day, here.
17:45:12 <nirik> just a FYI, notifications is not working currently... hopefully we will have it working again soon.
17:45:24 <mhayden> nirik: thanks for the work on that. i imagine it's a lot
17:45:43 <mhayden> okay, i'll wrap this one up then
17:45:49 <mhayden> i hope all of you have a great rest of the week
17:45:59 <nirik> it's a box o horror for sure. ;(
17:46:09 <salimma> Stephen Gallagher: nice that it's renamed there already
17:46:11 <sgallagh> mhayden++
17:46:12 <zbyszek> mhayden: thanks, and thanks for chairing.
17:46:19 <mhayden> no problem!
17:46:33 <gotmax[m]> Thanks y'all! Have a good week
17:46:33 <mhayden> #endmeeting