Re #Microsoft eating #GitHub -
one more alternative: #git-ssb
For "using git collaboratively without a central, closed-source point of origin"
https://github.com/noffle/git-ssb-intro
https://git.scuttlebot.io/
Word of caution: git-ssb works very differently from github/gitlab et al.
Would take some getting used to.
I'm asking for tips in SSB and will pass on anything that seems useful, if anybody wants.
The #DitchGithub conversation is moving fast. Here's my current summary of the implications of https://github.com/noffle/git-ssb-intro or probably any decentralized collaborative git repositories:
When using git-ssb anyone, not just the owner, can make a commit to a repository. That's radically different from the other git interfaces.
But it does not necessarily matter.
if you just just a specific git hash, it may be possible for an attacker to generate a colliding sha1 hash.
But if you combine it with a message id and only use messages linked to from that message (in the DAG of links), then you can be sure of getting the same content, since the published logs are immutable.
For belts and braces you create a tag with the message id, and use that.
@bhaugen the only attacker who can do that is the original creator of the colliding commit, when they originally created it.
A sha1 preimage attrack would be necessary for any stronger attack.
And tags add no security unless gpg signed.
No idea what you mean with the message ids and dags and stuff.
@bhaugen an nice tool to have would be a way to generate a gpg key pair from your ssb key pair.
(And vice-versa.)
Then you could gpg sign git tags with your ssb key and push to git-ssb, and ssb users could verify your signature using git's gpg integration.
However, anyone can overwrite any tag in git-ssb, which allows a DOS attack.
And people are not exactly great at remembering to check signatures either, especially given git's current interfaces for it.