Optional TLS cert for Git over HTTPS

[stefanprodan]

When using Git over HTTPS, the controller should look for the cert files inside the credential secret, the same way we do for Helm repositories.

apiVersion: source.fluxcd.io/v1alpha1
kind: GitRepository
metadata:
  name: podinfo
  namespace: default
spec:
  url: https://github.com/stefanprodan/podinfo
  secretRef:
    name: https-credentials
---
apiVersion: v1
kind: Secret
metadata:
  name: https-credentials
  namespace: default
type: Opaque
data:
  username: <BASE64> 
  password: <BASE64> 
  certFile: <BASE64>
  keyFile:  <BASE64>
  caFile:   <BASE64>

The certFile, keyFile and caFile should be optional, when present, the controller will use them to connect to the Git HTTPS server.

[hiddeco]

This is not going to be the easiest to solve due to the fact that the go-git/go-git HTTP client is runtime shared based on the protocol of the remote URL.

https://github.com/go-git/go-git/blob/641ee1dd69d3b8616127623e4b9341f4f4196d12/remote.go#L368
https://github.com/go-git/go-git/blob/641ee1dd69d3b8616127623e4b9341f4f4196d12/plumbing/transport/client/client.go#L16

[stefanprodan]

This can be implemented using libgit2 as this library allows us to handle the TLS handshake.

[phillebaba]

I just got a question about using mutual TLS. It might be worth implementing support for that if possible also, which we are at it.

[CermakM]

Is there any temporary workaround for this?

[aidmax]

Hi, also interested in adding self-signed git source (GitHub Enterprise) using https.

[stealthybox]

This is not going to be the easiest to solve due to the fact that the go-git/go-git HTTP client is runtime shared based on the protocol of the remote URL.

@hiddeco perhaps this is solvable by wrapping a Client with host specific behavior.
Maybe we would override a Connect() method

[hiddeco]

perhaps this is solvable by wrapping a Client with host specific behavior. Maybe we would override a Connect() method

What worries me is the management of the host specific behavior and credentials.

It would require something like a host <-> credential pool with a TTL so that credentials for resources that "magically disappear" are evicted from the pool.

Also: using the host is not a 100% fool proof, as multiple resources could point to the same host but with a different (m)TLS configuration.

[phillebaba]

I have started working on an implementation that would work with the libgit2 provider FYI. Still a need to figure out how one would do this with go-git.

[stefanprodan]

I think it's acceptable to having this feature implemented for libgit2 only.

[stefanprodan]

Implemented in #283