https://pantsbuild.org/ logo
Join Slack
Powered by
<@U0N6C2Q9F> <@U06A03HV1> do either of you remembe...
# development
h
@fast-nail-55400 @witty-crayon-22786 do either of you remember why we made 
remote_ca_certs_path
a distinct option from 
ca_certs_path
?
👀 1
(Context is trying to figure out the best way to fix CA certs path not working with environments: https://github.com/pantsbuild/pants/issues/16987#issuecomment-1258385192)
w
i do not. @average-vr-56795 might…?
h
It looks like Daniel added 
remote_ca_certs_path
4 years ago, and then @happy-kitchen-89482 added 
ca_certs_path
as a separate option: https://github.com/pantsbuild/pants/pull/10757
w
…ah. sorry for the ping Daniel.
h
FYI, why this matters is that Chris and I found two bootstrap uses of certs paths: 1) connecting to RE server 2) for 
DownloadFile
, which currently always happens on local host, regardless of RE and Docker Those should not support environment targets. It would be convenient, e.g. macOS vs Linux paths may differ, but I don't think we can due to chicken and egg. So, if users need to override, they do so the old way via env vars, cli args, or pants.rc But for subprocesses, like Pex and Twine, we can support an environment-aware option that env targets can safely override
I proposed three options like this:
Copy code
ca_certs_path_engine (or download_files)
ca_certs_path_remote
ca_certs_path_subprocesses
Chris pointed out maybe we can combine those first two options
a
I'm not sure we need multiple paths... I would have thought we'd have one path, which points at somewhere on the local filesystem where pants is getting executed, and we should ferry around those certs to any execution environment we end up using?
Like, "I trust these entities to issue certs" is a very top-level concept, and I don't think we should assume folks have different certs in a docker image - I can't think of a use-case for "My docker image where I execute a process trusts different root entities than my pants process does"
h
and we should ferry around those certs to any execution environment we end up using?
Oh that's an interesting point. Thank you. Can you think of why it would be useful for the certs used to connect to the RE server to be different than what we use for 
DownloadFile
and subprocesses? cc @curved-television-6568, do you remember why you added 
[twine].ca_certs_path
rather than always using 
[GLOBAL].ca_certs_path
?
a
Can you think of why it would be useful for the certs used to connect to the RE server to be different than what we use for 
DownloadFile
and subprocesses?
I don't have any good reason, curious if anyone else doe 🙂
👍 1
h
c
cc @curved-television-6568, do you remember why you added 
[twine].ca_certs_path
rather than always using 
[GLOBAL].ca_certs_path
? (edited)
According to https://github.com/pantsbuild/pants/pull/13593 my reasoning was that you’d likely don’t need to use the twine option which defaults to the global one, but I added it in case the two cert bundles would differ. Maybe overkill/premature feature..?
h
Using Global CA Certs option by default definitely is a good thing. The custom option is probably overkill, but I honestly lack enough real world experience to know if we should remove it. I'll ask in the PR
c
The thing to perhaps support is if you want to publish your python dist with twine to a cheeseshop pypi server with a self signed cert, you’ll need a custom cert bundle with your issuing CA in it, but you may not want to use that same bundle for all purposes as it would add a maintenance burden to keep it up to date with the world.
👍 1
Open in Slack
PreviousNext
Powered by