Tell HN: GitHub no longer supporting unauthenticated `git://` • Hacker News Board

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

#141

Post by piaste » Wed, Jan 12, 2022, 2:50 PM UTC

superkuh wrote: post #107

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.

Like most crimes, the biggest and most common dangers come from the people/software you already know. It's going to be a company's profit incentive or a lone dev's hissy fit expressed through softare you implicitly trust that gets you. Unencrypted internet transfers have worked and will continue to work for a very long time with very few problems for the vast majority of people. Requiring encryption might be okay, bu…

> Requiring encryption might be okay, but requiring CA based TLS is not okay. It is another strong force of centralization and shortly thereafter, control.

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.

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

#142

Post by ghshephard » Wed, Jan 12, 2022, 3:12 PM UTC

thayne wrote: post #127

whimsicalism wrote: post #80

Earlier quoted context omitted.

So why would it be better to learn about those things when the brownout was permanent? Seems like very short-sighted thinking.

I think the idea is that once you know what is going on you can opt out, so that you can put fixing it on your next sprint instead of having to drop everything and fix it right now so you don't lose 24 hours of productivity.

I 100% understand that - The point I'm trying to make is- the next "brown out" is permanent - so instead of 24 hours, next time you will have a permanent loss of productivity. I.E. Why are there devices being deployed that are still broken? Because in a few months, they are never coming back until they are fixed.

The idea is to make brownouts increasingly painful - just letting them be a short period of time, or let people "Opt. Out" doesn't service the purpose here - which is to make it absolutely clear that the service is going away.

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

#143

Post by CRConrad » Thu, Jan 13, 2022, 2:23 AM UTC

purkka wrote: post #108

superkuh wrote: post #107

Earlier quoted context omitted.

Like most crimes, the biggest and most common dangers come from the people/software you already know. It's going to be a company's profit incentive or a lone dev's hissy fit expressed through softare you implicitly trust that gets you. Unencrypted internet transfers have worked and will continue to work for a very long time with very few problems for the vast majority of people. Requiring encryption might be okay, bu…

If you're using GitHub, you've already centralized. git:// support is not being removed from Git or self-hosted repos of any kind.

> git:// support is not being removed from Git or self-hosted repos of any kind.

...quite yet. Because that's the third 'E' in the strategy, and they're not quite finished with the second one.

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

#144

Post by _g5q8 » Thu, Jan 13, 2022, 4:01 PM UTC

burnished wrote: post #128

_g5q8 wrote: post #89

Earlier quoted context omitted.

Credentials/tokens go in environment variables. For development, the convention is to make a `.env` file that's in `.gitignore` and load it into your environment variables. In deployed contexts, you often have a system to do this for you.

What sort of tools read .env files/what do I need to know to comfortably set and read environment variables in PowerShell or Bash? Do you just keep the token there in plain text in the .env file? If you have multiple work stations, do you have a method to keep your secrets synched? Sorry about all the questions! I appreciate any insight you might have on this though.

There are projects, like for Node there's a dotenv package, that can load these files.

If I have multiple machines, I manually sync them since that's usually the easiest way to manage it as secrets in my experience don't change enough to warrant syncing them.