4 ms·

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 de

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

purkka 5y ago
If you're using GitHub, you've already centralized. git:// support is not being removed from Git or self-hosted repos of any kind.
- superkuh 5y ago
  https://indieweb.org/POSSE https://indieweb.org/POSSE > 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.
- CRConrad 5y ago
  > 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.
piaste 5y ago
> 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.

purkka 5y ago

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

superkuh 5y ago
https://indieweb.org/POSSE https://indieweb.org/POSSE > 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.
CRConrad 5y ago
> 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.

piaste 5y ago

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