Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: GitHub no longer supporting unauthenticated `git://`

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 144 posts

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#11

Post by stblack »

Incidentally I'm onboarding someone new to git and Github. I must say, Github is now exceedingly difficult to set up. Vocalizing every step of the process, hopefully not in a hand-wavy way, it strikes me how hard this must be for unguided noobs.

To some degree, this must be crushing the value of the service.

If ever there was a crying need for setup wizards, configuration audit helpers, and clear error messages, this would be it.

On one hand I can clearly see how git-like history and version control could help in so many areas beyond tech. On the other hand, I can see that's never gonna happen with the barriers to entry we see today.

The Github team should talk to the Rust team about error messages and helpful diagnostics.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#12

Post by tialaramex »

vermilingua wrote: post #3
judge2020 wrote: post #2

git:// is not just unauthenticated, but unencrypted on the wire. They want you to use https:// for unauthenticated clones to at least prevent MITMs.

Doesn’t git:// transport use SSH? How is SSH possibly unencrypted on the wire?

> How is SSH possibly unencrypted on the wire?

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.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#13

Post by idsout »

rgoulter wrote: post #9
vermilingua wrote: post #3

Earlier quoted context omitted.

Doesn’t git:// transport use SSH? How is SSH possibly unencrypted on the wire?

I think you're thinking of the URLs like git@github.com: / .git

I was. Thanks for the clarification.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#14

Post by vtbassmatt »

Today we're in a 24-hour brownout period to help folks find places they might have forgotten which rely on unencrypted git:// protocol. The date where this will go away permanently is still March 15, 2022.

(I'm the product manager for Git Systems at GitHub.)

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#15

Post by tialaramex »

stblack wrote: post #11

Incidentally I'm onboarding someone new to git and Github. I must say, Github is now exceedingly difficult to set up. Vocalizing every step of the process, hopefully not in a hand-wavy way, it strikes me how hard this must be for unguided noobs. To some degree, this must be crushing the value of the service. If ever there was a crying need for setup wizards, configuration audit helpers, and clear error messages, this…

Well, I mean, if you're learning from Rust note that cargo just automatically makes new projects a git repository if that's possible, in the same way it defaults to your new project's code being a trivial implementation of "Hello, world." so that it will build and run before you write any code, and it defaults to providing you a working HTML documentation build and unit test framework. Plus of course it's access to the repository for Rust libraries. But today it does not (out of the box) provide you with automated fuzzing, good performance / benchmarking tools, a bug tracker and so on. Maybe the hot new language of 2035 will have all those things.

Also however GitHub is not able to have the clean slate cargo gets. If I make a new repo, GitHub suggests I populate it with many good things, license info, a README document, and so on... but of course I can't because it's actually just somewhere to push my existing local git repo and if it's not empty that would cause a conflict.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#16

Post by traverseda »

It seems like mostly the effects of all these auth changes are twofold

* ~~Force~~ Encourage people to have github accounts

* Make using plain git more difficult (auth tokens, deprecating passwords, etc) while encouraging people to use the github cli tool

Given microsoft's history of "embrace, extend, extinguish" I have a hard time seeing these changes as anything other than an attack on git as an open ecosystem.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#17

Post by outside1234 »

traverseda wrote: post #16

It seems like mostly the effects of all these auth changes are twofold * ~~Force~~ Encourage people to have github accounts * Make using plain git more difficult (auth tokens, deprecating passwords, etc) while encouraging people to use the github cli tool Given microsoft's history of "embrace, extend, extinguish" I have a hard time seeing these changes as anything other than an attack on git as an open ecosystem.

Or its about preventing MITM attacks, which is a much more likely, much less tin foil explanation.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#18

Post by bin_bash »

otherjason wrote: post #4
vermilingua wrote: post #3

Earlier quoted context omitted.

Doesn’t git:// transport use SSH? How is SSH possibly unencrypted on the wire?

No. From https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco... : > 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’…

I was also under the incorrect impression that git:// was just an alias for ssh. It's amazing how long you can use something and still not understand how it works.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#19

Post by arilotter »

vtbassmatt wrote: post #14

Today we're in a 24-hour brownout period to help folks find places they might have forgotten which rely on unencrypted git:// protocol. The date where this will go away permanently is still March 15, 2022. (I'm the product manager for Git Systems at GitHub.)

Our CI system broke as a result - I really like this "brownout" idea to help us find it before it turns off for good, but a 24-hour period for us to be broken or scramble to fix is kind of a PITA. I imagine it would be much more technical effort, but a way for us to opt certain repos out of a brownout would be really nice, so that once it happens, we could easily disable the brownout for our repo & schedule working on a fix, while letting us continue working with the existing infra.

Re: Tell HN: GitHub no longer supporting unauthenticated `git://`

#20

Post by vtbassmatt »

arilotter wrote: post #19
vtbassmatt wrote: post #14

Today we're in a 24-hour brownout period to help folks find places they might have forgotten which rely on unencrypted git:// protocol. The date where this will go away permanently is still March 15, 2022. (I'm the product manager for Git Systems at GitHub.)

Our CI system broke as a result - I really like this "brownout" idea to help us find it before it turns off for good, but a 24-hour period for us to be broken or scramble to fix is kind of a PITA. I imagine it would be much more technical effort, but a way for us to opt certain repos out of a brownout would be really nice, so that once it happens, we could easily disable the brownout for our repo & schedule working o…

Noted! As you surmise, that's a MUCH bigger lift, but it's worth considering.
Post reply on HN