20:31:13 #startmeeting requirements 20:31:14 Meeting started Wed May 16 20:31:13 2018 UTC and is due to finish in 60 minutes. The chair is prometheanfire. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:31:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:31:18 The meeting name has been set to 'requirements' 20:31:18 #topic rollcall 20:31:23 tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann 20:31:26 o/ 20:31:32 o/ 20:31:33 \o 20:31:37 o/ 20:33:21 :D 20:33:29 #topic Any controversies in the Queue? 20:33:42 https://review.openstack.org/558604 I'd say 20:35:27 Hmm, I think you are right about it being a security issue. 20:35:27 I though we discuessed that 20:35:43 how is it a security issue? 20:35:51 tonyb: I think we did, the main change now is that 3.25.1 is out 20:36:30 Isn't not exposing plain text passwords a security issue? 20:36:36 https://github.com/openstack/oslo.concurrency/commit/0c4718fcb77e9f4e3a22ae458869b7294b7bc91f 20:37:26 #link https://github.com/openstack/oslo.concurrency/commit/0c4718fcb77e9f4e3a22ae458869b7294b7bc91f 20:37:27 smcginnis: IIIUC it's transalating /dev/mapper/vg-my-lv-called-password into /dev/mapper/vg-my-lv-called-p*** 20:37:45 which seems to be doing to opposite to exposing passwords ;P 20:38:35 #link https://bugs.launchpad.net/oslo.utils/+bug/1482382 20:38:37 Launchpad bug 1482382 in Cinder "mask_password is overzealous" [Undecided,In progress] - Assigned to prashkre (prashkre) 20:38:44 ya, bug title makes it sound like it's going the other way 20:39:26 So if my reading is right *and* the fix is in 3.25.1 we can close the requirements bump 20:39:41 then the cinder team can just backport the fix 20:40:03 it is looking like that 20:40:32 ideally it'd add an extra hunk to detect the version of oslo.concurrency and "do the rigth thing" but IMO that isn't *required* 20:41:34 So you're saying Cinder would detect which version of oslo.concurreny is being used and perform the santization itself if it's an older one? 20:41:48 smcginnis: No 20:42:39 smcginnis: cinder would detect the version of oslo.concurreny and bypass it to *avoid* sanitizin the output on older versions (or those without the sanitize_stdout kwarg 20:43:52 smcginnis: but I don't really think that's required 20:45:43 Since it's pretty much the only thing in 3.25.1, it seems like bumping that would be the safer approach. 20:46:26 smcginnis: We'd need to look at the versions that $distros have packaged 20:46:38 safer, but since queens still should be syncing reqs that means re-releases 20:46:49 Available versions: 3.21.1 3.25.0 ~3.25.1 {test PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"} 20:46:52 here 20:46:53 Yeah 20:47:00 isn't stable yet, but 'soon' 20:47:05 smcginnis: we don't bump minimums on stable branches as that makes all the distros do extar work which they've balked at befoer 20:47:52 we usually just update the constraint for the new release and leave it up to downstream to pull it in 20:48:33 if it's not a security vuln that's fixed (and it doesn't look like this is) then we don't need to bump or exclude anything I don't think 20:48:53 it could offer a dos vector if the volume can't be deleted 20:48:55 dhellmann: Yup, and that's what I'm proposing as I don't think this meets our guidlines for minimum bumps on stable/* 20:49:17 it's not clear why the parameters to the command are being sanitized though 20:49:24 before it's run, that is 20:49:50 oh, looking at the patch I get it 20:49:59 we're calling command_b with the output from command_b and that output is being sanitized IIUC 20:50:06 so yeah, I don't think cinder needs to do anything here if we update the constraint 20:50:52 https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L24 20:50:55 already updated 20:51:00 cool 20:51:07 ok, going to close it 20:51:12 +1 20:51:19 I'll abandon with a message 20:52:14 thinking about this sort of thing for the future, we may want to automate some sort of block on changing minimum values on stable branches 20:52:23 although that can lead to broken gates, I guess 20:52:50 Yeah, I think there's always exceptions that need subjective evaluation. 20:52:54 but now that the lower bounds are controlled by project teams, it will be harder to catch "but we had a bug in a library" updates 20:53:00 Automatic blocking could cause issues. 20:53:07 True 20:53:18 Yup 20:53:22 I'm going to abandon the rsd-lib and rsdclient bumps as well 20:53:29 we can brainstorm it befoer August ;P 20:53:32 so maybe it's just a matter of reminding folks about that 20:53:48 prometheanfire: I thought they were okay just waiting for input? 20:53:51 the sphinx 1.7.x change needs a ml thread, because it's a breaking thing 20:53:54 tonyb: it's been a week 20:54:36 prometheanfire: your call but I'm not sure they need to be rejected 20:54:53 prometheanfire: Yeah it seems like we can't use 1.6 or 1.7 without braking someone 20:54:59 they can be re-opened (and I'll note as such) 20:55:19 my feel is go back to 1.7.4 and get the affetced projects to fix the docs 20:55:27 agreed 20:55:34 guess I'll email the list about that 20:56:12 prometheanfire: danke 20:56:24 nothing else for me 20:56:42 I'd like someone to review the uc bot bump (finally on the new webob :D 20:57:26 prometheanfire: Okay I'll look it over today 20:57:31 thanks 20:57:47 the only thing we should have to chage in the bot update is pika now 20:58:55 * tonyb was thinking we should add a "manual-updates.txt" into the repo so that as we find $things that we know are broken we can add them to that file and therefore avoid the bot updating those things 20:59:13 I feel like that'd save a bunch of manual messing with the generated changes 21:00:08 I kinda like having the anoying stuff 21:00:11 makes me want to fix it 21:00:29 #topic Open Discussion 21:00:56 prometheanfire: Okay, I feel like it slows us down 21:01:05 tonyb: probably does 21:02:23 gonna close this unless someone speaks up 21:02:36 * tonyb is good 21:02:43 eyes on https://review.openstack.org/568729 would be nice, but that's it 21:03:50 #endmeeting