On Mon, Oct 08, 2012 at 08:42:22AM -0400, Derrick Brashear wrote: > On Mon, Oct 8, 2012 at 1:09 AM, Troy Benjegerdes <ho...@hozed.org> wrote: > > On Sun, Oct 07, 2012 at 06:43:10PM -0700, Gary Buhrmaster wrote: > >> On Sun, Oct 7, 2012 at 10:28 AM, Troy Benjegerdes <ho...@hozed.org> wrote: > >> .... > >> > My take on the political layer obstacles to cross-realm is to figure out > >> > a way to leverage DNSSEC in some way to facilitate no-administrator > >> > intervention cross realm key exchange. > >> > >> We all look forward to your RFC. > > > > Before I bother with an RFC that nobody other than me cares about, I'd > > like to see gerrit.openafs.org *use* the following RFCs, so that I can > > trivially log in when authenticated to my own local cell: > > > > > > http://tools.ietf.org/html/rfc4120 > > http://tools.ietf.org/html/rfc4178 > > http://tools.ietf.org/html/rfc4559 > > > > Set up a SPNEGO-authenticated OpenID provider. You don't need our help to do > it. > If you'd like to see it, you have all the power needed, today. I'd > venture it would be easier also > to make RT use it, once you have it, than doing something directly to > RT (and having > 2 different somethings to maintain)
You have a good point, OpenID appears to solve the same problem, since we could log into both Gerrit and RT with an OpenID provider. But it's not worth the hassle for me to set up an SPNEGO OpenID provider if I'm the only one who uses it. I have concerns with Google as my OpenID provider, but it's 'good enough'. Can you get the central.org administrators to install http://search.cpan.org/~abergman/RT-Authen-OpenID-0.01/lib/RT/Authen/OpenID.pm Is there a compelling reason to continue using RT? There seems to be a lot of work involved to make it usable to new developers. But Github and Bitbucket also provide one-stop, (relatively) easy to learn setup for source code repos, code review, wikis, and integrated issue tracking that actually understands the revision history in useful ways. I'd lose the whole integrated kerberos login bit, but at this point, that's a worthwhile tradeoff to use a system other (non-afs) developers already are familiar with and use. _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
