https://pantsbuild.org/ logo
#development
Title
# development
h

hundreds-father-404

09/26/2022, 9:20 PM
@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

witty-crayon-22786

09/26/2022, 9:25 PM
i do not. @average-vr-56795 might…?
h

hundreds-father-404

09/26/2022, 9:25 PM
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

witty-crayon-22786

09/26/2022, 9:28 PM
…ah. sorry for the ping Daniel.
h

hundreds-father-404

09/26/2022, 9:30 PM
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

average-vr-56795

09/26/2022, 9:47 PM
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

hundreds-father-404

09/26/2022, 9:50 PM
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

average-vr-56795

09/26/2022, 10:13 PM
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

hundreds-father-404

09/26/2022, 10:56 PM
c

curved-television-6568

09/27/2022, 12:05 AM
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

hundreds-father-404

09/27/2022, 4:26 PM
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

curved-television-6568

09/27/2022, 4:28 PM
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