14:30:52 <fao89> #startmeeting Pulp Triage 2020-05-05 14:30:52 <fao89> !start 14:30:52 <fao89> #info fao89 has joined triage 14:30:52 <pulpbot> Meeting started Tue May 5 14:30:52 2020 UTC. The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:52 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:30:52 <pulpbot> The meeting name has been set to 'pulp_triage_2020-05-05' 14:30:52 <pulpbot> fao89: fao89 has joined triage 14:30:58 <dkliban> #info dkliban has joined triage 14:30:58 <dkliban> !here 14:30:59 <pulpbot> dkliban: dkliban has joined triage 14:31:06 <ggainey> !here 14:31:07 <ggainey> #info ggainey has joined triage 14:31:08 <pulpbot> ggainey: ggainey has joined triage 14:31:34 <fao89> !next 14:31:35 <pulpbot> fao89: 10 issues left to triage: 6645, 6644, 6643, 6642, 6638, 6631, 6628, 6623, 6597, 6463 14:31:35 <bmbouter> !here 14:31:36 <fao89> #topic https://pulp.plan.io/issues/6645 14:31:36 <bmbouter> #info bmbouter has joined triage 14:31:36 <pulpbot> RM 6645 - mdepaulo@redhat.com - ASSIGNED - pre-flight check not work properly when it needs a prereq role 14:31:37 <ipanova> #info ipanova has joined triage 14:31:37 <ipanova> !here 14:31:38 <pulpbot> https://pulp.plan.io/issues/6645 14:31:39 <pulpbot> bmbouter: bmbouter has joined triage 14:31:40 <pulpbot> ipanova: ipanova has joined triage 14:31:42 <ttereshc> #info ttereshc has joined triage 14:31:42 <ttereshc> !here 14:31:42 <pulpbot> ttereshc: ttereshc has joined triage 14:31:48 <dkliban> !propose accept and add to sprint 14:31:48 <pulpbot> dkliban: propose accept Propose accepting the current issue in its current state. 14:31:51 <fao89> #idea Proposed for #6645: accept and add to sprint 14:31:51 <fao89> !propose other accept and add to sprint 14:31:51 <pulpbot> fao89: Proposed for #6645: accept and add to sprint 14:31:56 <x9c4> !°here 14:31:56 <pulpbot> x9c4: Error: "°here" is not a valid command. 14:32:00 <x9c4> #info x9c4 has joined triage 14:32:00 <x9c4> !here 14:32:00 <pulpbot> x9c4: x9c4 has joined triage 14:32:14 <ipanova> +1 14:32:39 <fao89> mikedep333, are you already working on it, right? 14:32:50 <ttereshc> should these be triaged by the installer team? 14:32:57 <daviddavis> #info daviddavis has joined triage 14:32:57 <daviddavis> !here 14:32:57 <pulpbot> daviddavis: daviddavis has joined triage 14:33:04 <mikedep333> #info mikedep333 has joined triage 14:33:04 <mikedep333> !here 14:33:04 <pulpbot> mikedep333: mikedep333 has joined triage 14:33:05 <mikedep333> yes 14:33:13 <ttereshc> I can't vote for adding or not adding it to the sprint 14:33:28 <dkliban> it's a critical bug that's being worked on 14:33:39 <fao89> I'm wondering if we need a project for the installer 14:33:52 <fao89> #agreed accept and add to sprint 14:33:52 <fao89> !accept 14:33:52 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:33:53 <pulpbot> fao89: 9 issues left to triage: 6644, 6643, 6642, 6638, 6631, 6628, 6623, 6597, 6463 14:33:53 <fao89> #topic https://pulp.plan.io/issues/6644 14:33:54 <pulpbot> RM 6644 - mdepaulo@redhat.com - ASSIGNED - pre-flight check does not check plugins that are installed but not listed in pulp_install_plugins 14:33:54 <dkliban> let's discsuss that after triage 14:33:55 <pulpbot> https://pulp.plan.io/issues/6644 14:33:57 <mikedep333> Please add it. I am working on 6623's 4 sub-issues, #6642 -#6645 14:34:02 <dkliban> !propose accept and add to sprint 14:34:02 <pulpbot> dkliban: propose accept Propose accepting the current issue in its current state. 14:34:23 <fao89> #idea Proposed for #6644: accept and add to sprint 14:34:23 <fao89> !propose other accept and add to sprint 14:34:23 <pulpbot> fao89: Proposed for #6644: accept and add to sprint 14:34:25 <fao89> #agreed accept and add to sprint 14:34:25 <fao89> !accept 14:34:25 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:34:25 <mikedep333> fao89: We discussed that at Pulpcon I think. Let's discuss later; I'll dig up any notes. 14:34:26 <fao89> #topic https://pulp.plan.io/issues/6643 14:34:26 <pulpbot> fao89: 8 issues left to triage: 6643, 6642, 6638, 6631, 6628, 6623, 6597, 6463 14:34:28 <pulpbot> RM 6643 - mdepaulo@redhat.com - ASSIGNED - pre-flight check does not understand the plugin "upgrade" boolean 14:34:29 <pulpbot> https://pulp.plan.io/issues/6643 14:34:32 <dkliban> !propose accept and add to sprint 14:34:32 <pulpbot> dkliban: propose accept Propose accepting the current issue in its current state. 14:34:56 <fao89> !accept 14:34:56 <pulpbot> fao89: No action proposed, nothing to accept. 14:35:03 <dkliban> #idea Proposed for #6643: accept and add to sprint 14:35:03 <dkliban> !propose other accept and add to sprint 14:35:03 <pulpbot> dkliban: Proposed for #6643: accept and add to sprint 14:35:07 <dkliban> i was using the wrong format 14:35:09 <fao89> #agreed accept and add to sprint 14:35:09 <fao89> !accept 14:35:09 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:35:10 <fao89> #topic https://pulp.plan.io/issues/6642 14:35:10 <pulpbot> fao89: 7 issues left to triage: 6642, 6638, 6631, 6628, 6623, 6597, 6463 14:35:11 <pulpbot> RM 6642 - mdepaulo@redhat.com - ASSIGNED - pre-flight check does not check older pulp 3 installs properly 14:35:12 <pulpbot> https://pulp.plan.io/issues/6642 14:35:15 <dkliban> #idea Proposed for #6642: accept and add to sprint 14:35:15 <dkliban> !propose other accept and add to sprint 14:35:15 <pulpbot> dkliban: Proposed for #6642: accept and add to sprint 14:35:21 <fao89> #agreed accept and add to sprint 14:35:21 <fao89> !accept 14:35:21 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:35:22 <fao89> #topic https://pulp.plan.io/issues/6638 14:35:22 <pulpbot> fao89: 6 issues left to triage: 6638, 6631, 6628, 6623, 6597, 6463 14:35:23 <pulpbot> RM 6638 - bmbouter - NEW - [Epic] Host fixtures docker container at https://fixtures.pulpproject.org 14:35:24 <pulpbot> https://pulp.plan.io/issues/6638 14:35:31 <daviddavis> convert to task 14:35:33 <daviddavis> or story 14:35:37 <ggainey> is an epic an issue? or stary? 14:35:40 <ggainey> story even 14:35:41 <bmbouter> task 14:35:51 <ttereshc> +1 to task 14:35:55 <ggainey> yeah sounds good 14:35:56 <dkliban> #idea Proposed for #6638: convert to task 14:35:56 <dkliban> !propose other convert to task 14:35:56 <pulpbot> dkliban: Proposed for #6638: convert to task 14:35:57 <ipanova> +1 14:36:20 <fao89> #agreed convert to task 14:36:20 <fao89> !accept 14:36:20 <pulpbot> fao89: Current proposal accepted: convert to task 14:36:21 <pulpbot> fao89: 5 issues left to triage: 6631, 6628, 6623, 6597, 6463 14:36:21 <fao89> #topic https://pulp.plan.io/issues/6631 14:36:22 <pulpbot> RM 6631 - phlogistonjohn - NEW - pulp_installer: failure to install pulp-rpm on minimal fedora vm 14:36:23 <pulpbot> https://pulp.plan.io/issues/6631 14:36:58 <fao89> bmbouter, I do not have permission to convert to a task on infrastructure 14:37:16 <dkliban> this is not a bug 14:37:25 <bmbouter> I'll convert that to task 14:37:30 <dkliban> user is not using rpm_prerequisite_role 14:37:38 <ttereshc> maybe skip for now and see what user reports? 14:37:39 <fao89> I don't know what to propose 14:37:44 <ttereshc> or notabug is fine 14:37:46 <fao89> skip sounds good 14:37:47 <mikedep333> dkliban: exactly. 14:38:09 <dkliban> #idea Proposed for #6631: close as not a bug 14:38:09 <dkliban> !propose other close as not a bug 14:38:09 <pulpbot> dkliban: Proposed for #6631: close as not a bug 14:38:26 <fao89> #agreed close as not a bug 14:38:26 <fao89> !accept 14:38:26 <pulpbot> fao89: Current proposal accepted: close as not a bug 14:38:27 <fao89> #topic https://pulp.plan.io/issues/6628 14:38:27 <pulpbot> fao89: 4 issues left to triage: 6628, 6623, 6597, 6463 14:38:28 <pulpbot> RM 6628 - bmclaugh - NEW - nginx config broken in Pulp in a Container 14:38:29 <pulpbot> https://pulp.plan.io/issues/6628 14:38:52 <fao89> #idea Proposed for #6628: Leave the issue as-is, accepting its current state. 14:38:52 <fao89> !propose accept 14:38:52 <pulpbot> fao89: Proposed for #6628: Leave the issue as-is, accepting its current state. 14:39:05 <dkliban> and add to sprint 14:39:17 <fao89> #idea Proposed for #6628: accept and add to sprint 14:39:17 <fao89> !propose other accept and add to sprint 14:39:17 <pulpbot> fao89: Proposed for #6628: accept and add to sprint 14:39:20 <dkliban> the single container doesn't include nginx config snippets from plugins 14:39:30 <dkliban> and it should 14:39:32 <ggainey> ah 14:39:32 <fao89> #agreed accept and add to sprint 14:39:32 <fao89> !accept 14:39:32 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:39:33 <fao89> #topic https://pulp.plan.io/issues/6623 14:39:33 <pulpbot> fao89: 3 issues left to triage: 6623, 6597, 6463 14:39:34 <pulpbot> RM 6623 - bmbouter - NEW - pulpcore and plugin pre-flight check seems to not be enforcing and then installer fails at collectstatic 14:39:35 <pulpbot> https://pulp.plan.io/issues/6623 14:39:57 <mikedep333> Accept please, this is the parent issue for 6642 - 6645. 14:40:04 <fao89> #idea Proposed for #6623: accept and add to sprint 14:40:04 <fao89> !propose other accept and add to sprint 14:40:04 <pulpbot> fao89: Proposed for #6623: accept and add to sprint 14:40:06 <mikedep333> Assume a parent issue is the correct way to do this. 14:40:07 <dkliban> +1 14:40:09 <fao89> #agreed accept and add to sprint 14:40:09 <fao89> !accept 14:40:09 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:40:10 <pulpbot> fao89: 2 issues left to triage: 6597, 6463 14:40:10 <fao89> #topic https://pulp.plan.io/issues/6597 14:40:11 <pulpbot> RM 6597 - dkliban@redhat.com - NEW - docs fail to build for Pulp 2 14:40:12 <pulpbot> https://pulp.plan.io/issues/6597 14:40:13 <mikedep333> (can issues be parents?) 14:40:27 <dkliban> mikedep333: yes 14:40:33 <mikedep333> Thanks 14:40:43 <dkliban> we need to accept this and add to sprint also so that we can release 2.21.2 14:40:52 <fao89> #idea Proposed for #6597: accept and add to sprint 14:40:52 <fao89> !propose other accept and add to sprint 14:40:52 <pulpbot> fao89: Proposed for #6597: accept and add to sprint 14:40:52 <ttereshc> yeah +1 14:40:54 <ggainey> yeah 14:40:54 <ipanova> ok 14:41:10 <fao89> #agreed accept and add to sprint 14:41:10 <fao89> !accept 14:41:10 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:41:11 <pulpbot> fao89: 1 issues left to triage: 6463 14:41:12 <fao89> #topic https://pulp.plan.io/issues/6463 14:41:12 <pulpbot> RM 6463 - binlinf0 - NEW - pulp 3.2.1 duplicate key error when sync 14:41:13 <pulpbot> https://pulp.plan.io/issues/6463 14:41:36 <dkliban> #idea Proposed for #6463: accept and add to sprint 14:41:36 <dkliban> !propose other accept and add to sprint 14:41:36 <pulpbot> dkliban: Proposed for #6463: accept and add to sprint 14:41:40 <dkliban> we now have a reproducer 14:41:42 <daviddavis> +1 14:41:44 <ipanova> +1 14:41:45 <ggainey> +1 14:41:53 <ttereshc> +1 14:41:56 <fao89> #agreed accept and add to sprint 14:41:56 <fao89> !accept 14:41:57 <pulpbot> fao89: Current proposal accepted: accept and add to sprint 14:41:58 <pulpbot> fao89: No issues to triage. 14:42:07 <fao89> open floor! 14:42:21 <mikedep333> Q for this installer work 14:42:29 <bmbouter> I want to talk about secretcharfield 14:42:38 <daviddavis> can we skip the installer bugs during triage and let the installer team handle them? 14:42:50 <mikedep333> It sounds like if a user specifies a plugin name like pulp_file rather than pulp-file, pip will convert it to the dash. 14:42:51 <dkliban> daviddavis: we need to create a separate project in redmine 14:42:56 <daviddavis> +1 14:43:10 <mikedep333> +1 14:43:40 <daviddavis> I'll follow up on pulp-dev list 14:43:43 <mikedep333> But i am not sure about pip-tools. I was thinking of replacing underscores in plugin names with dashes for whenever pip-tools get called. 14:43:53 <fao89> I did a query for installer, so it will be easier to migrate to a new project https://pulp.plan.io/projects/pulp/issues?query_id=154 14:44:00 <mikedep333> fao89: thanks! 14:44:23 <dkliban> mikedep333: i am not sure ... can we discuss after the secret char field? 14:44:23 <mikedep333> I agree with this, it will make my work a lot easier. 14:44:29 <mikedep333> dkliban: sure 14:44:30 <bmbouter> thats great 14:44:47 <mikedep333> (the separate project will make things easier) 14:44:57 * mikedep333 yields 14:45:36 <dkliban> bmbouter: secret char field/ 14:46:15 <bmbouter> so I've heard from katello testers that they are having bindings issues because username/password are not shown in the openapi schema for remotes 14:46:45 <dkliban> yep 14:47:25 <bmbouter> the solution we have been persuing is to use secretCharFields 14:47:33 <dkliban> this is causing a major problem where you can't use pulp_container to sync from a registry that requires authentication 14:47:43 <dkliban> bmbouter: that's right 14:48:53 <dkliban> this field would allow users to submit a value for username and password, but only show a checksum of the value when they retrieve a remote 14:49:28 <bmbouter> yes that is what secret char field would do 14:49:28 <x9c4> What if it didn't show anything but "***"? 14:49:58 <bmbouter> there is a use case where the user wants to be able to verify that the saved data is correct 14:50:02 <dkliban> x9c4: then the user would have no way of verifying that the configuration is what they expect it to be. debuggging auth problems would be hard. 14:50:27 <x9c4> The foreman api does it that way. 14:50:31 <bmbouter> and also having anything but the actual data in that fields' response creates another problem I call the "read-then-write-whoops" problem 14:50:40 <bmbouter> foreman api probably has problem verifying the config then 14:51:18 <bmbouter> that problem is where you read the data in the bindings, e.g. '***' and then accidentally write that data back 14:51:27 <bmbouter> hence the whoops at the end of my description 14:52:17 <dkliban> yep 14:52:47 <x9c4> What if the field provided the checksum in a different field? 14:53:11 <x9c4> like 'password_checksum' 14:53:28 <bmbouter> well it complicates things in terms of the read/write serializers (complicates in the sense of additional complexity) 14:53:34 <bmbouter> it's not an off table idea tho 14:54:04 <x9c4> sure, the user needs to know how to handle it, but he does anyway to prevent you whoops 14:54:20 <bmbouter> that's true it would prevent the whoops. so I've been asking myself why are we hiding these fields at all? 14:54:46 <bmbouter> and the reason is because on a multi-user system one user could read the password from another 14:54:57 <ggainey> bmbouter: we're hiding them, iirc, because without authentication/rbac, once I set a remote, *anyone* can retrieve it, yeah? 14:55:02 <ggainey> yeah that 14:55:03 <bmbouter> yeah exactly 14:55:05 <bmbouter> :) 14:55:19 <bmbouter> so here's the thing, pulp as is isn't safe for multi-user in a whole bunch of ways 14:55:29 <bmbouter> currently ... until rbac 14:55:58 <bmbouter> but rbac is one of our next major things, and planning is underway, so I think assuming we'll have it in 2 months is a reasonable expectation to me 14:56:29 <bmbouter> so as a thought experiement, let's assume rbac is already in place ... I believe in that world we don't have to hide the fields at all 14:58:29 <dkliban> bmbouter: so with rbac in place, would some users not be shown these fields? 14:58:41 <ggainey> i mean, if I take a big security-step back, security-conscious users aren't going to want us to be storing things like this in pulp's db at all, but getting them from some keystore-solution 14:58:58 <x9c4> I guess users would not be able to see remotes of other users. 14:59:01 <ggainey> but anyway - with rbac, I'd imagine that only someone with access-to a remote would be able to see the pwds 14:59:04 <ggainey> yeah 14:59:31 <ggainey> admin can see everything, anyone w/db-access clearly can, otherwise you'd have to have allowed-read-access 14:59:36 <bmbouter> yes users having read access to remotes is one of the primary use cases 15:00:15 <x9c4> You would need to trust your pulp-admin in addition to root and the db admin. 15:00:41 <dkliban> bmbouter: i suspect it would be useful for some users to see the URL of a remote but not the username and password 15:00:47 <dkliban> what do you thi? 15:01:17 <bmbouter> the choice on who to trust currently includes the users, admin, db-admin, and root 15:01:31 <bmbouter> my proposal is only focused on removing users from that list 15:01:54 <ggainey> yeah, admin is either trusted or...you're in trouble 15:01:59 <dkliban> agreed 15:02:35 <bmbouter> dkliban: the rbac system would be flexible enough to have more fine grainey permissions, but the issue is openapi schema is not. so I put that in the hard-but-possible category. I'd want to have user nominated use case before thinking much more about it (is my take) 15:02:58 <bmbouter> as in, we'd have to start spliitting serializers around that field ... 15:03:09 <ggainey> yeah 15:03:42 <dkliban> bmbouter: i was thinking that the queryset would filter out that field based on permissions. but perhaps i am dreaming 15:04:02 <dkliban> anyway, back to the bigger picture 15:04:03 <ggainey> so, I understand the problems it can cause, but I am having problems shaking being Really Uncomfortable with treating auth-info as just-another-field 15:04:33 <ttereshc> do we have personas defined anywhere? (I thought we had but I can't find it) 15:04:43 <x9c4> Do we need to dumb down the serializers? Whoever can write may probably read all fields, right? 15:04:50 <bmbouter> consider the damage someone could do with other non-auth fields, oh I secretly rewrote the url field to sync from untrusted falsified content 15:05:01 <bmbouter> ggainey: my claim with ^ example is that rbac is our only hope 15:05:10 <dkliban> i agree 15:05:38 <bmbouter> ttereshc: personas will be plugin defined, these are the "roles" that users and groups can be assigned 15:05:39 <ggainey> bmbouter: RE changing-url - the issue here is that the auth-info may be used for *other access* to that remote site 15:06:02 <ggainey> I'm not as worried about "I can break your pulp install" as "your pulp install gave me access to someone else's machine(s)" 15:06:09 <bmbouter> ttereshc: we do not have a concrete list of personas I'm hoping thursday's call will help us get that 15:06:31 <bmbouter> ggainey: I'm more worried about compromising pulp actually, if you compromise pulp you p0wn the datacenter 15:07:14 <ggainey> bmbouter: if I compromise your login, I can comprise a totally-different datacenter - that's the thinking there 15:07:42 <ggainey> and I can do that with just read-access to the remote, even after RBAC exists 15:07:49 <bmbouter> x9c4: the beauty of this approach is that the read and write would not need to be different for remotes for example and would reduce the write_only issues to only serializers that accept data that isn't stored for retrieval later 15:08:08 <bmbouter> ggainey: I'm not quiet following, rbac only hands data to those authorized to have it 15:09:37 <ggainey> bmbouter: if my RBAC setup gives someone read-access to remotes, without write-access - so they can't break "your" pulp-installation - but they now have access to auth-info that gives them access elsewhere 15:10:22 <dkliban> ggainey: but that's not pulp's problem ... it sounds like the permissions are being handed out to the wrong people 15:10:30 <ggainey> (I mean, at some point users are going to want to be able to insure that this kind of auth-info exists only in some protected keystore and doesn't live in pulp's db at all, but tha's prob way down the road) 15:10:52 <bmbouter> I agree and I agree, I do hope that becomes an option down the road 15:11:27 <ttereshc> yeah, I have a similar concern as ggainey , that's why I asked about personas, I want to understand use cases for different ones. I believe some users will need to have a read-access without seeing auth info 15:12:00 <daviddavis> yea, I could see someone with access to a remote set it up in pulp with username+pass for someone else in pulp to sync from 15:12:14 <daviddavis> but I don't want to share user+pass with this pulp user 15:12:43 <bmbouter> the way this use case is being described is making sense to me 15:12:51 <bmbouter> despite my rejection from dkliban's description earlier 15:13:06 <dkliban> heh 15:13:16 <ggainey> the general-security-rule is to protect auth-info more than Other Stuff, mostly because even thye people you trust can't be trusted :) - the rabbit-hole does eventually have a bottom, but this isn't it 15:13:18 <ggainey> hehehe 15:13:20 <bmbouter> rbac could have a "use a remote" permission, but it wouldn't allow you to see some fields and not others 15:13:28 <bmbouter> and rbac is well suited for this 15:13:38 <ggainey> yeah, field-level RBAC is...rather a PITA 15:13:46 <ggainey> but, could be done I guess 15:14:08 <bmbouter> we need to keep in mind the practical issues of having openapi schema's try to have definitions of objects with conditional fields ... it's very hard and confusing 15:14:16 <ggainey> bmbouter: RE "despite rejection" - well, this is what we strive for, right? being able to change each other's minds? :) 15:14:23 <ggainey> yeah 15:14:31 <daviddavis> not me 15:14:32 <daviddavis> jk 15:14:41 <dkliban> bmbouter: i don't think we would want the schema to have conditional fields. i think we would simply want some fields returned as null. 15:14:44 <bmbouter> :) 15:14:55 <bmbouter> dkliban: well that's the workaround that has problems with it 15:15:03 <ggainey> so, lemme back up - How much work is it to make these secret fields? how often will that really bite users? how har dis it to puty warnings in the related docs? 15:15:25 <bmbouter> making the fields is easy, but the usability impact is not 15:15:28 <ggainey> good lord, and why can't I type today? 15:15:29 <dkliban> ggainey: we have the secret fields already for the client_key and client_cert 15:15:47 <daviddavis> ggainey: I thought that was your southern accent 15:15:47 <bmbouter> and those would also be handled in this same way, rbac 15:16:04 <dkliban> that was my understanding also bmbmouter 15:16:13 <ggainey> :P 15:16:19 <dkliban> bmbouter: so what problems do you see with the workaround? 15:16:29 <bmbouter> the issue wiht secretcharfields is a) they are not usable they require more work from the user b) they are insecure also because we don't use salts c) rbac is a better solution anyway 15:17:10 <ggainey> so I am unclear on c), I don't think RBAC will help unless/until we get to field-level RBAC. 15:17:32 <ggainey> but not using salts makes this not-security, and I'd rather have plaintext than pretend-security 15:17:46 <bmbouter> dkliban: the read-then-write-whoops problem still exists if we rewrite the data to null on READ 15:18:15 <bmbouter> ggainey: having two personas I think would resolve it a) rbac role to read a remote (all fields or none) b) rbac role to use but not read 15:18:39 <ggainey> ah kk 15:18:52 <bmbouter> and that use aligns well with openapischema also 15:19:24 <x9c4> Is read-than-write a thing for users without full access to the object? 15:19:24 <ggainey> RE the oops issue - security is def inconvenient - the number of times security-related-bugs get closed with "yes. it's painful if you do that. stop doing it. NOTABUG" is...large. :) 15:20:12 <dkliban> x9c4: i would expect users that can't see those fields, to not be able to modify that resource 15:20:17 <dkliban> bmbouter: ^ 15:20:18 <bmbouter> defining object partial access is hard and has usability issues overall 15:20:24 <ggainey> yup 15:20:31 <ggainey> def concur 15:20:48 <bmbouter> and we don't have a solid use case defining it as the only solution 15:20:52 <x9c4> Yes, and not beeing able to write circumvents any read-than-write-oops 15:21:17 <bmbouter> yes but then we end up with split serializers, that's what I mean when I say hard 15:21:30 <dkliban> time check ... we have 9 minutes 15:21:37 <ggainey> ah right 15:21:37 <bmbouter> rbac or not we could split the remote serializers and have some users use some and others others but this is going to get complicated fast 15:21:46 <x9c4> I mean if you cannot see the password, but change the URL, you can leak the password. 15:22:01 <dkliban> x9c4: i agree 15:22:09 <bmbouter> wow I never thought of that 15:22:21 <x9c4> So being able to write should imply full read access. 15:22:21 <bmbouter> hand the password to meeeeeee 15:22:25 <dkliban> yep 15:22:39 <ggainey> ok, so I'm just going to put this out there - I think having these as secretfields is worth the useability issues, both from a 'real' and a 'perceived' security stance - *BUT*, it depends on whether secretfields are actually keeping their content secret 15:22:42 <x9c4> And then there is no need to split the serializer. 15:23:08 <bmbouter> so my proposal is to have one serializer and not split it, do away with secret char fields, and let rbac do the rest 15:23:13 <x9c4> salting them should be fairly easy. 15:23:27 <bmbouter> it's easy for us, not easy for users their verification step becomes harder 15:23:43 <dkliban> and how do they provide the salt? 15:23:54 <dkliban> how do they know what salt to use when verifying 15:24:08 <dkliban> it seems complicated 15:24:09 <bmbouter> we select it server side so theyw ould have to read salt and then compute hash(salt + orig_password) == hashed_password 15:24:31 <dkliban> so it's ok to give out the salt "? 15:24:35 <bmbouter> it's more work and it's going to be error prone because of the additonal steps which if you mess any of it up as a user lead you to an incorrect 15:24:43 <x9c4> you provide salt:hash to the user. 15:24:44 <bmbouter> it is safe to give out the salt 15:24:50 <dkliban> gotcha 15:24:56 <ggainey> yeah 15:25:14 <bmbouter> an attacker would know what to recompute the password with, but they would have to recompute it for that psecific salt 15:25:29 <bmbouter> so they can't use a pre-generated well known table, they have to make a custom table 15:25:48 <x9c4> And a different one for each password. 15:25:54 <dkliban> gotcha 15:26:09 <ggainey> yupyup 15:26:28 <dkliban> it sounds like we are not ready to make a decision 15:26:49 <dkliban> and our time is almost up for today 15:27:11 <dkliban> what's our next step? 15:27:21 <dkliban> we need to fix this write_only fields bug soon 15:27:23 <bmbouter> more discussion is all I can see 15:27:23 <dkliban> very soon 15:27:49 <ggainey> yeah, that's my concern - we're broken *now*, and rbac isn't going to help for a while 15:28:15 <bmbouter> pulp is already not safe for multi-user as is I don't think exposing them is going to make it worse 15:28:26 <dkliban> agreed 15:29:34 <x9c4> I thought pulp is not multi-user. There is only admin. 15:29:48 <x9c4> And users come bac with rbac 15:29:49 <ggainey> well, I'm going to go on record as a -0 for 'leave them plaintext' - I don't like it, but not at the stop-the-presses level 15:30:21 <x9c4> I copy that ggainey 15:31:13 <ggainey> mostly because we have, as noted, way bigger fish to fry on the security front :) 15:31:14 <bmbouter> the thing is we would need a counterproposal and all of the ways we've contemplated resolving it come with even more issues 15:31:38 <ggainey> I'd make them secret, and eat the useability issues as doc 15:31:42 <bmbouter> ok I gotta run, this has been a great discussion ty for all the thought and energy 15:31:48 <ggainey> yessir! 15:31:59 <x9c4> thank you! 15:32:36 <dkliban> we can end open floor 15:33:03 <fao89> #endmeeting 15:33:03 <fao89> !end