17:01:05 <zbyszek> #startmeeting FESCO (2021-04-20)
17:01:05 <zodbot> Meeting started Tue Apr 20 17:01:05 2021 UTC.
17:01:05 <zodbot> This meeting is logged and archived in a public location.
17:01:05 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:05 <zodbot> The meeting name has been set to 'fesco_(2021-04-20)'
17:01:05 <zbyszek> #meetingname fesco
17:01:05 <zbyszek> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:01:05 <zodbot> The meeting name has been set to 'fesco'
17:01:05 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
17:01:08 <zbyszek> #topic init process
17:01:10 <zbyszek> .hello2
17:01:11 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:01:29 <bcotton> .hello2
17:01:30 <Eighth_Doctor> .hello ngompa
17:01:30 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:01:33 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:01:38 <mhroncok> .hello churchyard
17:01:44 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:02:05 <dcantrell> .hello2
17:02:05 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:02:45 <sgallagh> .hello2
17:02:46 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:02:57 <zbyszek> This meeting _is_ late in the day... I didn't fully realize this when we voted on the time.
17:03:09 <zbyszek> We have quorum.
17:03:20 <zbyszek> #topic #2596 F35 Change: Switching Cyrus Sasl from BerkeleyDB to GDBM
17:03:20 <zbyszek> .fesco 2596
17:03:21 <zodbot> zbyszek: Issue #2596: F35 Change: Switching Cyrus Sasl from BerkeleyDB to GDBM - fesco - Pagure.io - https://pagure.io/fesco/issue/2596
17:03:23 <nirik> morning
17:03:34 <zbyszek> I invited dbelyavs to the meeting.
17:04:20 <decathorpe> .hello2
17:04:21 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
17:04:24 <decathorpe> sorry for being late.
17:04:43 <bcotton> too much 4am haskell
17:04:54 <decathorpe> yeah way too much :|
17:04:54 <dcantrell> the list discussion clarified to me that sqlite was not an option.  for some reason I thought it was for cyrus-sasl, but sasldb won't allow that.  fine with me
17:05:03 * mhroncok has been busy with life, has not really followed this one
17:05:17 <zbyszek> So... maybe I'm overcomplicating this, but I have the feeling that upgrades could be a problem.
17:05:39 <dcantrell> that's where I was as well.  the proposal could use a little more info on that
17:06:11 <zbyszek> I can easily imagine a situation where some packages have been adjusted to move to the new format on upgrades, but some haven't, and then we're blocked.
17:06:24 <dcantrell> right
17:06:46 <zbyszek> Also, if we decide to revert  or postpone, it'll be hard.
17:07:04 <nirik> database migrations are always hard. ;(
17:07:04 <zbyszek> So... should we move the contingency deadline much earlier?
17:07:21 <dcantrell> I would be more comfortable with that
17:08:08 <dbelyavs> /join #freenode
17:08:18 <zbyszek> dbelyavs: I think it works now :)
17:08:41 <dbelyavs> Great :)
17:08:44 <dbelyavs> Thanks!
17:10:04 <dbelyavs> I've sent the letter to all the maintainers of the cyrus-sasl affected packages but get pretty little responses :(
17:10:17 <zbyszek> dbelyavs: yeah, that's what often happens.
17:10:23 <dbelyavs> Yes.
17:10:31 <dcantrell> how many packages are affected?
17:10:40 <dbelyavs> Let me take look...
17:10:42 <zbyszek> dbelyavs: Is the plan to only deprecate bdb, but keep support, at least for a while?
17:12:25 <dbelyavs> https://docs.google.com/spreadsheets/d/1z5eTSm3rtlKtEKPCxhI_wE861Xzg8kbvINWixSwQmLg/edit#gid=0
17:12:52 <mhroncok> oh, nice sphreadsheet
17:12:57 <dcantrell> yeah, this is nice
17:12:59 <dbelyavs> zbyszek, the plan is get away the (dynamic) dependency on bdb. The static one persists
17:13:10 <dbelyavs> for the migration tool
17:14:06 <zbyszek> It would be easier to keep the support at least for a release, to give more time to update.
17:14:37 <dbelyavs> zbyszek, unfortunately, the sasldb plugin can be linked only to one db library at a time
17:15:22 <zbyszek> Oh, that's bad. Because it means that once the upgrade starts, the old db becomes unavailable.
17:15:33 <dcantrell> I would say the packages in this spreadsheet that are either 'yes' or 'maybe' affected should be in the proposal.  We move the contingency deadline earlier.  Then keep the feature page updated with those affected as they are resolved.
17:15:51 <zbyszek> dcantrell: +1
17:16:16 * nirik is ok with that.
17:16:27 <mhroncok> wild idea: can we have a compat package (if needed) that conflicts with this one?
17:16:43 <zbyszek> dbelyavs: is the conversion helper packaged separately?
17:17:05 <dbelyavs> dcantrell, I think I provided the link in the proposal. If not, I can do it.
17:17:11 * dcantrell looks again
17:17:26 <dcantrell> I like the compat package idea as well, at least for packages that may need longer to update
17:17:27 <dbelyavs> zbyszek, no. It's a part of the cyrus-sasl package
17:18:01 <dcantrell> but wouldn't that mean things depending on the compat package would not be able to use the new db?  it would just be they can build successfully
17:18:28 <dcantrell> dbelyavs: I do see a link to the spreadsheet, sorry
17:18:34 <dbelyavs> NP
17:18:52 <dbelyavs> I don't have an idea how the compat package should look like
17:19:15 <mhroncok> dcantrell: yes, it would be either or
17:19:28 <mhroncok> dcantrell: with possible clashes on one system
17:19:51 <dcantrell> mhroncok: I mean, I think that's fine so long as it's documented for users.  I think you're also suggesting the compat package would not be long lived, but be something for 1 or 2 releases of Fedora
17:20:11 <mhroncok> dcantrell: something like that, yes
17:20:54 <nirik> that seems like just prolonging the pain to me. :)
17:20:57 <dbelyavs> mhroncok, dcantrell - how do you see the compat package?
17:20:58 <zbyszek> I think the compat-package approach *could* be useful, but maybe we'll be able to do without.
17:20:59 <mhroncok> unless some of the adapted dependent is "always installed" kind of package, in that case it makes it almost impossible to switch to the compat one
17:21:04 <dbelyavs> nirik, I agree
17:21:28 <mhroncok> (that was just in case we hit real trouble, not by default)
17:21:36 <mhroncok> as a "soft" contingency plan
17:21:58 <simo> I do not undrstand how a compat package can work ...
17:22:17 <dbelyavs> simo, +1
17:22:42 <mhroncok> basically the same package with different name and different db
17:22:47 <simo> there is no so name change or anything that would allow us to provide a "compat" package
17:22:53 <dcantrell> so the change here is for the sasldb plugin to move from bdb to gdbm, right?  how are the dependent packages linked with that?
17:23:04 <simo> mhroncok: so both provide the same and conflict?
17:23:11 <simo> mhroncok: I think it would be a terrible idea
17:23:13 <mhroncok> simo: yes
17:23:15 <dbelyavs> dcantrell, yes
17:23:19 <mhroncok> simo: why?
17:23:26 <simo> some peopel will randomly end up with the "compat" package
17:23:36 <mhroncok> well, not randomly
17:23:37 <simo> and then one day when it is gone their dbs will just break
17:23:51 <mhroncok> but you are right
17:23:53 * zbyszek shares simo's concern
17:24:08 <simo> I would rather take the pain once
17:24:17 <simo> converting the DBs is easy and it is a one time op
17:24:17 <mhroncok> better to have a coordinated migration in one release I guess
17:24:27 <dcantrell> are there any dependent packages that will present a db change problem?  maybe it's not even necessary to explore a compat package
17:24:27 <mhroncok> it was just an idea
17:24:28 <simo> and quite frankly only a very small subset of users will be affected
17:24:40 <simo> 95% of cyrus-sasl usage is for client packages
17:25:04 <simo> dcantrell: there are some we identified at risk
17:25:18 <simo> dcantrell: but it is mostly user configuration, so not much we can automatically do at upgrade time
17:25:38 <simo> we need to expect some people with random configs may see breakage
17:25:46 <simo> should be easy to recover though
17:25:58 <dcantrell> ok, in that case then I a more in favor of an earlier contingency deadline with a test plan
17:26:03 <simo> and it fails "safe"
17:26:07 <decathorpe> well, the release notes are usually the place to document this?
17:26:08 <simo> ie auth will fail
17:26:14 <dcantrell> decathorpe: yeah
17:26:19 <dcantrell> I mean, that's where I would look
17:26:22 <zbyszek> dcantrell: can you type up a proposal to vote
17:26:23 <mhroncok> ok. earlier contigency and doo ti asap in the dev cycle
17:26:27 <mhroncok> *do
17:26:49 <dcantrell> yeah, just a sec
17:26:59 <zbyszek> Please include "add a list of affected packages on the wiki" please ;)
17:27:38 <zbyszek> I have nothing against google docs, but they are a fleeting thing.
17:27:56 <simo> zbyszek: so just copy the doc in the wiki ?
17:28:17 <dcantrell> proposal: move cyrus-sasl db change contingency deadline to F35 branch date (2021-08-10), added maybe/yes affected dependent packages to the change proposal page for easier tracking, add test plan for affected packages once changes land
17:28:44 <zbyszek> simo: rather filter it to only include package names with C=Yes, and strip out outher columns.
17:29:09 <zbyszek> dcantrell: +1
17:29:10 <sgallagh> dcantrell: Sounds good to me. +1
17:29:21 <nirik> dcantrell: +1
17:30:07 <zbyszek> mhroncok?
17:30:14 <decathorpe> dcantrell: +1
17:30:16 <mhroncok> +1
17:30:19 <dbelyavs> dcantrell, zbyszek - would you be able to provide exact instruction for me? I'm not so familiar with the process
17:30:38 <zbyszek> dbelyavs: sure, let's discuss this by mail.
17:30:50 * bcotton has to leave
17:30:51 <dbelyavs> zbyszek, thanks!
17:30:51 <dcantrell> dbelyavs: yep, feel free to include me in the email
17:30:52 * nirik has to depart. can catch up on logs later.
17:31:09 <zbyszek> #agree APPROVED (+6, 0, 0)
17:31:16 <mhroncok> nirik: have a nice day o/
17:31:19 <zbyszek> dbelyavs, simo: thanks for coming!
17:31:40 <zbyszek> #topic #2597 F35 Change: Debuginfod By Default
17:31:45 <fche> .hello2
17:31:46 <zbyszek> .fesco 2597
17:31:46 <zodbot> fche: fche 'Frank Ch. Eigler' <fche@redhat.com>
17:31:49 <zodbot> zbyszek: Issue #2597: F35 Change: Debuginfod By Default - fesco - Pagure.io - https://pagure.io/fesco/issue/2597
17:32:09 <dbelyavs> zbyszek, thanks!
17:32:43 <fche> (btw I am glad I got wind of this meeting on the mailing list; the calendar/fesco indicates tomorrow)
17:33:04 <zbyszek> fche: hmm, I thought it was moved.
17:33:31 <decathorpe> I'm not sure if privacy / security concerns should (or can) really be addressed by FESCo. Wouldn't those be better issues for the Council or a Security team?
17:33:33 <dcantrell> zbyszek: I like the idea of debuginfod by default, but maybe this is something that should be default for rawhide and maybe up to the RC phase, then releases switch it back off
17:34:14 <fche> dcantrell, people running releases need to run debuggers as much as those running rawhide
17:34:27 <dcantrell> decathorpe: maybe the security team, I don't think the council necessarily
17:34:46 <zbyszek> fche: is this enabled only if the optional package is installed?
17:34:46 <dcantrell> fche: true, but turning it off by default doesn't mean it becomes not available
17:35:13 <zbyszek> elfutils-debuginfod-client?
17:35:14 <fche> zbyszek, depends on whether 'default on' is acceptable
17:35:29 <fche> the debuginfod-client is Suggest:'d or something so it gets around
17:36:08 <zbyszek> fche: so as a compromise of sorts, I think it'd be good to split out just the profile.d file to a separate package.
17:36:08 <fche> if 'default on' is not kosher, then some new purely optional subpackage could trigger it
17:36:18 <zbyszek> Yeah, exactly.
17:36:40 <dcantrell> that's reasonable
17:36:53 <zbyszek> The UX with this is just so wonderful... so it'd be sad not make this widely available.
17:37:07 <fche> well, I'm hoping we can convince y'all to let it be default-on :)
17:37:14 <mhroncok> fche, zbyszek: about the calendar, I'Ve opened https://pagure.io/fesco/issue/2599 not to forgot
17:37:15 <fche> i.e., what concerns can we overcome ?
17:37:27 <zbyszek> But it creates a potential info leak, and potentially additinoal security exposure.
17:38:03 <fche> re. info leak, yes, a little bit, but can that cost be overcome by release notes & an easy opt-out ?
17:38:30 <mhroncok> I think we can decide on "we want this" part and solve all the privacy issues and opt-in/opt-out mechanisms in the next step?
17:38:39 <zbyszek> fche: is anything except build-info sent to the server?
17:38:52 <fche> buildid hex code
17:39:03 <fche> and a User-Agent: string identifying the elfutils/fedora major version numbers
17:39:22 <decathorpe> sorry, I need to leave. I'll read up on the discussion later. see you next week
17:39:25 <zbyszek> OK, so unless you already have the code at hand, it's an opaque identifier. This is good.
17:40:14 <mhroncok> decathorpe: o/
17:40:19 <zbyszek> fche: so what about the following: make the config package separate and not pulled in by default. Let gdb (and other users) print out a hint on startup to install the package.
17:40:49 <fche> zbyszek, hm that'd be messy UX and affect a bunch of packages
17:41:37 <mhroncok> brb
17:42:01 <amerey> clients only send data if $DEBUGINFOD_URLS is set. couldnt we install debuginfod by default and instruct users to set the url to enable it fully?
17:42:28 <fche> amerey, that is the status quo (and we don't need debuginfod (the server), the context here is the client)
17:42:39 <zbyszek> proposal: change is approved in current form (on by default, can be opted-out by removing lfutils-debuginfod-client). We'll ask the Council to weigh in on the privacy/security aspect, and maybe adjust the enablement mechanism before release.
17:42:59 <fche> would be glad to make an easy opt-out possible
17:43:03 <fche> via rpm
17:43:43 <dcantrell> zbyszek: +1
17:44:04 <fche> any suggestions re. release notes wording?  maybe work with security folks to help compose?
17:44:20 <mhroncok> I'd rather see the council weighing in before we enable this in rawhide
17:45:24 <zbyszek> mhroncok: I think rawhide users should be OK with this.
17:46:07 <fche> possibility: we could flip it on for rawhide ASAP, announce it
17:46:08 <mhroncok> anecdotal evidence only, rawhide users seem more paranoid than "regular" users to me
17:46:31 <fche> ... and potentially roll it back to opt-in for f35 release, if controversy appears that we cannot reassure
17:46:52 <dcantrell> I think enabling it now in rawhide also serves to get some feedback from users now and the general sentiment toward enabling by default
17:46:59 <dcantrell> fche: right
17:48:09 <zbyszek> fche: after the discussion here, I'm fine with just enabling it. The privacy leak is negligible and I think good release notes are more important than the details of the opt-in/opt-out mechanisms.
17:48:42 <dcantrell> I will bring this up at the next council meeting too
17:48:54 <fche> would be glad to attend if appropriate/needed
17:49:08 <zbyszek> #action dcantrell to raise the issue in a Council meeting
17:49:31 <dcantrell> fche: thanks
17:49:46 <fche> shall we go ahead and rawhide-activate it asap?
17:50:02 <mhroncok> not approved yet
17:50:04 <zbyszek> fche: please wait for the vote to end.
17:50:21 <fche> (ok, I didn't mean for f35 final, as a transient test)
17:50:46 <mhroncok> zbyszek: proposal?
17:50:50 <zbyszek> fche: let's talk about security a bit too.
17:51:09 <fche> sure.
17:51:41 <zbyszek> Is it fair to say that if this is enabled, anyone who takes over the debuginfo server can cause arbitrary command excecution by gdb?
17:52:13 <fche> super hypothetically
17:52:56 <zbyszek> How robust is the code that uses this data?
17:53:15 <fche> you mean serves?  debuginfod.fedoraproject.org?
17:53:50 <zbyszek> fche: That also, to some extent. But I primarly meant the client code that uses the debuginfo data.
17:54:15 <mhroncok> zbyszek: Is it fair to say that who takes over the koji server can cause arbitrary command excecution by anything?
17:54:32 <fche> so your scenario is: someone broke into the debuginfod server, planted false data, that got downloaded to a client, now what can happen?
17:54:38 <zbyszek> fche: yes
17:55:14 <fche> zbyszek, yeah depends on the client.  they're generally robust internally but I suppose really malevolant crafted dwarf data could lead a debugger operator astray
17:55:15 <zbyszek> mhroncok: well yes, but users don't interact with the koji server directly. Users only use packages that have been signed.
17:55:35 <fche> zbyszek, and debuginfod only serves content from koji-built (signed methinks) packages.
17:55:37 <mhroncok> zbyszek: packages produced by koji are signed, nobody inspects them before that
17:56:17 <zbyszek> mhroncok: hmm, so it is the same server that does package builds and that serves the web ui?
17:56:46 <mhroncok> zbyszek: no idea
17:56:48 <zbyszek> (does package builds → orchestrates package builds, I know they are build on worker nodes.)
17:57:48 <zbyszek> fche: so I think this has some security implications, because the debuginfo server becomes a very juicy target to attack any developer machine.
17:58:21 <fche> zbyszek, for robustness of the server code proper, that's one issue
17:58:22 <mhroncok> fche: can/does the client verify the signatures against something produced by the usual delivery mechanism?
17:58:54 <fche> mhroncok, cannot exactly because the usual delivery bits are entire-RPM level
17:59:07 <fche> BUT we've just sketched out a design for verifying integrity after a download
17:59:18 <fche> and I'm pretty sure we can roll that out in a matter of weeks
17:59:36 <fche> https://sourceware.org/bugzilla/show_bug.cgi?id=27758
18:00:40 <mhroncok> this sounds like an orthogonla problem/solution
18:00:44 <zbyszek> fche: hmm, that doesn't answer my concern.
18:00:52 <mhroncok> if the server is compromised, this doesn't help
18:00:58 <zbyszek> right.
18:01:18 <fche> mhroncok, indeed, that was a verification / client side thing
18:01:48 <fche> for server compromise, two elements: server code vulnerability,   #2 input data corruption - i.e., someone builds bad stuff into koji
18:01:55 <mhroncok> shipping signatures/checksums of the debuginfo files in the runtime rpm is a big overhead I guess?
18:02:29 <zbyszek> fche: I wouldn't worry about #2. It the same situation as now.
18:02:33 <fche> mhroncok, planning to ship checksums.  signatures would imply a new level of key distribution etc. infrastructure, and without privilege separation wouldn't do that much
18:02:39 <fche> zbyszek, agree re. #2.
18:02:47 <mhroncok> agree about 2
18:02:53 <mhroncok> the koji thing was not relevant here
18:02:57 <fche> so for code robustness per se, we -think- it's decent -- it's run under valgrind all the time
18:03:17 <fche> not sure we have resources available for some Expert review of the code base, but of course would welcome that
18:03:40 <fche> it's c++ code rather than c, so processing user input is pretty clean
18:04:35 <mhroncok> we are on this topic for 30+ minutes, should we take this async?
18:04:51 <zbyszek> mhroncok: yeah, I think we should continue the discussion in the ticket.
18:05:27 <zbyszek> Ack?
18:05:36 <mhroncok> zbyszek: do you placeholder -1 it, or do we need a decision here?
18:05:57 <zbyszek> I'll just keep the meeting tag for next week.
18:06:20 <zbyszek> I don't think we need / should make a decision.
18:06:21 <mhroncok> it will get approved in 2 days
18:06:52 <zbyszek> mhroncok: I put a placeholder -0.
18:07:18 <zbyszek> fche: thank you for joining us, this was very helpful.
18:07:27 <zbyszek> #topic Next week's chair
18:07:41 <zbyszek> Volunteers?
18:08:03 <zbyszek> If no volunteers, you'll have to suffer me doing it again.
18:08:15 <mhroncok> not me, that will be the last week to hand over our old appartment
18:08:31 <sgallagh> I can do it, it's been a while
18:08:40 <zbyszek> #action sghallagh will chair next meeting
18:08:44 <zbyszek> Thanks.
18:08:47 <zbyszek> #topic Open Floor
18:08:47 <sgallagh> #undo
18:08:47 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f25b2d887d0>
18:08:54 <sgallagh> #undo
18:08:54 <zodbot> Removing item from minutes: ACTION by zbyszek at 18:08:40 : sghallagh will chair next meeting
18:09:04 <sgallagh> #action sgallagh will chair next meeting
18:09:12 <sgallagh> #topic Open Floor
18:09:36 <mhroncok> sgallagh: too much sghs?
18:09:41 <zbyszek> Everyone, speak up now or remain silent until next week.
18:10:07 <sgallagh> Wouldn't *that* be nice...
18:10:35 <zbyszek> I'll close in a minute.
18:10:39 <mhroncok> zbyszek++
18:10:48 <mhroncok> fche++
18:10:48 <zodbot> mhroncok: Karma for fche changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:10:55 <fche> see ya
18:10:57 <mhroncok> dbelyavs++
18:10:57 <zodbot> mhroncok: Karma for dbelyavs changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:11:04 <zbyszek> dbelyavs++
18:11:04 <zodbot> zbyszek: Karma for dbelyavs changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:11:06 <zbyszek> simo++
18:11:07 <zodbot> zbyszek: Karma for simo changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:11:09 <zbyszek> fche++
18:11:10 <zodbot> zbyszek: Karma for fche changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:11:27 <zbyszek> Thank you all for coming.
18:11:27 <zbyszek> #endmeeting