14:00:47 <dkliban> #startmeeting Pulp Triage 2019-12-05 'Content Signing'
14:00:47 <dkliban> !start 'Content Signing'
14:00:47 <dkliban> #info dkliban has joined triage
14:00:47 <pulpbot> Meeting started Thu Dec  5 14:00:47 2019 UTC.  The chair is dkliban. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:47 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:47 <pulpbot> The meeting name has been set to 'pulp_triage_2019-12-05_'content_signing''
14:00:47 <pulpbot> dkliban: dkliban has joined triage
14:00:55 <misa> #info misa has joined triage
14:00:55 <misa> !here
14:00:55 <pulpbot> misa: misa has joined triage
14:01:00 <dkliban> https://docs.google.com/document/d/1HSrRduFYuidhbc8ISjUnkb3IXk6FnJ2iXEqa4vDC-pA/edit?usp=sharing
14:01:16 <dkliban> ^ there are the use cases we discussed so far and the notes from the last meeting
14:01:31 <ggainey> #info ggainey has joined triage
14:01:31 <ggainey> !here
14:01:31 <pulpbot> ggainey: ggainey has joined triage
14:03:04 <misa> This is what we're using for signing stuff: https://github.com/sassoftware/relic
14:04:09 * dkliban reads
14:05:01 <dkliban> misa: so in this case you have an external service that does all the signing
14:05:03 <misa> client/server signing infrastructure. The server can talk to an HSM (hardware security module)
14:06:00 <misa> dkliban: yep. Conceptually similar to gpg itself in the end. However, unlike gpg (or most gpg implementations), you have no access to the private key material
14:06:33 <misa> setting up one of these belongs to the Administrator role
14:07:18 <daviddavis> #info daviddavis has joined triage
14:07:18 <daviddavis> !here
14:07:18 <pulpbot> daviddavis: daviddavis has joined triage
14:08:10 <dkliban> daviddavis: ttereshc: we are discussing https://github.com/sassoftware/relic  .... that's a service that signs packages
14:08:34 <dkliban> one of the use cases that we discussed last time was using something like ^ to perform the signing
14:08:35 <misa> To resume the discussion: maybe what you want are high-grade/production and low grade/dev/testing scenarios
14:08:50 <bmbouter> #info bmbouter has joined triage
14:08:50 <bmbouter> !here
14:08:50 <pulpbot> bmbouter: bmbouter has joined triage
14:09:11 <ttereshc> #info ttereshc has joined triage
14:09:11 <ttereshc> !here
14:09:11 <pulpbot> ttereshc: ttereshc has joined triage
14:09:12 <misa> To resume the discussion: maybe what you want are high-grade/production and low grade/dev/testing scenarios
14:09:30 <misa> (should we wait for a few more minutes?)
14:10:00 <daviddavis> no, I think we're good
14:10:24 <dkliban> yeah ... let's continue
14:11:19 <dkliban> misa: we want to support use cases where the signing is done externally and signing is performed by Pulp
14:11:45 <dkliban> and perhaps that's what you mean by high-grade (external) and low-grade (internal to pulp)
14:11:46 <misa> As we learned from docker (v2 schema 1 manifests are signed), a signature with a random key is not much better than a checksum
14:12:14 <misa> the value of signing is in the trust of the key
14:13:10 <misa> so as a consumer of whatever, I need to be able to tell with a certain amount of certainty that: 1) I trust signatures by this key; 2) the infrastructure hosting this key is reasonably secure
14:14:17 <dkliban> we discussed last time that we there is desire to have Pulp hostingthe private key
14:14:18 <misa> a user uploading their key and then signing packages is ok for testing, but inherently low-grade
14:15:01 <dkliban> misa: what about an administrator putting the key in place and then signing with it?
14:15:58 <misa> definitely higher grade, yes, in as much as it comes to securing the private key
14:17:07 <dkliban> bmbouter: you were interested in the use case wehre the REST API user uploads a private key that will be used for signing
14:17:40 <misa> RBAC plays a role in this whole thing. Let's take the use case of RHEL. If any developer can upload a package and have it signed with the RHEL8 signing key (trusted by millions of users), it doesn't matter that the key lives in an HSM, the process up to the HSM is flawed since it imparts trust to packages that are not verified
14:18:44 <bmbouter> yes I was thinking more about that use case
14:19:14 <misa> but I think that's a different discussion. I was only offering that to describe why it's hard to categorize high grade/low grade because it's not just about key storage. Anyway.
14:19:15 <bmbouter> and also misa's proposal, the main aspect about misa's proposal is that private key provider/configurer is the deployer of pulp
14:19:45 <bmbouter> so I was thinking that misa's use case is probably the best starting point for 3.1
14:20:14 <misa> If we come up with the concept of a signing service, and allow more than one signing service to be configured (by an Administrator), then we need to define the interface to a signing service
14:20:19 <dkliban> but i just heard a concern about everyone being able to sign packages with the same key
14:21:10 <misa> a signing service could be as simple as a bash script that is being fed a number of environment variables, filled in by the plugin, and that invokes gpg in its easiest form
14:21:18 <dkliban> misa: so the signing service probably needs to b only available if the user has the permissions to use it
14:21:27 <misa> right
14:21:30 <bmbouter> agreed
14:21:33 <bmbouter> RBAC will help w/ this
14:21:38 <bmbouter> as I think I read ^ also
14:21:44 <dkliban> yes
14:21:49 <bmbouter> +1 to that
14:22:15 <bmbouter> for the RBAC to layer onto these objects they need to be in the db
14:22:35 <dkliban> yes, there needs to be a DB record that represetns the signing service
14:22:40 <bmbouter> at least a representation of how to connect to it, I'm not suggesting the keys themselves
14:22:44 <bmbouter> +1
14:23:23 <misa> Here's a proposal: administrator is the only one that can add services, using a command line tool
14:23:52 <bmbouter> pulp_ansible can use this approach at least for the near-term
14:23:55 <misa> the tool has commands like add, remove, grant (for RBAC)
14:24:30 <misa> it validates that the command line for signing does exist, and pushes a record in the DB
14:24:41 <bmbouter> can we leave the RBAC mechanisms a bit abstract because we want it to be consistent w/ the other RBAC assignments
14:24:52 <bmbouter> so command line tool would add/remove signing services
14:25:15 <dkliban> As an administrator, I can use django-admin to add a signing service to Pulp.
14:25:24 <bmbouter> add/remove +1
14:25:29 <dkliban> yes, both
14:25:32 <bmbouter> ja
14:25:39 <misa> sounds good
14:25:40 <ttereshc> да
14:25:47 <bmbouter> kekeke
14:26:09 <dkliban> should we discuss how the signing service should be described?
14:26:23 <bmbouter> yes, misa does your proposal outline aspects we can use?
14:26:34 <misa> it could :-)
14:26:44 <bmbouter> if not then let's spitball here
14:26:54 <misa> let's finish the personas
14:26:58 <bmbouter> sure
14:27:10 <misa> repository administrator configures signing service for the repo they created
14:27:25 <misa> RBAC may deny them from adding a service
14:27:29 <dkliban> +1
14:28:00 <misa> pulp may (not day 0) provide a plugin for managing keys remotely
14:28:12 <bmbouter> +1, repository administrator being the end-user, someone who has the RBAC permissions to both that repo and that signing service
14:28:52 <misa> administrator may configure a signing service that uses the private keys managed by the hypothetical pulp plugin
14:29:17 <misa> so the plugin and its service are completely optional
14:29:27 <bmbouter> yup over time that would be cool yes
14:29:34 <misa> bmbouter: I don't understand the ansible use case, will this cover it?
14:32:47 <bmbouter> misa: it will cover it for the near term
14:33:19 <bmbouter> it's an acceptable downside, but this issue is this doesn't scale to a large number of users/keys
14:33:34 <bmbouter> but that's not unique to pulp_ansible
14:33:51 <bmbouter> and not something we need to focus on resolving in the nearterm (the more I thought about it)
14:34:07 <dkliban> for 3.1 we can focus on providing a single Signing Service type
14:34:20 <dkliban> it would be similar to what is in pulp_deb now.
14:34:34 <daviddavis> +1
14:34:39 <misa> cool.
14:34:55 <bmbouter> +1
14:34:59 <misa> In terms of what a signing service does:
14:35:36 <misa> In our case, we have one service configured with multiple signing keys. The wrapper bash script around relic determines which key to use based on the repository name
14:36:17 <misa> because we have a dev/test/prod scenario, and we don't want dev repos' metadata to be signed with the prod key, for instance
14:37:12 <misa> This is the reason https://github.com/pulp/pulp_deb/blob/2-master/README.md#signing-support documents that GPG_REPOSITORY_NAME will be filled in by pulp_deb and passed to the signing service
14:37:30 <misa> The plugin writer may add extra variables, of course
14:38:01 <misa> So I think there are, once again, multiple layers/flavors/use cases for this.
14:38:05 <bmbouter> I expect the application code would be enforcing the repo<->key relationship
14:38:42 <misa> 1. administrator configures signing service to use exactly one key (even though there are multiple keys in the store)
14:39:25 <misa> 2. administrator leaves the key blank, and lets the signing service pick a key based on a number of environment variables (like repository name, for instance)
14:39:54 <misa> 3. administrator leaves the key blank and also allows for the user to specify the key to be used for signing
14:41:06 <misa> 4. repository administrator defines the key to be used for their repo
14:41:33 <misa> 5. repository administrator defines a list of keys that can be used, that a content producer can specify for signing their packages
14:41:38 <bmbouter> for pulp_ansible's purposes we want the admin configuring the signing service/keys
14:41:52 <bmbouter> yes that sounds like (5)
14:42:27 <misa> so there's like service-level config, repo-level config, content producer config
14:42:40 <bmbouter> I'm not understanding
14:43:00 <misa> my last statement?
14:43:49 <bmbouter> are we listing options, or are you saying all of these should be done?
14:43:57 <dkliban> What i think he meant was that the Administrator configured a Signing Service. When the repo admins adds that service to a repository, he also provides configuration.
14:44:12 <misa> right.
14:44:40 <bmbouter> I don't think I have a clear idea of a repo admin persona
14:45:08 <dkliban> repo admin is someone that creates the repository and assigns it a specific signing service
14:45:19 <dkliban> it may or may not be the same person as the Administrator
14:45:54 <misa> repo admin also possibly limits the signing keys the signing service has
14:46:18 <bmbouter> I think that's part of the confusion to me, in the case the "repo admin" and the "Administrator" are not the same how can the repo admin provide additoinal configs tothe box they can't access
14:46:38 <bmbouter> having the Admin define all the things and have RBAC limit who can use them did make sense to me
14:46:38 <misa> bmbouter: think whitelists
14:46:51 <misa> bmbouter: admin says service has keys A, B, C
14:47:12 <bmbouter> sounds good
14:47:16 <misa> bmbouter: repo admin says content producer can only use B, C, D
14:47:25 <bmbouter> who is content producer?
14:47:27 <misa> D is invalid because the admin didn't specify it
14:47:34 <misa> bmbouter: person uploading artifact, for instance
14:47:43 <bmbouter> k sounds good
14:48:00 <misa> then content producer may pick between B and C
14:48:20 <bmbouter> ok I'm understanding
14:48:36 <bmbouter> but aren't B, C, and D "references" to objects the admin configured
14:48:45 <bmbouter> so how is the repo admin specifying a reference to something that doesn't exist?
14:49:05 <misa> bmbouter: don't know :-)
14:49:09 <dkliban> bmbouter: for the most basic signing service these are just strings
14:49:18 <misa> bmbouter: I was assuming they were GPG key fingerprints, for instance
14:49:22 <misa> one may mistype one
14:49:46 <bmbouter> ok thinking of them as fingerprints makes it more clear
14:49:46 <misa> or maybe A, B, C, D were initially configured, but the admin retired D.
14:50:08 <misa> but repo admin didn't update the config, so what was once a valid ref to D is no longer valid
14:50:18 <bmbouter> ok this sounds good
14:50:35 <bmbouter> admins configure keys/signing and users reference them w/ fingerprints
14:50:42 <misa> right
14:50:50 <bmbouter> sweet
14:51:09 <bmbouter> why have more than 1 signing key per repo?
14:51:12 <misa> to summarize that case for a (admin, repo admin, content producer): ([A, B, C], [B, C], [B])
14:51:38 <misa> bmbouter: donno. I suspect one may want that
14:52:28 <dkliban> i am having a hard time picturing that scenario also
14:52:32 <misa> pulp-gpg case could be that the admin allows any available keys, but the repo admin limits to a number of them, etc.
14:53:05 <dkliban> but i do want to summarize the use cases we went over so far today ...
14:53:13 <bmbouter> yup
14:53:28 <dkliban> As an administrator, I can use django-admin to add/remove a Signing Service.
14:54:15 <dkliban> As a REST API user (repo admin), I can assing a Signing Service to a repository and provide a key signature as additional configuration.
14:54:59 <dkliban> As a REST API user uploading content into a repository, I can specify a key signature of the key to use when signing the uploaded content.
14:55:15 <misa> Sounds good
14:55:27 <bmbouter> it's a good recap
14:55:31 <bmbouter> I'm not sold on the last one
14:55:45 <misa> bmbouter: I think the use case would be something like rawhide
14:55:45 <bmbouter> but for our time today it's great content/discussion
14:56:10 <misa> developer uploads package, signs it with his own key
14:56:43 <misa> I can't think why this is useful
14:56:54 <dkliban> i will add these to the document along with a summary of today's discussion
14:56:58 <misa> but I think for a while that's how it was working, before there was a centralized build system
14:57:06 <bmbouter> yeah we can include it for now anyway
14:57:17 <bmbouter> I don't want content providers to have to think about keys for pulp_ansible
14:57:28 <dkliban> bmbouter: i think it's optional
14:57:49 <misa> The discussion about ABC -> BC -> B was only to describe that admins may restrict key selection
14:57:52 <dkliban> bmbouter: repo admin can set a single key to use
14:58:08 <bmbouter> pulp_ansible will be set then
14:58:21 <bmbouter> but I don't understand how it's useful generally
14:58:31 <bmbouter> that's ok though I'll think about it
14:58:57 <misa> dkliban: in the hypothetical case of rawhide/dev keys, that's when you may want to have more than one key configured by repo admin
14:59:41 <dkliban> misa: yes, and the key might be selected based on the user that is uploading the content
14:59:53 <misa> yeah, something like that
15:00:05 <dkliban> alright ... i am going to end the meeting now
15:00:12 <dkliban> i'll schedule another discussion for next week
15:00:20 <ttereshc> ty!
15:00:26 <dkliban> #endmeeting
15:00:26 <dkliban> !end