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.
Hey thanks, you might understand the situation better than me.
> No idea what you mean with the message ids and dags and stuff.
Those are features of git-ssb. Or just ssb. https://www.scuttlebutt.nz/
@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.
But @joeyh thanks, and please continue to help me refine this info. I haven't got a response to my rough draft in SSB yet.