[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote:
> On Wed, 08 Jun 2016, Pirate Praveen wrote:
> > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote:
> > > [SN: trimmed Cc list, as this is about what Debian wants]
> > > 
> > > Hi Alex
> > > 
> > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote:
> > >> Its more things like:
> > >> - integration into alioth - aka, how easy is it to integrate the already
> > >>   existing identity data (which we want to keep) into the system
> > > 
> > > This can be easy (use OAUTH2 against the identity provider) or hard
> > > (convert all data).  Also it speaks ldap itself.
> > 
> > Does alioth/fusionforge already support becoming an OAUTH2 identity
> > provider? How do other debian services (like nm.debian.org) use alioth
> > login? [1] I found this [2]
> I wrote a minimal exporter for user information (no group or acl
> information) that gets synced to the dacs host. That enables dacs enabled
> services to use these information.

for authentication, I think you should probably use the Debian SSO with
client certificates:

for authorization, at least if the plan is to mirror the current alioth
git infra you will need some scripting to sync the alioth data to gitlab
(I would suggest starting with a very limited pilot with only one of
very few projects).

> Please keep in mind that dacs is not available for non dsa enabled hosts.
> > >> - mapping groups and permissions from alioth to the new system 
> > > 
> > > Fusionforge also uses a similar group based permission system.
> > > 
> > > Okay, there is this (hacked in?) "allow every DD to write" permission
> > > that some groups use, which is only supported by gitlab EE.
> Alioth uses some role based model where specific permissions get mapped to
> (pre-)defined roles. We will never be able to get that into a different
> system et al. My current plans are limited to group information and admin
> flags. Everything else will need to get redefined by the admins to the
> specific system.
> > We'll have to ask gitlab folks if they are willing to provide that in CE.
> I am also not very keen on using a system with a "open core / enterprise"
> model. For such a crucial service I would really prefer a real open source
> system. But maybe I am alone with that oppinion. 

You are not. even though I think gitlab is great, the fact that there is
a proprietary version with "premium features" has always made me feel

Antonio Terceiro <terceiro@debian.org>

Attachment: signature.asc
Description: PGP signature

Reply to: