Re: Single Sign On for Debian
Hello, Le mardi 22 août 2017, Luca Filipozzi a écrit : > On Mon, Aug 21, 2017 at 04:35:59PM -0700, Raoul Snyman wrote: >> On 2017-08-21 5:48, Alexander Wirt wrote: >> > > I second that: Using LDAP as a single source of truth. It's also >> > > possible to store SSH keys etc. in LDAP. >> > Then someone has to go ahead and develop a complete usermangement for >> > sso.d.o. As it is we can't work with software that is maybe coming at >> > some >> > point. Therefore we will start with gitlabs own user management, >> > combined >> > with debians ldap. >> > >> > But if you do take in point the following things: >> > >> > - user self management (lost password, deletion) >> > - key self management >> > - api for user manipulation >> > - oauth2 frontend (sso as oauth2 provider) >> > - maybe saml frontend (sso as saml provider) >> >> Has anyone looked at Keycloak? http://www.keycloak.org/ > > I have and deployed it for others in production. Not an unreasonable > option. There is lemonldap-ng already packaged which provides saml, oauth, openid-connect, CAS, and more (both identity provider and service provider). It works with users in ldap but doesn't have a user management interface. We use it at work and it integrates nicely with all kind of webapp (including gitlab, via oauth). Regards Mathieu Parent -- Mathieu
Re: Single Sign On for Debian
On Aug 22, 2017 8:23 AM, "Luca Filipozzi" wrote: > Has anyone looked at Keycloak? http://www.keycloak.org/ I have and deployed it for others in production. Not an unreasonable option. I'm running it in production as well. If you need some help to evaluate/configure it, just ping me. Philipp
Bug#872812: exim4-config: Exim configuration error in line 684 of /var/lib/exim4/config.autogenerated.tmp
control: reopen -1 control: reassign -1 jenkins.debian.org thanks On Mon, Aug 21, 2017 at 11:27:12PM +0200, Marco d'Itri wrote: > Not a bug: not true, see above. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844220#65 thanks for the pointer! -- cheers, Holger signature.asc Description: Digital signature
Processed: Re: Bug#872812: exim4-config: Exim configuration error in line 684 of /var/lib/exim4/config.autogenerated.tmp
Processing control commands:
> reopen -1
Bug #872812 {Done: m...@linux.it (Marco d'Itri)} [general] exim4-config: Exim
configuration error in line 684 of /var/lib/exim4/config.autogenerated.tmp
Bug reopened
Ignoring request to alter fixed versions of bug #872812 to the same values
previously set
> reassign -1 jenkins.debian.org
Bug #872812 [general] exim4-config: Exim configuration error in line 684 of
/var/lib/exim4/config.autogenerated.tmp
Bug reassigned from package 'general' to 'jenkins.debian.org'.
Ignoring request to alter found versions of bug #872812 to the same values
previously set
Ignoring request to alter fixed versions of bug #872812 to the same values
previously set
--
872812: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872812
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Re: Single Sign On for Debian
On Tue, 22 Aug 2017, Mathieu Parent wrote: > Hello, > > Le mardi 22 août 2017, Luca Filipozzi a écrit : > > On Mon, Aug 21, 2017 at 04:35:59PM -0700, Raoul Snyman wrote: > >> On 2017-08-21 5:48, Alexander Wirt wrote: > >> > > I second that: Using LDAP as a single source of truth. It's also > >> > > possible to store SSH keys etc. in LDAP. > >> > Then someone has to go ahead and develop a complete usermangement for > >> > sso.d.o. As it is we can't work with software that is maybe coming at > >> > some > >> > point. Therefore we will start with gitlabs own user management, > >> > combined > >> > with debians ldap. > >> > > >> > But if you do take in point the following things: > >> > > >> > - user self management (lost password, deletion) > >> > - key self management > >> > - api for user manipulation > >> > - oauth2 frontend (sso as oauth2 provider) > >> > - maybe saml frontend (sso as saml provider) > >> > >> Has anyone looked at Keycloak? http://www.keycloak.org/ > > > > I have and deployed it for others in production. Not an unreasonable > > option. > > There is lemonldap-ng already packaged which provides saml, oauth, > openid-connect, CAS, and more (both identity provider and service > provider). It works with users in ldap but doesn't have a user management > interface. > > We use it at work and it integrates nicely with all kind of webapp > (including gitlab, via oauth). I haven't looked into it. Can lemonldap-ng have multiple backends at the same time? Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend? If the answer is yes, I maybe find time to evaluate it (of course any help is appreciated) Alex
Re: how to build dependency of python-webkit if python-webkit is not maintained?
On 15/08/17 19:03, 慕 冬亮 wrote: > Hello all, > > I have a python pacakge which depends on python-webkit(or pip package > pywebkitgtk). > > However, pywebkitgtk is not maintained now. Is there alternative pip > package to replace webkit python module? The alternative is gir1.2-webkit2-4.0. See e.g. my mail at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749253#5 Cheers, Emilio
Re: Debian Policy 4.1.0.0 released
Hi, On Mon, Aug 21, 2017 at 02:35:39PM -0700, Sean Whitton wrote: > Debian Policy 4.1.0.0 is on its way into unstable. [...] > 4.15 > Packages should build reproducibly when certain factors are held > constant; see 4.15 for the list. > > 4.15 > Packages are recommended to build reproducibly even when build > paths and most environment variables are allowed to vary. [...] while I'm glad for the other changes too, I must say I'm still+again *excited* to see this change to debian-policy really happening now. We've come a long way! (And still have a long way to go.) I've wrote some more bits about this at http://layer-acht.org/thinking/blog/20170812-reproducible-policy/ so all I want to say now is m## mm#mm # mmmmm m mm # m m m mmm m m ##" # " # #" # # m" "m m" #" "# # # ## # m"""# # # #"##m# # # # # "mm # # "mm"# # # # "m "#"#m#" "mm"# m" "" to everyone who contributed. You know who you are and you rock! -- cheers, Holger signature.asc Description: Digital signature
Re: salsa.debian.net
On 2017-08-21 12:38:46, Alexander Wirt wrote: > On Mon, 21 Aug 2017, Marcin Kulisz wrote: > > > On 2017-08-21 07:03:42, Salvatore Bonaccorso wrote: > > > > > It looks this is the new collaboration server in replacement to > > > alioth: https://wiki.debian.org/Salsa . > > > > Just to be clear is salsa.d.o (with gitlab) replacing alioth? I thought > > that it > > was meant to be pagure (just asking as maybe I missed something). > it will, we made the final decision during the sprint. An announcement will > follow. Great, thx for the info. -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
Re: Single Sign On for Debian
On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote: > > There is lemonldap-ng already packaged which provides saml, oauth, > > openid-connect, CAS, and more (both identity provider and service > > provider). It works with users in ldap but doesn't have a user management > > interface. > > > > We use it at work and it integrates nicely with all kind of webapp > > (including gitlab, via oauth). > I haven't looked into it. Can lemonldap-ng have multiple backends at the same > time? > Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend? I haven't used lemonldap-ng but I'd like to add that it's maintained in Debian by Xavier Guimard (within the Debian Perl Group) who's also part of upstream. I'm sure he's happy to help by answering questions and maybe also setup or changes etc. (CC'd). Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Oscar Brown Jr.: Brother Where Are You? signature.asc Description: Digital Signature
Re: Single Sign On for Debian
On Tue, Aug 22, 2017 at 04:29:49PM +0200, gregor herrmann wrote: > On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote: > > > > There is lemonldap-ng already packaged which provides saml, oauth, > > > openid-connect, CAS, and more (both identity provider and service > > > provider). It works with users in ldap but doesn't have a user management > > > interface. > > > > > > We use it at work and it integrates nicely with all kind of webapp > > > (including gitlab, via oauth). > > I haven't looked into it. Can lemonldap-ng have multiple backends at the > > same > > time? > > Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend? > > I haven't used lemonldap-ng but I'd like to add that it's maintained > in Debian by Xavier Guimard (within the Debian Perl Group) who's also > part of upstream. I'm sure he's happy to help by answering questions > and maybe also setup or changes etc. (CC'd). > URL for clicking https://lemonldap-ng.org/welcome/ On Tue, Aug 22, 2017 at 09:30:50AM +0200, Philipp Hug wrote: > On Aug 22, 2017 8:23 AM, "Luca Filipozzi" wrote: > > > Has anyone looked at Keycloak? http://www.keycloak.org/ > > I have and deployed it for others in production. Not an unreasonable > option. > > > I'm running it in production as well. If you need some help to > evaluate/configure it, just ping me. What I learned from the Alioth Sprint last weekend is that DSA previously handed-out a new (test) machine easily. New policy is handing-out machines for the stage after early tests. Thing that I hope is that Alioth successors will have the various services on separate machines. So that we have not again the situation when replacing a Source Code Management system we also have to replace the machine with all the -guest accounts. Don't count on me for that. New tasks I volunteert for during the Alioth replacement sprint are listmaster and http://gitea.debian.net maintenance. So most likely nothing new: We all agree that someone else should do it. And we all respect those who actually do. Groeten Geert Stappers -- Leven en laten leven
Bug#872930: general: reboots every time even when i shut it down
Package: general Severity: normal Dear Maintainer, When I shut down my computer it reboots every time, but only when I use Linux (debian). However, I don't have this problem with Windows. I have both of the OSs on the same computer. And only when debian reboots after I tried to suspend it, and error message appears before. It says something like : "* time is in the future ( by less than a day probably due to *'s clock...)" This message doesn't appear after using Windows or turning off the computer by removing the battery. Thank you, -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Single Sign On for Debian
Le 22/08/2017 à 16:29, gregor herrmann a écrit : > On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote: > >>> There is lemonldap-ng already packaged which provides saml, oauth, >>> openid-connect, CAS, and more (both identity provider and service >>> provider). It works with users in ldap but doesn't have a user management >>> interface. >>> >>> We use it at work and it integrates nicely with all kind of webapp >>> (including gitlab, via oauth). >> I haven't looked into it. Can lemonldap-ng have multiple backends at the same >> time? >> Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend? > > I haven't used lemonldap-ng but I'd like to add that it's maintained > in Debian by Xavier Guimard (within the Debian Perl Group) who's also > part of upstream. I'm sure he's happy to help by answering questions > and maybe also setup or changes etc. (CC'd). Hi all, LLNG can have many backends simultaneously. The 2.0 version (not yet published, in tests) adds a better plugin system that can be used to create new backends. For now, LLNG is usable with: * LDAP, Active-Directory, SQL, Kerberos (better with 2.0), Radius, another LLNG system (proxy or delegate), SSL (using webserver), Yubikey (better with 2.0), WebID, * SAML-2.0, CAS, OpenID-2.0, OpenID-Connect, * Multi : backend chosed by rule (better with 2.0 => "Combination") * Choice : user can choose its backend * backends usable by 2.0 only: * PAM * REST API * Second factor (U2F or custom) It can also (and simultaneously) be used as identity provider for CAS, OpenID-Connect, OpenID-2.0, SAML It has been designed for French government but is used in many places now. Our main installation handles hundreds applications for ~25 users (~30 millions hits/day). I've heard about a bigger one in US but have no info on it. Best regards, Xavier https://lemonldap-ng.org signature.asc Description: OpenPGP digital signature
Bug#872947: ITP: node-tap-mocha-reporter -- Format a TAP stream using Mocha's set of reporters
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-tap-mocha-reporter Version : 3.0.6 Upstream Author : Isaac Z. Schlueter (http://blog.izs.me/) * URL : https://github.com/isaacs/tap-mocha-reporter * License : ISC Programming Lang: JavaScript Description : Format a TAP stream using Mocha's set of reporters This module allows one to format node-tap output like output of Mocha test framework. . node-tap is a Node.js implementation of TAP a simple text-based interface shared between testing modules implemented in many popular languages. . Mocha is a feature-rich JavaScript test framework running on Node.js and browser, making asynchronous testing simple. . Node.js is an event-based server-side JavaScript engine.
Re: Evaluation (Re: Proposal: A new approach to differential debs)
On 2017-08-16 00:21:09 [+0200], Julian Andres Klode wrote: > libreoffice-core (size only): > > -rw-r--r-- 1 jak jak 29M Jul 22 20:02 libreoffice-core_5.3.5~rc1-3_amd64.deb > -rw-r--r-- 1 jak jak 31M Jul 16 00:10 libreoffice-core_5.4.0~rc2-1_amd64.deb > -rw-r--r-- 1 jak jak 31M Jul 28 18:29 libreoffice-core_5.4.0-1_amd64.deb > -rw-r--r-- 1 jak jak 18M Aug 15 23:44 > libreoffice-core_5.3.5~rc1-3_5.4.0-1_amd64.pdeb > -rw-r--r-- 1 jak jak 4.5M Aug 15 23:42 > libreoffice-core_5.4.0~rc2-1_5.4.0-1_amd64.pdeb > > For 5.4~rc2 to 5.4 it made a huge difference, for 5.3.5~rc1 to 5.4 not so > much, > so it probably is a good fit for stable updates, but not for unstable and > testing. I would say it depends on the software. Some differs more than other. > firefox (size & performance): > > -rw-r--r-- 1 jak jak 2.3M Aug 15 20:59 firefox_55.0-1_55.0-2_amd64.debdelta > -rw-r--r-- 1 jak jak 2.4M Aug 15 22:13 firefox_55.0-1_55.0-2_amd64.pdeb and bsdfiff of old data.tar vs new data.dat 2.3MiB which is probably what debdelta does. So I am not sure if it is worth the extra mile to diff file by file. It might be faster and less memory hungry however. > # Further extensions > > If you put a pristine-tar delta into the delta file, you can fully > reconstruct debs. There is deltarpm [0] which does the same thing for rpm/fedora. I tried to find a design document but it seems that there is none. It seems however they grab all the binaries and make a delta via in-tree copy of bsdiff (delta.c). They also have intree-zlib but I didn't look why… I was mostly interrested if they have some filters to replace the offsets in binaries with something else but didn't find anything yet. I am not sure if they keep old rpm around for the delta to apply or if they reconstruct if from the file system (minus the config files). [0] https://gitorious.org/deltarpm/deltarpm Sebastian
Re: Debian Policy 4.1.0.0 released
Holger wrote: >m## > mm#mm # mmmmm m mm # m m m mmm m m >##" # " # #" # # m" "m m" #" "# # # >## # m"""# # # #"##m# # # # # >"mm # # "mm"# # # # "m "#"#m#" "mm"# > m" >"" > > to everyone who contributed. You know who you are and you rock! I would normally be reluctant to send a "me too" mail, but… Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Evaluation (Re: Proposal: A new approach to differential debs)
On Tue, Aug 22, 2017 at 10:53:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-08-16 00:21:09 [+0200], Julian Andres Klode wrote:
> > libreoffice-core (size only):
> >
> > -rw-r--r-- 1 jak jak 29M Jul 22 20:02
> > libreoffice-core_5.3.5~rc1-3_amd64.deb
> > -rw-r--r-- 1 jak jak 31M Jul 16 00:10
> > libreoffice-core_5.4.0~rc2-1_amd64.deb
> > -rw-r--r-- 1 jak jak 31M Jul 28 18:29 libreoffice-core_5.4.0-1_amd64.deb
> > -rw-r--r-- 1 jak jak 18M Aug 15 23:44
> > libreoffice-core_5.3.5~rc1-3_5.4.0-1_amd64.pdeb
> > -rw-r--r-- 1 jak jak 4.5M Aug 15 23:42
> > libreoffice-core_5.4.0~rc2-1_5.4.0-1_amd64.pdeb
> >
> > For 5.4~rc2 to 5.4 it made a huge difference, for 5.3.5~rc1 to 5.4 not so
> > much,
> > so it probably is a good fit for stable updates, but not for unstable and
> > testing.
>
> I would say it depends on the software. Some differs more than other.
True.
>
> > firefox (size & performance):
> >
> > -rw-r--r-- 1 jak jak 2.3M Aug 15 20:59 firefox_55.0-1_55.0-2_amd64.debdelta
> > -rw-r--r-- 1 jak jak 2.4M Aug 15 22:13 firefox_55.0-1_55.0-2_amd64.pdeb
>
> and bsdfiff of old data.tar vs new data.dat 2.3MiB which is probably
> what debdelta does. So I am not sure if it is worth the extra mile to
> diff file by file. It might be faster and less memory hungry however.
debdelta also does some file thing, but not sure. We definitely want
to go per file, as we will not generate a new tar but directly patch
the installed files (basically, changing the code that unpacks a file
to .dpkg-new to apply the delta to the old file and write the result
to .dpkg-new) - you might not even have to read (all) the old files.
>
> > # Further extensions
> >
> > If you put a pristine-tar delta into the delta file, you can fully
> > reconstruct debs.
>
> There is deltarpm [0] which does the same thing for rpm/fedora. I tried
> to find a design document but it seems that there is none. It seems
> however they grab all the binaries and make a delta via in-tree copy of
> bsdiff (delta.c). They also have intree-zlib but I didn't look why…
> I was mostly interrested if they have some filters to replace the
> offsets in binaries with something else but didn't find anything yet.
Right. We do have our own fork of bsdiff as well now, it's temporarily
known as jkdiff (https://github.com/julian-klode/jkdiff). The goal is
of course to turn this into a re-usable library and frontend programs,
and not limit it to "just" dpkg.
I did two changes compared to bsdiff:
* Instead of storing three different control (tuples of delta length,
extra length, and an amount to seek), delta (sumwise difference
of bytes), and extra (extra bytes to write); it now stores the tuple
directly followed by the diff data and the extra data.
This makes the patches streamable - we don't have to read from
three different positions at the same time. Which is important for
us because we can now apply the deltas without even extracting
the individual diffs (which is important due to the next point).
* jkdiff files are uncompressed, bsdiff uses bzip2 on the control,
delta, and extra blocks. We will store the files in an xz compressed
tarball, so not compressing them first saves time and space. Also,
xz is faster than bzip2 (or even gzip) when decompressing AFAICT.
The diff tool is still based on bsdiff, but jkpatch was completely
written from scratch and should be really easy to read. The jkpatch
tool applies diffs using SIMD instructions (using GCCs vector_size
attribute), which improved user time by about 50%.
Also, I applied the following changes for the generator:
* Debian: Do not support large files (> 2GB) - For large files, we need
(9 * old + 1 * new) memory (essentially because we build a suffix
offset array, so sizeof(off_t) * input size), so at 2GB that would
be about 20GB of RAM needed already. By only supporting small files,
we reduce the memory overhead to 5 * old + new, so for the maximum of
2 GB we only need 12 GB of RAM.
This only affects generation though. The patches still use 64 bit
values, and the patch tool supports large files.
* Chromium changes:
- Replace embedded qsufsort with linking to libdivsufsort - much
faster diff generation (for libreoffice it went from 93 seconds
to 5 seconds), especially in some pathological
cases
- Some more fixes for pathological cases
(See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409664#44)
I'll be writing a blog post and/or email with more details
shortly.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Bug#872959: ITP: gcc-7-doc -- documentation for the GNU compilers (gcc, g++, etc.)
Package: wnpp Severity: wishlist Owner: =?utf-8?b?R3VvIFlpeHVhbiAo6YOt5rqi6K2eKQ==?= * Package name: gcc-7-doc Version : 7.2.0-1 Upstream Author : FSF * URL : https://gcc-gnu.org/ * License : GFDL-1.3+, with invariant sections (thus non-free) Programming Lang: Texinfo Description : documentation for the GNU compilers This package contains manual pages and documentation in info and html format, for the GNU compilers. This documentation is licensed under the terms of the GNU Free Documentation License, and contains invariant sections, so it can't be part of Debian main. Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? I'm maintaining gcc-6-doc and have maintained several earlier versions. [1] As a DM, I need sponsor on the first upload, and would prefer DM upload permission for subsequent updates. [1] http://anonscm.debian.org/gitweb/?p=users/yixuan-guest/gcc-doc.git;a=summary Thanks, Yixuan
Re: OpenSSL disables TLS 1.0 and 1.1
On Thu, 17 Aug 2017, Philipp Kern wrote: > At the same time holding testing hostage does not feel right to me. I > applaud the intention, but I strongly dislike the implementation. +1 Also in the security field (i.e. for Kali Linux as derivative based on Testing), we like to keep support for older protocols as that's precisely the kind of thing that you are testing (with tools using libssl) in a security review. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Single Sign On for Debian
On Tue, 22 Aug 2017 18:10:39 +0200 Geert Stappers wrote: > On Tue, Aug 22, 2017 at 04:29:49PM +0200, gregor herrmann wrote: > > On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote: > > > > > Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend? > > [...] > [...] This seems like backward thinking to me. > Thing that I hope is that Alioth successors will have the various services > on separate machines. So that we have not again the situation when replacing > a Source Code Management system we also have to replace the machine > with all the -guest accounts. I whole heartedly agree! One of the current challenges with replacing Alioth is because of how many services it's providing. If Alioth were not being used for guest accounts, this wouldn't even be a discussion. Using Gitlab (or any VCS) as the user db for guest accounts means adding a dependency that could block future upgrades... kinda like now. This is not a future-proof design and will come at a future cost. I'm happy to help implement an SSO solution that Gitlab is capable of using, but I argue against using Gitlab as a future user database. Side note... I got cert-based SSO working on https://gitea.debian.net/. It actually ended up being pretty easy and kinda fun. I have a ticket with upstream to support populating the email address, but that'll be a while. Cheers, -- Michael Lustfield
Re: Single Sign On for Debian
Michael Lustfield writes: ... > Using Gitlab (or any VCS) as the user db for guest accounts means adding a > dependency that could block future upgrades... kinda like now. This is not a > future-proof design and will come at a future cost. I suspect that Alexander's intent was just to avoid blocking the gitlab setup on having some SSO solution in place. If lemonldap-ng can make use of gitlab's guest data initially, then that lets the two things be setup independently. Once lemonldap-ng is shown to do the job, I doubt it will be a big task to transfer authority for the guest data into lemonldap-ng's control, and then have gitlab use lemonldap-ng as it's source of that data. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Single Sign On for Debian
On Wed, 23 Aug 2017, Philip Hands wrote: > Michael Lustfield writes: > > ... > > Using Gitlab (or any VCS) as the user db for guest accounts means adding a > > dependency that could block future upgrades... kinda like now. This is not a > > future-proof design and will come at a future cost. > > I suspect that Alexander's intent was just to avoid blocking the gitlab > setup on having some SSO solution in place. > > If lemonldap-ng can make use of gitlab's guest data initially, then that > lets the two things be setup independently. > > Once lemonldap-ng is shown to do the job, I doubt it will be a big task > to transfer authority for the guest data into lemonldap-ng's control, > and then have gitlab use lemonldap-ng as it's source of that data. I dont' think Lemonldap-ng does usermanagement on its own. It is a replacement for sso.d.o which allows to have more backends and provides more frontends (like saml, oauth2 and so on) Alex signature.asc Description: PGP signature
