On: Tell HN: GitHub no longer supporting unauthenticat...

[asveikau]

I've used git without github quite a bit.

I don't know anyone who would advocate using the raw git: protocol without ssh. Setting up an ssh key is not a conspiracy to make it more difficult. Using ssh is simply how it's done.

I'm not a fan of the github app or github cli, I prefer the standard tools. However, calling this "embrace, extend, extinguish" is weird.

[u801e → asveikau]

> I don't know anyone who would advocate using the raw git: protocol without ssh. Setting up an ssh key is not a conspiracy to make it more difficult. Using ssh is simply how it's done.

But it does require having an account or public key on the server. https does not require having an account, but the http transport protocol is less efficient compared to the native git protocol. If git supported a protocol like gits where it could establish a TLS connection to the server and then use the git protocol for fetch or push, that would be ideal.

[falcor84 → u801e]

> But it does require having an account or public key on the server.

It's a bit of a hassle, but I suppose you could always create a public read-only account with a 'private' ssh key made available in the readme.

[prepend → asveikau]

It’s great for anonymous clones of public repos where I don’t care about signing in.

I work a lot of public repos. I want anonymous reads and clones to be super easy on my users.

I don’t like forcing people to log in just to read. I don’t care about encryption as the integrity of anonymous clones isn’t something I suspect will be abused.

[judge2020 → prepend]

I said this in my top comment but https:// also allows unauthenticated access while being encrypted, whereas git:// is unencrypted and can be MITM'd.

[prepend → judge2020]

I understand the differences. I don’t care about MITM git protocol attacks.

[Majestic121 → prepend]

You don't have to force them to log in, replace with https:// and it works anonymously as it did before

[eptcyka → prepend]

Do you like your ISP being able to inject commits into your repo clones? There's nothing wrong with using HTTPS.

[prepend → eptcyka]

I don’t consider that a reasonable risk. And even if it was, then I don’t care for repos I explicitly clone without using encryption.

There’s a large set of “I don’t care” style projects where I’m just looking to grab a copy. So even if my ISP (or some nefarious jerk on the same WiFi) could MITM, I don’t care. Plus, I’m not aware of any attacks like this because of the whole git checksum thing it’s harder than injecting into http traffic.

For stuff I care about, I log in.

[eptcyka → prepend]

I'd be interested to know what kind of a development environment do you have that allows you to download arbitrary source and don't get pwnd. If you're on Qubes, that's cool, but I think most contemporary toolchains for all contemporary languages will expose some kind of arbitrary code execution through their build tools. Which is of course a massive shame.

[quinnjh → eptcyka]

Do you have any documentation on this?

[snovv_crash → quinnjh]

Raw git:// without SSH keys is unencrypted, like http. Http has had ISP injections since forever, so nothing stops this extending to git.

[jka → asveikau]

This seems unlikely, but if you thought that the site that you believe is github.com might be responding to you with tampered data, and you wanted to allow an independent third party to view the bi-directional traffic flowing between you and that entity, then you might want to communicate without encryption.

(it could also reduce encryption and decryption load at both endpoints, and if you have other means to enforce content integrity then the channel itself does not have to been encrypted)