Opened 6 years ago
Closed 10 months ago
#5445 enhancement closed invalid (invalid)
validate against platform-trusted certificate authorities by default for HTTPS URLs in twisted.web.client.Agent
Reported by: | Glyph | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | web | Keywords: | |
Cc: | jknight, ivank | Branch: | |
Author: |
Description (last modified by )
HTTPS client connections from Agent.request should use the platform's native list of certificate authorities as the trust root by default.
This ticket is only for fixing Agent
to actually point at the certificate store API we come up with; there is another ticket for actually implementing that store which is really the hard part here.
Change History (8)
comment:1 Changed 6 years ago by
Cc: | jknight added |
---|
comment:2 Changed 6 years ago by
Cc: | ivank added |
---|
comment:3 follow-up: 4 Changed 5 years ago by
comment:4 Changed 5 years ago by
Replying to itamar:
I am skeptical that this will happen anytime soon. A more realistic, short term goal is to do what
requests
does: ship the Mozilla CA pack, with a integration point which packagers can point at their own local CA storage location.
I agree, as my recent comments on the ticket related to hostname verification suggest; maybe we should have an interim ticket for doing that.
However, I think it's important to have realistic expectations here: aside from Linux, as I noted on the ticket for the hard part of this problem "local CA storage" is a database with an API to query it, not a filesystem location. Tools to manage trust don't necessarily keep a filesystem directory that we can list in sync.
comment:5 Changed 5 years ago by
Description: | modified (diff) |
---|
Update description to mention the other ticket, which is where the bulk of the work is and where the comments explaining what should be done are.
comment:6 follow-up: 7 Changed 5 years ago by
Owner: | set to Glyph |
---|
The ticket description could still do a better job of explaining what needs to be done. For example, as is, I might just say that it is already possible to point an Agent
at a certificate store using WebClientContextFactory
and the pyOpenSSL Context
APIs. What do you think is necessary beyond that to resolve this ticket?
comment:7 Changed 5 years ago by
Description: | modified (diff) |
---|---|
Owner: | Glyph deleted |
Summary: | certificate validation against natively-configured certificate authorities for HTTPS URLs in twisted.web.client.Agent → validate against platform-trusted certificate authorities by default for HTTPS URLs in twisted.web.client.Agent |
Replying to exarkun:
The ticket description could still do a better job of explaining what needs to be done. For example, as is, I might just say that it is already possible to point an
Agent
at a certificate store usingWebClientContextFactory
and the pyOpenSSLContext
APIs. What do you think is necessary beyond that to resolve this ticket?
Hmm. Good point. The issue here is that this always ought to be done by default; as it was phrased previously this was not clear at all.
comment:8 Changed 10 months ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
Struggling with a resolution status for this: the functionality still isn't quite there, but the API is; however, there's no longer any work left to do in Agent to make this happen, we just have to make platformTrust
smarter.
I am skeptical that this will happen anytime soon. A more realistic, short term goal is to do what
requests
does: ship the Mozilla CA pack, with a integration point which packagers can point at their own local CA storage location.