Re: Raising the problem of Debian Single Sign On + Alioth (again)
Le 23/02/2018 à 19:32, Alexander Wirt a écrit : > On Fri, 23 Feb 2018, Geert Stappers wrote: > >> On Fri, Feb 23, 2018 at 06:54:29PM +0100, Alexander Wirt wrote: >>> On Fri, 23 Feb 2018, Enrico Zini wrote: >>>... >>> Then the dd process should get fixed, not making again something to a >>> backend >>> which isn't meaned like that (we had the same problem with alioth and >>> debconf). >>> >> >> Mmm, there was something with lemon and LDAP ... websearch ... yes found >> it. >> >> https://lemonldap-ng.org/start >> >> Text from that webpage >> >> LemonLDAP::NG is an open source Web Single Sign On (WebSSO), Access >> Management and Identity Federation product, written in Perl and >> Javascript. >> >> LemonLDAP::NG is a free software, released under GPL license. >> >> LemonLDAP::NG is the first SSO software deployed in French >> administrations. It can handle large-scale organization (tested with >> hundreds of thousands users). Many private firms use it too. >> [ https://lemonldap-ng.org/references ] >> >> How much would it fill our needs?? > Yes, thats already in the process of the gsoc project. > It is very high ranked on my list, however it is just a frontend, there is a > backend missing and its management (something that manages ldap). > > Alex Hello, we currently deploy LLNG with Fusion-Directory and LSC-Connector to provide a full IAM solution. See https://fusioniam.org : the project to package the 3 in one solution (for commercial aspect and to provide Docker images, the 3 softwares remain separated). I think that LLNG stable version will not be the best for Debian (2FA not easy). The next release (2.0) will be release in a few weeks (some alpha versions are available). It is more complete and the new plugin system is more interesting to customize it. https://lemonldap-ng.org/documentation/2.0/start Regards, Xavier
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Sat, Feb 24, 2018 at 09:07:30AM +0100, Xavier wrote: > > Hello, > > we currently deploy LLNG with Fusion-Directory and LSC-Connector to > provide a full IAM solution. See https://fusioniam.org : the project to > package the 3 in one solution (for commercial aspect and to provide > Docker images, the 3 softwares remain separated). > > I think that LLNG stable version will not be the best for Debian (2FA > not easy). The next release (2.0) will be release in a few weeks (some > alpha versions are available). It is more complete and the new plugin > system is more interesting to customize it. > https://lemonldap-ng.org/documentation/2.0/start > Updated https://wiki.debian.org/Services/DebianSingleSignOn#What_we_have with that information. However a link for "LSC-Connector" is missing. Further wiki updates are appreciated. Groeten Geert Stappers -- Leven en laten leven
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Sun, Feb 11, 2018 at 03:48:07PM +0100, Alexander Wirt wrote: > On Sun, 11 Feb 2018, Boyuan Yang wrote: > > > Hello all, > > > > I just recalled that an issue was left behind during the Alioth -> > > Salsa migration: > > sso.debian.org 's Alioth account integration with Alioth platform. This > > service > > seems to have no migration plan (yet) and will break many other stuff > > once Alioth > > is down. > > > > Digging through the history, I found several places that once hold > > some related discussion: > > > > * Alioth Sprint 2017: > > > > https://gobby.debian.org/export/Sprints/AliothSuccessors2017/Minutes > > > > * Thread from debian-devel back on 2017-08: > > > > https://lists.debian.org/debian-devel/2017/08/msg00465.html > > > > From a user (non-DD)'s perspective, current best plan should be the > > integration > > with Salsa GitLab user database. Works on such implementation are surely > > needed > > though. > so you volunteer to do that? great! > FWIW there is now https://wiki.debian.org/Services/DebianSingleSignOn#What_is_missing Groeten Geert Stappers -- Leven en laten leven
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Fri, Feb 23, 2018 at 04:27:40PM +0100, Enrico Zini wrote: > On Fri, Feb 23, 2018 at 03:49:06PM +0100, Alexander Wirt wrote: > > > I would wait for the gsoc project. And on the alioth sprint, several people > > decided against using salsa as backend for sso, but the other way round. > > So please don't. > > Ok, fine with me. > > I'll stop worrying about it for now, I think I did decrypt that clear text message ... > and refer people who ask me about it, to this thread. Or/and https://wiki.debian.org/Services/DebianSingleSignOn#Make_over_2018 Groeten Geert Stappers -- Leven en laten leven
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Fri, 23 Feb 2018, Enrico Zini wrote: Hi Enrico, > > > Are there other ways in stretch of getting apache to authenticate > > > against gitlab? > > I would wait for the gsoc project. And on the alioth sprint, several people > > decided against using salsa as backend for sso, but the other way round. > > So please don't. > > Please do not switch Alioth off, nor disable creation of new accounts on > alioth, until then. Being able to get a SSO certificate as a non-DD is > currently a required step to become a DD. Please don't get me wrong, that decision was a team decision done at the spring (and I didn't even voted for it) - however I stand behind such team decisions and follow them like they are my own. I think I owe you some reasoning. It was decided that relying again on a service wouldn't be the best idea if the would have to move to some other solution - the whole fun would start again. We also took into account that the may be another implementation of a git service. We decided that the best solution would be another new, authorative backend for guest users and dms, that can work independently of the service. However, I hoped that someone else would take care about that new hypothetic service/backend. Appearently that wasn't the case, until yesterday noone expressed interest in *doing* the work. Therefore I decided that I should take care about it and started the gsoc project (I even applied as admin to ensure it will really happen). I also invited you to take part in the project - the response wasn't very enthusiastic. I do really hope that we can have a good backend for guestuser and dm authorisation and authentiction at the end of the summer. Something like ud-ldap that can serve us for the next years. I still hope that you will join us in that mission. Alex signature.asc Description: PGP signature
Bug#891361: ITP: golang-github-armon-go-socks5 -- SOCKS5 server in Golang
Package: wnpp Severity: wishlist Owner: Christopher Hoskin * Package name: golang-github-armon-go-socks5 Version : 0.0~git20160902.e753329-1 Upstream Author : Armon Dadgar * URL : https://github.com/armon/go-socks5 * License : Expat Programming Lang: Go Description : SOCKS5 server in Golang Provides the socks5 package that implements a SOCKS5 server (http://en.wikipedia.org/wiki/SOCKS). SOCKS (Secure Sockets) is used to route traffic between a client and server through an intermediate proxy layer. This can be used to bypass firewalls or NATs. Feature The package has the following features: * "No Auth" mode * User/Password authentication * Support for the CONNECT command * Rules to do granular filtering of commands * Custom DNS resolution * Unit tests The package lacks the following: * Support for the BIND command * Support for the ASSOCIATE command
Re: wiki.d.o returns "403 Forbidden"
On Fri, Feb 23, 2018 at 12:51 PM, Georg Faerber wrote: > ...at least for me. Please send your IP address to w...@debian.org. Probably the IP or network got banned for spam. > Could someone forward this to DSA? DSA is not the contact for the wiki. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Sun, Feb 25, 2018 at 2:46 AM, Alexander Wirt wrote: > I do really hope that we can have a good backend for guestuser and dm > authorisation and authentiction at the end of the summer. Something like > ud-ldap that can serve us for the next years. Will this mean that the guest users in db.d.o will move elsewhere? -- bye, pabs https://wiki.debian.org/PaulWise
Bug#891389: ITP: python3-defconqt -- A set of Qt objects for use in defcon applications
Package: wnpp Severity: wishlist Owner: Yao Wei (魏銘廷) Control: block 806464 by -1 * Package name: python3-defconqt Version : x.y.z Upstream Author : Name * URL : http://www.example.org/ * License : GPL-3 or LGPL-3 Programming Lang: Python3 Description : A set of Qt objects for use in defcon applications This is the dependency used by trufont (#806464) signature.asc Description: PGP signature
Bug#891390: ITP: ufo-extractor -- Tools for extracting data from font binaries into UFO objects.
Package: wnpp Severity: wishlist Owner: Yao Wei (魏銘廷) * Package name: ufo-extractor Version : 0.2.0 Upstream Author : Cosimo Lupo * URL : https://github.com/typesupply/extractor * License : Expat Programming Lang: Python Description : Tools for extracting data from font binaries into UFO objects. This is one of the dependencies of trufont signature.asc Description: PGP signature
Bug#891391: ITP: python-hsluv -- Python implementation of HSLuv (Human-friendly HSL)
Package: wnpp Severity: wishlist Owner: Yao Wei (魏銘廷) Control: block 806464 by -1 * Package name: python-hsluv Version : 4.0.2 Upstream Author : Alexei Boronine * URL : https://github.com/hsluv/hsluv-python * License : Expat Programming Lang: Python Description : Python implementation of HSLuv (Human-friendly HSL) This is the dependency of trufont signature.asc Description: PGP signature
Bug#806464: ITP: trufont -- cross-platform ufo3 font editor
Package: wnpp Followup-For: Bug #806464 Owner: Yao Wei (魏銘廷) Control: retitle -1 ITP: trufont -- cross-platform ufo3 font editor Some of the dependencies has been resolved (thanks to fontmake!) , so I am going to revisit this. Yao Wei signature.asc Description: PGP signature
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Sun, 25 Feb 2018, Paul Wise wrote: > On Sun, Feb 25, 2018 at 2:46 AM, Alexander Wirt wrote: > > > I do really hope that we can have a good backend for guestuser and dm > > authorisation and authentiction at the end of the summer. Something like > > ud-ldap that can serve us for the next years. > > Will this mean that the guest users in db.d.o will move elsewhere? For me guest user are the users named -guest. ud-ldap wise they are guest accounts in the ud-ldap. Therefore I don't think anything will change (unless DSA thinks it would be a good idea to use the new backend). Alex
