[WIP] Add test for GIT_SSL_CAINFO env var removal #315
Conversation
Change-Id: Ib46708cc2cc7d8b92b694e3bea92e66ab4d0b737
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Gonna wait to merge this until @sdowell adds support for http access to git. That way we won't pollute the CACertSecretRef test with needing to use NoSSLVerify (which has its own test). |
| @@ -280,6 +280,25 @@ func TestCACertSecretRefV1Beta1(t *testing.T) { | |||
| if err != nil { | |||
| nt.T.Fatal(err) | |||
| } | |||
|
|
|||
| // Set RepoSync to use HTTPS with no auth and SSL verification disabled. | |||
| // This validates that the GIT_SSL_CAINFO env var can be removed. | |||
There was a problem hiding this comment.
I believe line 266 should already be verifying this. It unsets caCertSecretRef and then checks that the env var has been removed
There was a problem hiding this comment.
Technically you're correct, but it also doesn't sync. I wanted one where it actually worked.
There was a problem hiding this comment.
Seems like you could add a DeploymentMissingEnvVar predicate to line 279 then, right?
There was a problem hiding this comment.
Fair enough.
That said, I don't understand how 278 works without the CACertSecretRef. The SecretRef is a private key to authenticate the user, right? How does it validate the server cert without a CA file?
There was a problem hiding this comment.
Does git@ scheme not validate the server cert by default??
There was a problem hiding this comment.
caCertSecretRef is only used for verifying the authenticity of the server certificate over HTTPS. SSH is a different protocol
There was a problem hiding this comment.
Does SSH not validate the server cert? I thought it did.
Or is the git server configured to use a known CA when using SSH?
There was a problem hiding this comment.
Certificate authorities aren't involved with SSH protocol. They are used to sign certificates used in HTTPS. Authenticity over SSH is established using the public/private key pair
This is at least typically the case, to my understanding. There may be some exceptions where certificates are used with SSH
There was a problem hiding this comment.
In the connection setup phase, the SSH server authenticates itself to the client by providing its public key. This allows the SSH client to verify that it is actually communicating with the correct SSH server (instead of an attacker that could be posing as the server).
Weird... How can you trust that the SSH server is who they say they are if you get the public key from them instead of a trusted third party? In TLS, the server gives you its public key, but it has to have been signed by a CA you trust. It sounds like maybe SSH (or at least git?) doesn't have that layer of security by default, which is... really surprising.
|
curious if this is still WIP or if it's even relevant. If it is consider closing the PR and keeping the private branch or converting to draft. |
This confirms that the new SSA used to update the reconciler Deployment correctly deletes the GIT_SSL_CAINFO env var (as long as no one else has modified it).