git:// is not just unauthenticated, but unencrypted on the wire. They want you to use https:// for unauthenticated clones to at least prevent MITMs.
If you've insisted on building something that insists on using git:// this way, you can proxy it to the safer supported system seamlessly, since you had no way to know before it was correct and you'll have no way to know if the proxy worked either. Somebody might already make a tool to do that, if not you could roll your own.
git config --global url."https://".insteadOf git://
There are versions of that config line more specific to individual hosts if you didn't want to blanked cover every git host, but it's probably a good idea at this point to instead ask those other hosts if they would consider adding https:// support.
This was true in the past, but the newer "smart" http protocol has content negotiation similar to the git and ssh protocols.
> Finally, we have the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create a git-daemon-export-ok file — the daemon won’t serve a repository without that file in it — but, other than that, there is no security. Either the Git repository is available for everyone to clone, or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access but, given the lack of authentication, anyone on the internet who finds your project’s URL could push to that project. Suffice it to say that this is rare.
Not really a practical answer, as your SSH client doesn't (and shouldn't) offer this, but of course the rest of the SSH protocol just relies on a negotiated arbitrary encryption for moving data between client and server which is transparent to it, you can drop in different algorithms (on most PCs today AES will be the best option because it is hardware accelerated, on cheaper or lower power hardware ChaCha20 may be much better). So, it is technically possible to have a NO-OP encryption layer but just a bad idea.
SSHv2 negotiates this stuff up front, before anybody authenticates anywhere. Key Agreement protocols like Diffie-Hellman allow two parties to agree over the network on keys and encrypt all their data even though they don't yet know who the other party is, and in SSH the encryption protocols just have string names like chacha20-poly1305@openssh.com so you could invent useless-empty@example.com and if anybody wants to agree to use that the consequences are on them.
Not just technically possible - it actually exists. There is a NONE cipher that is part of the HPN-SSH patches, etc.:
https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/
"The NONE cipher switch disables data encryption AFTER you have been authenticated or logged into the remote host. This can significantly reduce the load on the CPUs of both machines and may improve performance even more. Its important to remember that the initial authentication process is still fully encrypted."
If we're sending data over a private point-to-point link we always consider the NONE cipher ... especially if the underlying data was created by borg or restic anyway ...
Requiring encryption might be okay, but requiring CA based TLS is not okay. It is another strong force of centralization and shortly thereafter, control.
http is fine. git:// is fine. TLS CA based git and https are great. But CA TLS only to "fix" the problem introduces more security problems than it fixes.
> POSSE is an abbreviation for Publish (on your) Own Site, Syndicate Elsewhere, the practice of posting content on your own site first, then publishing copies or sharing links to third parties (like social media silos) with original post links to provide viewers a path to directly interacting with your content.
...quite yet. Because that's the third 'E' in the strategy, and they're not quite finished with the second one.
CA-based TLS is a requirement that a client can enforce on the servers, not viceversa (except for client certificates which are obviously not the case here).
When a server (Github in this case) chooses to acquire a CA-based TLS, the client isn't forced to depend on the CA in any way - it can even choose not to verify the certificate authenticity.
If the official git implementation started requiring TLS, thus forcing free private git servers (including your personal selfhosted gitea or whatever) to centralize under a recognized root CA, then your comment would make sense.