You are reading content from Scuttlebutt
@bobhaugen

I see this today in Mastadon:

Looking at self-hosted Github alternatives, so the options areLooking at self-hosted Github alte

GitLab
Gitea
Gogs

Gitea is a fork of Gogs with a better governance model[0] so that leaves GitLab and Gitea.

Gitlab:
"We also strongly recommend at least 4GB of free memory to run GitLab. "

Mmm nahhhh, so that leaves Gitea.

Or git-ssb? I suggested it like this:

Re ##MicrosoftMicroso 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/

What do y'all think? Is git-ssb too raw for public consumption? Should I retract the suggestion?

Or should I add anything else to make the suggestion more useful?

User has chosen not to be hosted publicly
@bobhaugen

When using git-ssb anyone, not just the owner, can make a commit to a repository, can't they? That's radically different from the other git interfaces.

Is that true? If so, how do the git-ssbers manage that? Are you using git-ssb for serious work on ssb? Or just experimenting with an alternative git collaboration setup?

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@bobhaugen

I posted the external link to this thread on mastadon and @alanz warned me that two of the respondents did not want to be published in the web viewers, so I deleted the mastadon post.

How would I have known that info? (That some people did not want their messages to be shown on the web viewers?) I looked at everybody's profile, do not see that mentioned. Did I miss something? Or, would it be shown on a different client? Or, just known from previous messages?

At any rate, I will quit posting those external links. They are not very reliable anyway.

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@bobhaugen

A clear summary of that chat would be useful. I don't think I can write one yet; I would need to be using it, which I will do when I get some time. But very interesting.

User has chosen not to be hosted publicly
@bobhaugen

@kas @alanz

When using git-ssb anyone, not just the owner, can make a commit to a repository, can't they? That's radically different from the other git interfaces.

yes, but it does not necessarily matter.

And then, why it doesn't matter. (rough draft, might not be correct)

  • if you use a specific git hash, you are guaranteed to get what you expect, regardless of what other arbitrary people have published?
    • maybe not
    • if you just just a 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 more sure of getting the same content.
  • So for belts and braces you create a tag with the message id, and use that.

Is that all true and adequate to explain? I feel like I would need to feel the experience...

User has chosen not to be hosted publicly
User has chosen not to be hosted publicly
@bobhaugen

@cel might be unavailable. Does anybody else know if my attempt to summarize an explanation upthread is accurate or could be improved?

Lotta people chatting about this in various venues who might be interested, and just saying "use git-ssb it's decentralized" without explaining the implications is not honest.

User has chosen not to be hosted publicly
@bobhaugen

How about

for belts and braces you create a tag with the message id, and use that.

?

@keks

So, git-ssb is small-world-pushable at the moment. What does that mean? It means everyone who is close to the one who receives the updates (is in their small world) can push. Is that a problem? Classic IT security answer: it depends.

Github has (had) two major use cases: allow collaboration (git hosting, issue tracker, PRs and project management) and code hosting (as in: you can find my code on github/to install go to github).

SSB is also used for several jobs: To debate, publish events or collaborate on code. However, the idea of SSB is to choose your small world such that you trust the ones inside.

So if you assume that all people in your network are trusted, you can safely pull all their changes (from a security perspective). If someone pushes code to a branch even though you agreed on a core review process that's a social problem. Yes, you could solve that using technology, but don't forget that this takes agency from the peers, and in some cases it's important to break the protocol.

Now, assume that there are some rogue peers in your network. One of them pushes some commits that look like they come from a trusted peer (I believe that is possible, but not 100% sure). If you have a strict CR policy, you'd probably revert the commits and ask the person you think the commits were from to refrain from doing that in the future. At some point the misunderstanding might come to light and the rogue user is uncovered (by digging through git-update messages to find who really pushed those commits.
My personal stance is that this should be made harder or impossible to do. Maybe it would be nice to use ssb to sign external messages, or git pull on a git ssb repos tells you

Hey! @rogueUser (@WeiRdID.ed25519) pushed to this repo for the first time, make sure everything is okay!

In general it would be nice to be able to see in git interfaces which ssb user pushed the commits, but I'm not sure if or how that could be made to work.

Now, as I said above, Github also is used as a code distribution platform. I don't think git-ssb is very good at this job. You currently need to be in foaf range of all (or, with ooo, at least some active) contributors, and the code authors won't be able to see that someone attacks their users because the rogue messages may be outside their foaf range (but inside their users').
However, problems like these could be tackled with independent tooling: you could have a daemon that listens for git-update messages authored by users on a whitelist and packages all tagged commits as .zip or .tar.gz files and makes these available through http. That way you can publish the team's version of the repo securely. That would be a new point of centralization though, but maybe that's okay? Idk. Maybe you could also make new git-release messages that say "Repo %abc.sha256 has a new version x.y.z at commit def123 -- @author.ed25519" and provide good tooling for that ( #somebodycould ;).

In general I'm not sure I buy the "they can't handle the implications of decentralization" narrative. Firstly, it's implemented inconsequentially. Repos still "belong" to users, e.g. keks/margaret. This implies ownership, and ownership implies some control.
Secondly, If we want code as commons, this obviously break the "clear boundaries" rule that Elinor Ostrom identified in successful commons projects. Of course this is not a hard requirement, but maybe we can learn from the experiences of past generations.

For the moment, for our situation, I don't see a problem. We can all trust each other to a reasonable degree, so we don't need to bake security into our tools. I think it would be wise to make possible attacks more visible by notifying users of new users that post git-update messages.
But what if people who abandon Github come here? Here, again, it depends. If it's something like dotfiles or small uni projects - go for it. Same with private repos - they are secure already. But if you are looking for a replacement that not only collaborating with a small or medium sized group of users but also want to distribute the resulting code, more tooling is needed. To collaborate with a huge group of users on a single project: That seems difficult with git-ssb (because you might not know some commiters), but that also doesn't sound very decentralized.


Well, these are my idea at this moment. I've used git-ssb for a while now and for the purposes I use it for it's decent. However, I often struggle with the distribution part because of the way Go package management works. There is no central registry like npm and you have to care about hosting the code yourself - and Github is super convenient here, but with git-ssb it's a pain, especially because the public mirrors have been unreliable in the past (maybe that changed though).

@bobhaugen

In response to:

if you just just a 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 more sure of getting the same content.
So for belts and braces you create a tag with the message id, and use that.

@Joey Hess (whom I don't seem to be able to @mention here, but maybe this will work? @BCM6DHY...
)
says in Mastadon:

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.

@ev

This is a similar discussion to the one we're having about avatars on ssb: %m2QMChU... %7FSY+a3...

It's not so much about who is allowed to fork the repo, it's more about whether you should clone from the latest commit pushed to the network or the latest repo pushed by the repo author.

Right now git-ssb clones from the latest push from anyone within your friend of a friend gossip network. However, it'd probably be just as easy to only clone from the repo author.

Then we wouldn't be worried about random strangers pushing commits to core repos.

I don't know which approach is best, but we should offer people a choice about whether they want to trust repo authors or everyone in their network.

--

And yes, I have accidentally pushed to master when I meant to push to a branch on %patchbay at least once back in the day. It's fairly easy to fix that issue -- just get in touch with the primary developer and have them push a new commit that doesn't include your code.

@cel

@bobhaugen

Creating a tag with a message id in it could be useful if you want to mirror the repo externally, so that a person who gets the repo from outside SSB can locate the repo update messages on SSB.

@alanz

And it is up to a user of the repo to merge in any changes anyone else may have done, in any of the other trees referring to the same repo, and then put a new message/hash out to show that it is approved

This is not the case in the current git-ssb implementation. Currently, pushing to git-ssb is like replying to a thread, and fetching from git-ssb is like fetching new messages in the thread since you last fetched.

@joeyh

A sha1 preimage attrack would be necessary for any stronger attack.
[...]
No idea what you mean with the message ids and dags and stuff.

Each push to git-ssb publishes a git-update message. A git-update message links to previous git-update messages, forming a DAG. Including a message id with a git sha1 increases the hashspace to make infeasible the preimage attack. To link to a git commit on ssb, abstractly, use the tuple (commit id, message id) where the message id is of a git-update ssb message that pushed that commit.

@ev

we should offer people a choice about whether they want to trust repo authors or everyone in their network.

Noted.

@bobhaugen

@cel thanks for the clarifications. Ok if I repost them to Mastadon?

And @joeyh want to repost your continuation in Mastadon over here?

Or can people here see this thread in Mastadon?

What's the best way to carry on a conversation between two different decentralized/federated spaces?

@cel

@bobhaugen you can quote me. I wish I had better things to say. I see that thread. Best way to do it I think would be to make servers bridge between the spaces. Otherwise I think it is fine to manually quote & relay messages; we have done this for email ↔ ssb conversations. I recommend to include a link to quoted messages/threads. So for quoting a ssb message, if you include the message id (or a ssb-viewer link) then readers can find the original message on SSB to find the conversation here too, if they want to.

@bobhaugen

I did a ssb-viewer link but @alanz said some people in the thread did not want to be exposed that way so I deleted the message in Mastadon.

@bobhaugen

Quote from another space:
"MSFT opened the door to a lot of good experimenting!
Little did they know..."

@bobhaugen

@cel and all:

Best way to do it I think would be to make servers bridge between the spaces.

Smells like #activitypub ? Or what?

@cel

@bobhaugen yes, #activitypub federation https://www.w3.org/TR/activitypub/#server-to-server-interactions

@bobhaugen

yes, #activitypub federation https://www.w3.org/TR/activitypub/#server-to-server-interactions

@cel and all: how could that work? What's the easiest way technically? How would it work socially/culturally? What implications?

@cryPhone📱

I'm with @arcfide, it's hard to grasp. I currently feel a tension between following someone out of some (yet) small interest and once they follow me back they get write access to all my repos? That's begging for a Whoops or will make me really reluctant to follow new people...

White-listing write access or some kind of PR-only mechanism for more crucial once should help us a long way, I guess. Or making more project specific keys i.e. fractal identities where following is more specific.

@cryPhone📱

@alanz I wonder if an evil actor could publish a poisoned blob though.

Since blobs are addressed by the hash of their content, this should also be pretty hard to pull off (for the foreseeable future)

@bobhaugen

More from mastadon via @Mayel
https://social.coop/@mayel/100146903138883619

@rhodey orbits

@bobhaugen only alternatives I've tried so far are GitLab and Gitea. GitLab is a veryyyy big piece of software, whereas Gitea is focused and excellent. I've been running the Gitea docker container on a Linode VPS for maybe 10 months now and have seriously never, ever had a problem with it, not once.

I use my Gitea to host projects that I'm working on but not yet ready to share publicly, so for security I make Gitea only accessible through my Wireguard VPN, and then I just set all repositories as "public" on Gitea so that hosts on my VPN can pull from them without configuring application-level auth.

@mix

Nice analysis. There could be intermediate solutions @keks - e.g. use gitlab to do www hosting of your final team solution.

I particularly like the idea of signing git commits with you private key, though not sure how to do that.

Part of me also thinks that nothing is going to change that much unless there are 3-4 people who really want to have a go at this community commons problem. It's massive, and I don't think it's just a thing for dabbling. I wonder about first step of having a call and mapping out the parts of this "Village" and then seeing if there are bite sized pieces we can get through in the next year

@André Staltz

Good analysis @keks, specially from the security and social aspect.

I think a person clearly taking initiative right now to build something is @noffle, so let's follow his work and see if we can detect and discuss on early design decisions.

Part of the work is philosophical: deciding what is the meaning of names and conventions that we use, then how that affects social dynamics. I wrote a bit about this in a blog post https://staltz.com/open-source-without-maintainers.html and I plan to write another blog post about convergence versus divergence in open source and git. Roughly, convergence is merge commits, divergence is forks or branches. Convergence is agreement, divergence is extension. The GitHub social dynamics so far because it emphasizes convergence, it's "diverge a little bit so that soon you can agree", and it leads to several problems because it conflates the author role with the maintainer role (the person who initiated the project is now expected to do convergence work forever). I'm getting ahead of myself because there are lots of ideas to unwrap, but I mean that we shouldn't just copy GitHub over to git-ssb, we need to actually think how to make open source social dynamics more reasonable than GitHub.

The other part of the work is practical and looking for the right databases (SSB? Hyperdb?), looking for loopholes, solving code distribution versus solving code collaboration, looking for features that may alter the social dynamics in unexpected ways, etc.

@bobhaugen

From @Mayel

MSFT>Github is propelling lots of new activities....

User has chosen not to be hosted publicly
@kik

Lot of interesting thoughts, here.

I just discovered git-ssb two days ago, played a bit with it, and it certainly comes as a surprise that anyone can push to my repos master :) As it was presented to me at first, it was supposed to be "decentralized github", so as @bobhaugen mentioned, the radically different nature of git-ssb permission model should be mentioned in readme. Also, the git-web interface reproducing github layout, with "author name / repos name" on top left and the clone link for master on top right is misleading in that model (initial author may not have vetted last commit on master), it should probably be replaced with something making clear there is no authority implied, like a link to the list of commits, and a git clone url for each of them (git clone project ; git reset --hard commit_hash).

So I guess, from @keks ' explanation that the proper use case for for git-ssb is replacing private repos? In that case, I suppose it's better to create new dedicated ssb accounts for handling repos, because else anyone we add as friend - and their own friends - could read our private code? I get it that we're supposed to add only people we trust as friend, but given how new ssb is, I have no irl friend on it, and the people I added as friends to use ssb are people I met on it. I guess most users are in that situation.

On the other hand, providing commits only from initial author on git-web pages and during git clone, like @ev mentioned, would totally fix the problem with no further modification needed : I know as a fact whose code I'm pulling, without the friction of having to inspect all message ids. It's also closer to the lieutenant/dictator model of git : each person has their own repos, lieutenant/dictator can pull commits from other repos (and git-web may allow devs to ask dictator to pull). Github was initially pretty close to git philosophy, there, they only diverted from it once they allowed several people to push to the same repos. Maybe git-ssb can come back to git's model?

We're far from there yet but this is worth noting anyway : private repos are github and gitlab's core business. So if we disrupt them, better have a plan to allow project discovery and public hosting and not rely on them for that :) Although, that's not exactly a git-ssb problem, we can build separate projects to do that.

@bobhaugen

See also this chat with a lot of people who seem to be starting a work group around federated git repos:
https://chat.indieweb.org/social/2018-06-06#t1528299585941600

@bobhaugen

I wonder how many of the problems being discussed in that chat have been encountered and either solved or thought about deeply in git-ssb practice?

@bobhaugen

https://github.com/git-federation/gitpub/blob/draft-0.1/SPECIFICATION.md

GitPub extends from the server-to-server layer of the ActivityPub specification. Through this, repositories and branches can signal each other for updates.

GitPub only involves in server-to-server signaling. It does not involve in the underlying git operation or implemtation done by different server.

@greg d

I can use it/understand it. So probably anyone can haha

@bobhaugen

Gitpub has apparently changed its name to https://github.com/forgefed/forgefed

Don't know what it means. The mailing list is still intact at https://framalistes.org/sympa/arc/git-federation

@bentflower
Voted this
User has chosen not to be hosted publicly
Join Scuttlebutt now