CertGuard

Is this really specific to RPM content only? If not, perhaps this content-guard should be contributed by a separate plugin?

I think it's more broadly useful to other plugins. I also think that until another plugin actually wants to use it, shipping it along with RPM is a very easy thing to do now. The packaging, release bumping, release note-ing, travis overhead can be a lot to do.

When we do go to make it, it's own package and repo, I highly recommend using cookiecutter which is how I generated the generic package for the pulp_streamer.

I had some questions about where the cert will be checked, and if we are sure that Pulp needs to provide custom code to do that type of checking?

In terms of where the checking is happening, I've been wondering lately about if Pulp should be doing cert validation in its WSGI process or outside of it. In Pulp2 the WSGIAccessScript was code Pulp provided but it was run "outside" of the Pulp WSGI process. Or are we validating the cert "inside" the Pulp WSGI process in Pulp's Django view code?

Also does Pulp have to provide code on how to check an OidCertificateGuard or can Apache validate an OidCertificateGuard like a nomral cert without Pulp providing a custom WSGIAccessScript?
I have the same quesiton for nginx as well.

It's been my understanding that the primary motivation behind pulp3 ContentGuards was to provide content protection in a way that was independent of the web server. Mainly, that complicated apache/nginx configurations and access scripts would not be necessary. To fully achieve this, it seems that an SSL based ContentGuard should have the capability to validate the certificate in addition to the specialized things such as OID matching. I would expect the certificate validation to be enabled/disabled through the guard attributes. When content protection starts to require mod-ssl configurations and/or access scripts, I no longer see the value of ContentGuards.

jortel@redhat.com wrote:

It's been my understanding that the primary motivation behind pulp3 ContentGuards was to provide content protection in a way that was independent of the web server. Mainly, that complicated apache/nginx configurations and access scripts would not be necessary. To fully achieve this, it seems that an SSL based ContentGuard should have the capability to validate the certificate in addition to the specialized things such as OID matching. I would expect the certificate validation to be enabled/disabled through the guard attributes. When content protection starts to require mod-ssl configurations and/or access scripts, I no longer see the value of ContentGuards.

I totally agree with this reasoning. So this means authorization for content guards are checked "inside" Pulp's Content app.

Is the plan to only use the cryptography Python library mentioned in the ticket? That is a Python dependency so that I think would work well.

Looking into the cryptography package, it does not seem to support certificate validation.

[1] https://github.com/pyca/cryptography/issues/2381

In discussing making this its own python package that ships separately from RPM, here are some questions we came up with:

1. What will the PyPI package name be? e.g. for the streamer it's pulp_streamer
2. What will the python package path be? e.g. for the streamer it's pulpcore.streamer
3. What will the repo name be? I recommend the same as (1)
4. Which github team will have write perms to that repo?
5. Where will issues for it be filed?

bmbouter wrote:

In discussing making this its own python package that ships separately from RPM, here are some questions we came up with:

1. What will the PyPI package name be? e.g. for the streamer it's pulp_streamer

pulp_oidguard

2. What will the python package path be? e.g. for the streamer it's pulpcore.streamer

pulp_oidguard

3. What will the repo name be? I recommend the same as (1)

pulp_oidguard

4. Which github team will have write perms to that repo?

I recommend we have a new team of 2-3.

5. Where will issues for it be filed?

My first thought is a new project in pulp.plan.io but wondering if we should consider just using github issues.

@jortel, all those answers look great, ty.

+1 to using Redmine as a tracker for consistency. Let me know if you need any help setting that up, there are a few strange configuration points.

Let's consider an attribute (setting) on the guard to enable/disable OID/path matching. This supports the guard also being useful to users only needing the client certificate validation part. Given this, I wonder if the name should be more focused on SSL/certificate (more broadly) and less on the OID/path matching. Perhaps: pulp_sslguard would be more appropriate.

Thoughts?

jortel@redhat.com wrote:

Let's consider an attribute (setting) on the guard to enable/disable OID/path matching. This supports the guard also being useful to users only needing the client certificate validation part. Given this, I wonder if the name should be more focused on SSL/certificate (more broadly) and less on the OID/path matching. Perhaps: pulp_sslguard would be more appropriate.

Thoughts?

+1 to a setting to disable the OID/path matching. I think it should by default do the checking so that could turn it off.

Renaming I think makes sense. I really like the "certificate" or "cert" in the name over SSL because strictly speaking we're not doing SSL. Maybe pulp-certguard or pulp-cert-guard which would be either pulp_certguard or pulp_cert_guard respectively as package names?

What do you think?

The name pulp-certguard (or pulp_certguard) works for me.

That works for me also.