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

91–100 of 144 posts

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

#91

Post by quinnjh »

eptcyka wrote: post #74
prepend wrote: post #60

Earlier quoted context omitted.

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.

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

Do you have any documentation on this?

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

#92

Post by bastardoperator »

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…

What setup? Creating a user? Maybe utilize the quick start docs GitHub provides?

https://docs.github.com/en/get-started/quickstart

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

#93

Post by voussoir »

shepherdjerred wrote: post #90
MattGaiser wrote: post #83

Earlier quoted context omitted.

This was not what a lot of people were doing beforehand. We were logging in with our passwords. At least for me when this change was announced, I had no idea what a key pair was as I was always using passwords for everything.

Have you never used ssh? Genuinely curious.

I'm not the person you asked, but I can say that at the time I started using github I had never used ssh.

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

#94

Post by LordLandon »

burnished wrote: post #44
Invictus0 wrote: post #31

Earlier quoted context omitted.

I have setup github several times in the last 3 days on fresh Linux installs. It is very easy.

Hey, I keep bouncing between mac and windows, where/how do you store credentials/tokens? I feel like I've got passwords now that I can't memorize and have to save as text somewhere. I'm putting sensitive stuff in a secrets folder with a corresponding gitignore entry, but I feel like there has got to be some well understood way to handle this?

I use pass[1] as my password manager, and pass-git-helper[2] to serve credentials from pass to git.

[1] https://www.passwordstore.org/ [2] https://github.com/languitar/pass-git-helper

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

#95

Post by snovv_crash »

quinnjh wrote: post #91
eptcyka wrote: post #74

Earlier quoted context omitted.

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

Do you have any documentation on this?

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

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

#97

Post by MattGaiser »

shepherdjerred wrote: post #90
MattGaiser wrote: post #83

Earlier quoted context omitted.

This was not what a lot of people were doing beforehand. We were logging in with our passwords. At least for me when this change was announced, I had no idea what a key pair was as I was always using passwords for everything.

Have you never used ssh? Genuinely curious.

Until GitHub had made that change, nope. Logged into servers with a password (my entire company did actually). Used Git nearly exclusively through some Jetbrains tool.

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

#98

Post by dragonwriter »

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…

> a 24-hour period for us to be broken or scramble to fix is kind of a PITA.

Brownouts need to be a PITA otherwise people are too likely to miss them or write them off as transient errors.

> 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

That's not a bad idea, though.

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

#99

Post by akomtu »

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.)

Sorry to digress, but what is brownout? First time I see this word.

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

#100

Post by dragonwriter »

whimsicalism wrote: post #81
humanwhosits wrote: post #46

Earlier quoted context omitted.

Brownouts make me lose confidence in the product, simply because it manifests as a failure that needs to be debugged at unknown cost

So do deprecations.

> So do deprecations.

Well, feature removals do. Deprecations are just declaring that a feature should not be used and either will or may be removed in the future, which causes no operational problems (and in fact is done specifically to help avoid the operational problems of feature removals.)

Post reply on HN