Github login on lab.libreho.st


#1

In order to develop libre.sh on this shared git, I want the lowest barrier for people to contribute from Github.

What do you think about having a Github login, just there?


#2

I would rather avoid this, github goes somewhat against our values afaict.

If you want github contributions its perhaps better to place it on github.


#3

I know it goes against our values, but it is just to lower the barrier to contribute.

Currently, you need to click:

  • sign in with login.libreho.st (which is not the sign up intent)

  • then click register

  • then fill a wall of a form

Then you are in!

If you just wanted to correct a typo, I don’t think people will do it.

And we don’t host GitHub code on our server, just a link to their OpenId connect thing (which is an open standard).

So I think it is not about our values, but also the freedom for a contributor to have the convenience to contribute easily.

And this is the only place I’d advocate this convenience.

Also :slight_smile: do you want to host private data of people in our login.libreho.st? :wink:

( Ok, we’ll do it anyway on our gitlab, but well, one place less :slight_smile: )


#4

This argument is sound. But I get @realitygaps’s argument as well.

As many free software developers moved from Github to Gitlab and Gitea, would it make a good compromise to implement these first?

When enough people coming from Github complain, then we can put this question back on the table.

Over the last few months, I’ve been actively unlinking my Github account from places around the Web that use it, because I don’t like M$ spying on my Web habits, so I prefer letting them do the spying work instead of granting them access to my data so easily.


#5

I’m ok with gitlab.com actually, you are right :slight_smile: ( and maybe framagit?)

(Until IBM buys gitlab.com :stuck_out_tongue: )


#6

If we accepts logins from https://framagit.org then they shield us from Github, Gitlab, and Bitbucket. :wink:


#7

(Actually, it is what I thought :P)

But framagit is kinda really french, we can’t have just that

I propose:

What do other think? Anybody strongly against?


#8

I would add https://git.coop/ as well. Any other friendly dev forge around?


#9

One idea would be to mirror the repo to Github and accepts Pull/Merge requests on both places.


#10

Yes I’d love too actually :slight_smile:

(But first I need GitHub integration to have that mirroring thing :stuck_out_tongue: )

And then do you have experience in such setup? (I know myself, if I can’t merge with one click from the browser knowing everything is perfect, I’ll not merge PR…)


#11

I don’t think you need Github integration for mirroring. Gitlab can mirror/push a repository to any valid git repo out there. It’s under Settings > Repository > Mirroring. All you need is the a url and a token.

The caveat in that scenario is that mirroring is one way. So one of the repos is the primary one (eg. Gitlab), that pushes changes to the other(s). That means that you can only merge through the web interface on the primary repo. If a PR is opened on Github, you’ll do the review and when it’s ready to be merged you’ll have to do the merge locally and push it to Gitlab. When Github gets the changes will know that this is the same commit and will close the PR as merged.


#12

Can we move this login story further?

I don’t have admin rights on the gitlab, so, can somebody give it to me please? danke!


#13

+1 @pierreozoux. Yes, Github (before M$ as well) sucks but it is the daily reality of the majority of software developers for now. We have to meet them where they are ready to be met and that is largely on Github. Auto-migrate, login and mirroring all start from the integration. I would add it.


#14

I’m not sure from your post what is your proposal. Can you make an unambiguous statement instead?

From what I understand, you’re proposing to use Github logins. As explained before, such logins are already compatible with Gitlab, Framagit, and Git Coop. Therefore it’s unnecessary to accept direct Github logins, since we would lose an opportunity to send such users to GH alternatives already.

I’m not concerned at all that the bulk of ‘open-source’ developers are on GH since most of them cannot make a difference between the former and free software in the first place. We’re interested in contributors who know the difference, so as to engage with them. The others will have to learn the difference first, probably by watching LibreHosters and sister projects mark this difference more clearly.

I’d be happy that @pierreozoux gets Gitlab admin and proceed with the proposal in post #12. Is it @mattronix who has set this up?


#15

Hi How,

Just so i understand what are trying to achieve here, authentication with github?

For anything authentication related the connection has to be done at keycloak level and not gitlab level but i might not be fully understanding the goal.


#16

No, authentication with gitlab, framagit and git coop. Pierre wants to enable “login with …” in Gitlab.


#17

ah ok,

But we are we not federating at the SSO level? as application-level authentication oauth or SAML will end up going though Keycloak anyway so it seems like with our topology it might be more overhead to do auth from Gitlab rather then Keycloak?

@pierreozoux do you feel the same way or do you see a limitation of Keycloak or benefit of “login with Gitlab” that I might not be aware of yet?


#18

I guess it’s a matter of ‘advertisement’: the current info says ‘Sign in with login.libreho.st’ and offers a ‘local’ username/password login interface – this one could be removed and replaced with a single SSO button that can advertise as login.libreho.st does. In this case it might even be advantageous to redirect Gitlab sign-in page directly to login.libreho.st, yes?


#19

I understand where your coming from but to “login with gitlab” you will then be redirected to keycloak automatically as GItlab uses keycloak as its sole auth provider meaning you enter the same flow but with an additional step which might not add any value to the user experience and increase operational management overhead of the application and failure domain of authentication services.

I like the idea of somehow making the SSO (keycloak) more appealing to the target audience.

Correction: i forgot we have local login enabled so both work.


#20

If no one is against it lets redirect auth to SSO directly?

We do that on some gitlab instances that would make the user workflow easier.

Any user that exists only locally could then sign up and it would map their account so the risk of data loss or issues is low.

Anyone up for this, where do we vote on it?