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