14:30:58 <fao89> #startmeeting Pulp Triage 2020-05-08
14:30:58 <fao89> #info fao89 has joined triage
14:30:58 <fao89> !start
14:30:58 <pulpbot> Meeting started Fri May  8 14:30:58 2020 UTC.  The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:30:58 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:30:58 <pulpbot> The meeting name has been set to 'pulp_triage_2020-05-08'
14:30:58 <pulpbot> fao89: fao89 has joined triage
14:31:04 <bmbouter> #info bmbouter has joined triage
14:31:04 <bmbouter> !here
14:31:05 <pulpbot> bmbouter: bmbouter has joined triage
14:31:08 <daviddavis> #info daviddavis has joined triage
14:31:08 <daviddavis> !here
14:31:08 <pulpbot> daviddavis: daviddavis has joined triage
14:31:11 <fao89> !next
14:31:12 <pulpbot> fao89: 5 issues left to triage: 6687, 6670, 6669, 6667, 6658
14:31:12 <fao89> #topic https://pulp.plan.io/issues/6687
14:31:13 <pulpbot> RM 6687 - daviddavis - NEW - Return Docs link to main navigation
14:31:14 <pulpbot> https://pulp.plan.io/issues/6687
14:31:30 <dkliban> #info dkliban has joined triage
14:31:30 <dkliban> !here
14:31:30 <pulpbot> dkliban: dkliban has joined triage
14:31:34 <daviddavis> I opened this for some feedback
14:32:00 <bmbouter> what you're saying makes sense
14:32:00 <fao89> can someone add me on infrastructure project? it will help me triage issues
14:32:13 <dkliban> fao89: sure
14:32:15 <x9c4> #info x9c4 has joined triage
14:32:15 <x9c4> !here
14:32:15 <pulpbot> x9c4: x9c4 has joined triage
14:32:30 <bmbouter> as an aside we track website issues here https://github.com/pulp/pulpproject.org/issues
14:32:39 <daviddavis> oh right
14:32:41 <ggainey> #info ggainey has joined triage
14:32:41 <ggainey> !here
14:32:41 <pulpbot> ggainey: ggainey has joined triage
14:32:42 <bmbouter> which likely is not where we should track them
14:32:58 <daviddavis> I'll move it
14:33:04 <bmbouter> daviddavis: would you want to email pulp-dev w/ this quesiton and/or link?
14:33:12 <daviddavis> sure, will do
14:33:14 <bmbouter> mcorr: fyi ^
14:33:44 <dkliban> fao89: added
14:33:57 <daviddavis> so let's skip
14:33:59 <fao89> thank you!
14:34:05 <fao89> !skip
14:34:06 <fao89> #topic https://pulp.plan.io/issues/6670
14:34:06 <pulpbot> fao89: 4 issues left to triage: 6670, 6669, 6667, 6658
14:34:07 <pulpbot> RM 6670 - fao89 - NEW - pulp-operator is not exhibiting logs when getting 500
14:34:08 <pulpbot> https://pulp.plan.io/issues/6670
14:34:25 <fao89> it was a problem with galaxy CI
14:34:36 <bmbouter> this is valid but we're not fixing pulp-operator issues atm, so I propose accept
14:34:49 <fao89> #idea Proposed for #6670: Leave the issue as-is, accepting its current state.
14:34:49 <fao89> !propose accept
14:34:49 <pulpbot> fao89: Proposed for #6670: Leave the issue as-is, accepting its current state.
14:34:52 <dkliban> +1
14:35:12 <fao89> #agreed Leave the issue as-is, accepting its current state.
14:35:12 <fao89> !accept
14:35:12 <pulpbot> fao89: Current proposal accepted: Leave the issue as-is, accepting its current state.
14:35:13 <fao89> #topic https://pulp.plan.io/issues/6669
14:35:14 <pulpbot> fao89: 3 issues left to triage: 6669, 6667, 6658
14:35:15 <pulpbot> RM 6669 - mdepaulo@redhat.com - NEW - pulp_installer does not support plugins having both the version and the upgrade vars specified
14:35:16 <pulpbot> https://pulp.plan.io/issues/6669
14:35:40 <dkliban> mikedep333: should we accept or accept and add to sprint?
14:36:00 <mikedep333> ~here
14:36:08 <mikedep333> Add to sprint please.
14:36:11 <fao89> #idea Proposed for #6669: accept and add to sprint
14:36:11 <fao89> !propose other accept and add to sprint
14:36:11 <pulpbot> fao89: Proposed for #6669: accept and add to sprint
14:36:15 <dkliban> +1
14:36:17 <bmbouter> +1
14:36:18 <mikedep333> #info mikedep333 has joined triage
14:36:18 <mikedep333> !here
14:36:18 <pulpbot> mikedep333: mikedep333 has joined triage
14:36:19 <fao89> #agreed accept and add to sprint
14:36:19 <fao89> !accept
14:36:19 <pulpbot> fao89: Current proposal accepted: accept and add to sprint
14:36:20 <pulpbot> fao89: 2 issues left to triage: 6667, 6658
14:36:20 <fao89> #topic https://pulp.plan.io/issues/6667
14:36:21 <pulpbot> RM 6667 - mdepaulo@redhat.com - NEW - Create larger pulp_installer docs
14:36:22 <pulpbot> https://pulp.plan.io/issues/6667
14:36:38 <dkliban> convert to task?
14:36:44 <fao89> +1
14:36:49 <mikedep333> yes
14:36:53 <mikedep333> convert to task
14:36:55 <fao89> #idea Proposed for #6667: convert to a task
14:36:55 <fao89> !propose other convert to a task
14:36:55 <pulpbot> fao89: Proposed for #6667: convert to a task
14:37:00 <fao89> #agreed convert to a task
14:37:00 <fao89> !accept
14:37:00 <pulpbot> fao89: Current proposal accepted: convert to a task
14:37:01 <pulpbot> fao89: 1 issues left to triage: 6658
14:37:01 <fao89> #topic https://pulp.plan.io/issues/6658
14:37:02 <pulpbot> RM 6658 - xenlo - NEW - Pain points when trying Pulp3 for the first time
14:37:03 <pulpbot> https://pulp.plan.io/issues/6658
14:37:32 <dkliban> let's accept ... we are going to improve the installer docs based on this feedback
14:37:38 <dkliban> but it's not meant to go directly on the sprint
14:37:40 <mikedep333> Agreed
14:37:42 <fao89> #idea Proposed for #6658: Leave the issue as-is, accepting its current state.
14:37:42 <fao89> !propose accept
14:37:42 <pulpbot> fao89: Proposed for #6658: Leave the issue as-is, accepting its current state.
14:37:50 <fao89> #agreed Leave the issue as-is, accepting its current state.
14:37:50 <fao89> !accept
14:37:50 <pulpbot> fao89: Current proposal accepted: Leave the issue as-is, accepting its current state.
14:37:51 <pulpbot> fao89: No issues to triage.
14:38:10 <fao89> open floor!
14:38:48 <dkliban> we need to finish the discussion about what we want to do about the secret char fields.
14:38:55 <dkliban> or at least continue it
14:38:55 <bmbouter> we do
14:39:37 <fao89> somewhat related with it, I don't know what to do with my write_only fields PR, should I close it?
14:39:50 <dkliban> fao89: this is all part of that discussion
14:40:00 <dkliban> fao89: please don't close it yet
14:40:08 <dkliban> my biggest concern right now is that the client bindings are unable to use the username and password fields on the Remote
14:40:28 <x9c4> I think, we concluded, that whoever can write to a resource can read all of it.
14:40:30 <dkliban> which makes pulp_container plugin unable to sync from registries that require authentication ... which is almost all of them
14:40:58 <dkliban> x9c4: that's right
14:41:04 <dkliban> so let's go back to that
14:43:10 <dkliban> if we start returning the values of these 'secret' fields, what kind of warning should we provide our users during the time without RBAC?
14:43:33 <fao89> with bindings docs issue, and this write_only fields issue, it is leading me to conclude bindings should have github repos
14:44:01 <bmbouter> dkliban: I think we should highlight in the release notes that at this time pulp is only safe as a single-user system
14:44:31 <x9c4> "Do not let anyone stand behind you while operating pulp!"
14:44:36 <bmbouter> which is already the case but it's so important we can say it again <blink>single user only!</blink>
14:44:37 <dkliban> lol
14:45:39 <bmbouter> the main thing I've realized is that any secretCharField w euse can be easily compromised by someone updating the url
14:45:39 <ggainey> hehehe
14:45:50 <dkliban> i agree
14:46:01 <bmbouter> and the solution to limiting who can update that is rbac
14:46:13 <x9c4> Does the api allow to specify field i do not want to see in the request?
14:46:28 <dkliban> x9c4: yes, you can filter out fields
14:46:40 <bmbouter> but the apispec does not
14:46:49 <bmbouter> openapi v2 specifically AIUI
14:47:49 <dkliban> that's right
14:48:36 <dkliban> bmbouter: but that shouldn't really be a problem. a user that can update the resource should be able to read all of it anyway.
14:49:33 <bmbouter> dkliban: I agree but to answer x9c4's question
14:49:57 <bmbouter> actually your answering the question asked, I was not
14:50:40 <x9c4> So there is a way to prevent evesdropping of already saved credentials if you do not use the tools provided.
14:51:04 <dkliban> so the big question still remains, are we comfortable with returning the values for username and password fields (and similar ones) and telling the users that pulp is only to be used by a single user for now?
14:51:20 <x9c4> But in the other direction (to set them) we transfer then unecrypted anyway.
14:51:52 <dkliban> x9c4: hopefully they will be set over https
14:52:28 <bmbouter> yes pulp can be configured with https (I've been doing this lately for certguard)
14:53:01 <bmbouter> I have an installer branch that configures self-signed certs for nginx and httpd which work
14:53:18 <x9c4> Sure. But i think that means, we are not really adding security by hiding them on the way out. (that should be ssl too.)
14:54:16 <bmbouter> x9c4: I agree https is needed I think the installer team probably needs to discuss that goal soon
14:54:30 <bmbouter> regardless of what we hide on the response if the request is insecure it's not safe
14:55:50 <dkliban> true
14:56:07 <bmbouter> but that's a separate issue because users could do that today
14:56:59 <dkliban> agreed
14:59:19 <x9c4> So SecretCharFields look like a security improvement, but really arent. If we can agree on that, let's remove them. And sure keep telling users, to thoroughly restrict access to the API.
15:00:36 <bmbouter> that is the conclsuion I've reached
15:00:54 <dkliban> yep
15:01:15 <dkliban> i am convinced that SecretCharField is feaux security
15:01:50 <x9c4> dalley++
15:01:50 <pulpbot> x9c4: dalley's karma is now 245
15:02:52 <bmbouter> daviddavis, ggainey, dalley: wdyt about this ^?
15:04:53 <ggainey> bmbouter: that works for me
15:04:58 <daviddavis> +1 from me
15:05:01 <ggainey> (sorry, had to take a sec to catch up)
15:05:46 <bmbouter> np, I don't want to move on w/o you all
15:06:35 <bmbouter> so in terms of implementing this change, did secretCharField ever get merged or used anywhere?
15:07:48 <dkliban> bmbouter: yes, it's used for client_cert and client_key
15:09:08 <bmbouter> ok so one issue to specifically remove the use there?
15:09:15 <dkliban> that's right
15:09:24 <dkliban> and the other is updating the PR from fao89
15:09:31 <daviddavis> hey question
15:09:33 <dkliban> yes
15:09:36 <daviddavis> would that break semver?
15:09:54 <dkliban> not if we are saying that this is a bug
15:10:04 <daviddavis> yea I guess we could say we're fixing a bug
15:10:19 <daviddavis> +1 from me
15:10:45 <bmbouter> https://pulp.plan.io/issues/6691
15:11:05 <bmbouter> dkliban: what is the bug related to not seeing those username and password fields?
15:11:25 <bmbouter> I propose we put that on the spring and have it fixed with plaintext responses also along with 6691
15:11:29 <bmbouter> sprint
15:11:45 <dkliban> bmbouter: https://pulp.plan.io/issues/6346 .. on the sprint already
15:11:47 <daviddavis> bmbouter: your task is a bit ambiguous. are we removing the field or just its usage?
15:11:58 <dkliban> both!
15:12:06 <daviddavis> +1 from me
15:13:23 <daviddavis> and +1 to putting it on the sprint
15:14:24 <bmbouter> I added it to the sprint
15:15:06 <bmbouter> so back to fao89 's PR, I think two new PRs should be made one for 6691 and one for 6346, and the write_only field only deal wil the remaining write_only usage outside of those things
15:16:05 <dkliban> bmbouter: ok ... so close the current PR?
15:16:23 <bmbouter> I thought there were a few other places write_only was used outside of these two?
15:16:47 <bmbouter> for cases where the data submitted by the request wasn't actually saved so it couldn't be returned, e.g. the file at upload time
15:16:51 <dkliban> yes, in the Content serializer
15:17:07 <bmbouter> yup
15:17:17 <bmbouter> so more like thin the current open PR down
15:18:37 <daviddavis> I had another issue to look at write_only fields ot see if they could be converted to non write only https://pulp.plan.io/issues/6421
15:18:48 <daviddavis> since many of them are on serializers used only for POST requests
15:19:47 <dkliban> yep
15:20:01 <dkliban> i am going to put a comment on the open PR
15:20:24 <dkliban> to say that this change should simply be limited to making username and password fields not write_only
15:20:42 <dkliban> and that's it ... everything else we will handle with sparate PRs
15:20:48 <daviddavis> +1
15:21:44 <bmbouter> +1
15:22:00 <bmbouter> and the 3.4 relase note needs a big banner on it
15:22:49 <dkliban> https://github.com/pulp/pulpcore/pull/600#pullrequestreview-408316663
15:22:50 <daviddavis> something like "Don't use write_only fields. We don't support them" ?
15:22:50 <bmbouter> Actually we could put it here above the "latest" changelog at all times and do that ahead of cutting the changelog
15:23:52 <bmbouter> https://raw.githubusercontent.com/pulp/pulpcore/master/CHANGES.rst  above the line ".. towncrier release notes start"
15:23:56 <bmbouter> let me file that now
15:24:15 <bmbouter> any suggestions on where else this shoul go are welcome
15:24:43 <dkliban> on bumper sticker!
15:25:08 <dkliban> i am just kidding ... it's friday!
15:25:18 <daviddavis> !friday
15:25:18 <pulpbot> ♪ It's Friday, Friday, gotta get down on Friday ♪
15:25:29 <ggainey> sigh - and here I am in the middle of adding write-only fields to export :(
15:25:31 <ggainey> blargh
15:25:38 <ggainey> i'll figure out how to do it differently
15:26:11 <bmbouter> https://pulp.plan.io/issues/6692
15:26:46 <ggainey> +1
15:27:06 <bmbouter> ggainey: if it's a legit write_only use (as in not for secrecy and also not able to be returned on the subsequent GET) then maybe continue? fao89's PR will need to handle that more broadly by splitting the serializers
15:27:23 <bmbouter> what about grooming 6692 for the sprint?
15:27:27 <ggainey> bmbouter: yeah, I am prob going to leave it as-is for now
15:27:29 <bmbouter> and what other places should thisbe documented?
15:31:15 <dkliban> i am not sure
15:32:07 <bmbouter> I can find a few more places to suggest
15:32:15 <bmbouter> and then maybe we can add to sprint later?
15:32:22 <bmbouter> I'll post back here about it
15:32:22 <dkliban> sounds good
15:32:25 <bmbouter> we should end open floor
15:32:36 <fao89> #endmeeting
15:32:36 <fao89> !end