You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Public repos pass certificate verification using the system's trusted root certificates. Private repos may require a Certificate Authority that is not in the system's trusted root certificates.
Although some users may be able to add CAs system-wide, it is easiest and cleanest to allow setting CAs on a per-repo basis. This way no change system-wide change is necessary in order to use private repos with custom CAs.
The repo.yaml syntax can be extended with a CA string field so users can provide the CA together with the repository information.
If I understand this correctly, we would basically allow setting a CA field in repo.yaml, and then create a custom https client which will only talk to a repo serving a cert form there. Correct?
Yes, the HTTPS client would use the repo.yaml's CA for certificate verification. I'm not sure whether the client should exclusively use the CA or the CA is used in addition to the system-wide trusted root certificates.
This way, a private repo that is available via HTTPS with an internal CA will work.
Public repos pass certificate verification using the system's trusted root certificates. Private repos may require a Certificate Authority that is not in the system's trusted root certificates.
Although some users may be able to add CAs system-wide, it is easiest and cleanest to allow setting CAs on a per-repo basis. This way no change system-wide change is necessary in order to use private repos with custom CAs.
The
repo.yaml
syntax can be extended with aCA
string field so users can provide the CA together with the repository information.@andreabolognani
The text was updated successfully, but these errors were encountered: