Proposal for Official Fork

[alexandre-leites]

Hi,

As everyone here can see, the project is almost abandoned.

I believe someone or preferable a group of people fluent in Go lang should create an 'official' fork of the project so the community can contribute with PRs which won't be waiting forever at "Pull Requests" tab.

I'm not fluent in Go but I can help with docker images or something like that if needed.

====== Edit =====

According to @russtacular comment on 29 Aug 2018 this project is oficially discontinued. Therefore, while the community is discussing where it will be 'oficially' forked and supported, there are several projects already taking place as a migration path:

https://github.com/pusher/oauth2_proxy (see https://github.com/bitly/oauth2_proxy/issues/628#issuecomment-453494239) https://github.com/buzzfeed/sso https://github.com/openshift/oauth-proxy https://github.com/ploxiln/oauth2_proxy (see https://github.com/bitly/oauth2_proxy/issues/628#issuecomment-449255369 and https://github.com/bitly/oauth2_proxy/issues/628#issuecomment-449544677)

Also, there is a discussion on gofrs https://github.com/gofrs/help-requests/issues/32#issue-388720547

[eforbus]

Agree. I think many of us would love to see some of these PRs get merged. Like it or not this is one of the simpler to use solutions for integration of OAuth2 or OIDC providers on top of Kubernetes.

[andreacassioli]

It is definitely a pity the project is kind of dead. Looks like a lot of people use it though. There is an interesting fork

https://github.com/openshift/oauth-proxy

but specialized on OpenShift.

If I were proficient in Go I would love to help.

Would be nice to know the maintainers opinion.

[ermik]

Let's find a well-known OSS org on github that could manage having such fork. Security repos shouldn't be on any one personal account. It is important though to have @bitly's support and perhaps have their team add the official fork's releases as a tag on dockerhub.

[alexandre-leites]

I agree with you @ermik. Finding an OSS organization which can take care of the project and assign people (not just one) which can approve PRs and manage the repository.

[bhack]

This is used quite often with K8S. /cc @cncf if it has any suggestion of what group could take care of this.

[bhack]

/cc @jbeda Do you know someone that could be interested to maintain this project active in a fork?

[tanuck]

Have @bitly stopped using this, hence the staleness of the project? If so it would be interesting to hear what they use instead.

[ermik]

Everyone at bitly might be just drones and we are a part of their simulation.

[skwashd]

I have been in touch with people at bitly about the current state of the project. I will post another update when I have more information.

[mohammed90]

If you're going for a hard fork, consider https://github.com/gofrs .

[ajcollett]

I too would like to use this! I recently started using the free Access service from CloudFlare. I really like the concept. So being able to do the same in a stable way with NGINX would be amazing...

[skwashd]

I have exchanged emails with the CEO of @bitly. I thought we were going to get this resolved. Unfortunately once it was passed over to an engineer it died.

I think it is pretty clear that this project is no longer a priority for bitly. For whatever reason they are unwilling to pass it over to new stewards.

I propose the following actions:

• identify a new home for the project
• mirror the repo in new org
• update the docs
• review all outstanding issues/PR and duplicate them in the new project. Add comments on the bitly version with a link to the new issue
• map out what a ???/oauth_proxy 1.0 (or 3.0) release would look like

[alexandre-leites]

@skwashd

That's sad to hear.

Have you guys heard of https://github.com/buzzfeed/sso ? It seems to be built on top of OAuth2 proxy with more features. I'll try it out soon...

[logicfox]

There are many large companies with significant OSS presence that have forked this project and have pending PRs awaiting merge. Can one of these companies please come forward to adopt this project?

There are many features that we require, which are stuck in unreviewed PRs. We are manually merging into our private forks, which is not sustainable!

[mgoldsborough]

I'm not fluent in Go so I've been working on a node.js port. Would others here be interested in this?

[ccojocar]

I will be interested to contributed to the maintenance of this project, since we built recently the https://github.com/jenkins-x/sso-operator on top of it and have a certain understanding of the code base.

I like what @skwashd is proposing. It seems that sso-proxy org is still available. Do you have any other suggestions? If you agree, we can move on with this org.

[ermik]

~Could we try reaching out to BuzzFeed for comment (pun intended)? Their sso product seems well-established and a merge path would be a better choice for this repo — and introducing more flexibility (more auth providers, better config, k8s-ready, etc.) to their project could be a symbiotic thing.~ **@ccojocar pointed out below that it's not a derivative._**

If there are not takers by Oct 1st — let me add to @skwashd's list — we need to identify a group of maintainers that can commit (ok, this pun is just unavoidable) to working on newly forked org/repo for the near future while we try to build a community around it.

In my opinion, here is a minimum of people required for this repo to continue being of the most wonderful tools out there:

• security expert with substantial credentials
• cloud-native expert to keep things in perspective
• networking specialist to push this to the cutting edge
• engineering manager to keep things going

feel free to adjust.

Please volunteer yourselves with a brief description of your specialty, and please start reaching out to people to see if we have the support we need.

[ermik]

cc/ @ohaiwalt — you pointed me to this repo and I'll never be more grateful; do you have any thoughts on the matter?

[ccojocar]

@ermik the buzfeed/sso does not seem to be depend on this proxy https://github.com/buzzfeed/sso/blob/master/Godeps. I am not sure, if it makes sense to couple the two projects.

This project has a well established user base in the Kubernetes community. It must continue to be maintained.

I would say, the simplest way to move forward, it is to create a new organisation with a group of maintainers, and then ask bitly to transfer the ownership of this repo to that organisation.

@skwashd Do you think, would this work onbitly side?

[tanuck]

If we can't get any response from bitly engineers then it may not be possible to move the repo.

[ccojocar]

Please could someone from bitly provide an official statement to this issue? I am mentioning all current members of bitly organisation. Sorry for noise!

@apriendeau @hlhendy @jctbitly @jehiah @kpurdon @lrmay @markrechler @mrwoof @russtacular @sioanis @tpherndon

[skwashd]

I tried a couple of times to reach the company via twitter. (first attempt and second attempt). The second one lead to a short email exchange with the CEO. It was passed onto @jehiah, who never responded.

Bitly don't owe us anything. They are free to throw their code over the wall and do nothing else. That's how open source works. That said, it is disappointing that they won't engage with the community that they built. Priorities change, life moves on, we accept that. It would have been nice if they either came out and said why the tumbleweed is blowing around the project or worked with interested members of the community to move it to a new home. Sadly there appears to be no interest in either option.

I would be happy to play a role in any fork, but I don't feel like I have the time nor the skills to provide the technical leadership. Without leadership we will remain an unruly mob moving pitch forks.

With all this in mind I created 2bitproxy/oauth2_proxy. I picked the name as it includes bit as a reference to the bitly heritage and a tongue in cheek reference the negative "two bit". (It takes under a minute to rename it with sed).

I believe the first 3 points from the plan I posted last week have been resolved. Who wants to help with the remaining 2?

[kpurdon]

Hi all ... I've reached out internally here at Bitly and will make sure we get a response here soon. Just wanted to drop a line here so you all know we are listening.

[ermik]

@skwashd It's great we have a home for the time being — thanks for stashing away a nice org name! I think you have it right: we can work on improving the project while this gets resolved. A certain breathing room needs to be maintained for @bitly and other community members, as well as possible maintainers, to chime in to this conversation.

@kpurdon Great news! I don't presume to speak for everyone, but I would say the key thing to resolve here is a managerial one. There is no need for a fork if and only if the team at @bitly is dedicated to working towards granting some community members merge permissions and working towards reinforcing the community support itself for this repository.

[russtacular]

Hello all,

Sorry it's taken so long to respond—it's often difficult to acknowledge that you can no longer maintain something that you've built and nurtured for so many years.

While this project has served us well internally for a while, we haven't been able to find someone on our team to push it forward and shepherd community contributions that weren't part of our roadmap. We've also since moved on to other priorities and are even investigating switching to buzzfeed/sso since it's a newer fork of oauth2_proxy.

As a result, we've decided to make this read-only and archive this project at the end of September. We're happy to update the readme to point people to newer, maintained forks, so please update this issue (or start a new one) with possible successors in order to make this transition as easy as possible.

[cilindrox]

Thanks for the update @russtacular

[martin-loetzsch]

bumb up

[ermik]

I'm calling for a goodbye party to be hosted at one of Flatiron bars. @russtacular

[martin-loetzsch]

bump

[ploxiln]

The openshift fork https://github.com/openshift/oauth-proxy has already been mentioned. I've started a humble and initially somewhat minimal fork myself, and I've made a release: https://github.com/ploxiln/oauth2_proxy/releases

[ploxiln]

So, @russtacular or @jehiah should push a small update to README.md soon, probably mentioning a couple forks (maybe @JoelSpeed is interested in maintaining an OpenID Connect focused one?)

[kfox1111]

Is this something that could be contributed to the CNCF? It seems like it would be well within scope for them, and would then limit the number of needlessly divergent forks?

[JoelSpeed]

Hi all, I've discussed this with the team @pusher today and we have decided that since we rely on this heavily and have a reasonable understanding of the code base, that we are going to clean up our fork and make it an "official" hard fork.

Personally we have a decent understanding of OIDC but have little experience of the other authentication providers, I'd like to try and find some people willing to help out with the other providers if anyone would like to volunteer?

In the mean time, I am going to update our fork's master to match the current master here and get the outstanding PRs that I own updated and merged, set up some CI and update the documentation on our fork as well as raising a PR to update the documentation here.

WRT the CNCF, I've reached out to @oicheryl for guidance on how and whether this might be suitable for adoption by the CNCF

[martin-loetzsch]

Thanks for doing this @JoelSpeed

[skwashd]

Thanks @JoelSpeed for stepping up.

Originally I thought that forking and maintaining this project would be possible. After a comprehensive review of the available options we decided to go with Cloudflare Access. We already run a bunch of stuff behind Cloudflare, so switching to Access made sense for us.

I hope to find other opportunities to use this proxy. If I do, I hope to contribute to @pusher's fork.

[oicheryl]

The process for joining the CNCF as a sandbox project is at https://github.com/cncf/toc/blob/master/process/sandbox.md. The main criteria is that two TOC members sponsor the project and it is presented at a TOC meeting (and subsequently approved).

However the majority of the TOC is up for re-election in January, so rather than gathering sponsors now I suggest waiting until after the new TOC members are elected. There is also a growing backlog of projects under review (https://github.com/cncf/toc/issues), so please be patient if it takes a while to schedule.

Having said all of that, I think forking oauth2_proxy and hosting the new project at the CNCF makes a lot of sense. Let me know if it's unclear or you have questions.

[marratj]

Personally we have a decent understanding of OIDC but have little experience of the other authentication providers, I'd like to try and find some people willing to help out with the other providers if anyone would like to volunteer?

@JoelSpeed

We have created a small fork ourselves to include support for Azure AD B2C, which is OIDC with an added policy parameter that needs to be passed to the auth endpoint. For this, we also forked the go-oidc package from CoreOS, on which the OIDC provider is reliant, to pass the parameter upstream.

However, if we get an official fork, we'd be happy to make a proper AAD B2C provider (in addition to the "standard" Azure AD, which works differently), maybe by taking the OIDC provider and the go-oidc package as template, "converting" it to a full provider in oauth2_proxy.

Thoughts on that?

[JoelSpeed]

Thanks @oicheryl for your input. Having discussed internally we are planning to continue our plan to adopt the repo and have started the migration process (please add comments if you think anything can be improved: https://github.com/pusher/oauth2_proxy/pull/7) from here.

We would then like to start the process for proposing the project to the CNCF when the time is right, perhaps February? This will need some help from the folks @bitly however since part of the process is signing over any trademarks. Hopefully if it gets accepted we should be able to merge any changes made to the @pusher fork in the mean-time into the CNCF homed repository.

@marratj Totally happy for that to happen, once the migration process is complete, if you have time, feel free to start working on a PR. I know that Google also use extra parameters in their implementation of OIDC and have seen this implemented without forking go-oidc so perhaps we can look at that together to work out how not to fork it. Perhaps you can inject it like the HD param is done here? https://github.com/JoelSpeed/dex/blob/ccd954582b85162882656d0842e89af58f87d356/connector/google/google.go#L120

[dt-rush]

Given this is the only repo that convincingly handles this pretty important use-case (reverse oauth2 proxy, using multiple handlers, very configurable), I would prefer personally to see this find a home which is not a specific company, something like CNCF or as someone else suggested, gofrs. But Pusher do seem to be actively maintaining their fork - I opened an issue which was responded to within hours.

[dt-rush]

@skwashd has created a "community fork" and Pusher (@JoelSpeed) has forked and are maintaining. This is a bit of an awkward situation. @skwashd would you consider trying to merge your changes via PR into Pusher's fork? Or should Pusher rather try to help land this in a more community-centric place and commit and maintain from there?

[kfox1111]

@dt-rush See @JoelSpeed's comment from above, that pusher is willing to help contribute it to the cncf, and cncf said it might be a bit slow to catch, so the febuary timeframe seems reasonable to me.

Is it acceptable to everyone to use pushers fork for a few months until all the details can be worked out?

[adamdecaf]

SGTM. Please ping on this issue as updates happen.

Gofrs would be another option and I can help get it moved over there.

[skwashd]

I am happy to transfer the organisation to someone he will run with the fork. As mentioned above we have decided to use an alternative product for our use cases. While I am interested in helping out it will all be in my limited spare time. My changes were a change I made to support github teams properly (PR #613) and some "rebranding".

My email address is on my profile. It's probably easier to discuss things there. If you're planning to pull an npm event-stream stunt, don't waste your time emailing me.

[adamdecaf]

I've created a Gofrs issue to adopt the project and I'll volunteer time to work and improve the project.

[adamdecaf]

Could we hand out github issue access to a few folks? There are lots of issues and PR's that could be closed.

Example: (Adding a Dockerfile): https://github.com/bitly/oauth2_proxy/pull/671, https://github.com/bitly/oauth2_proxy/pull/460, https://github.com/bitly/oauth2_proxy/pull/372, and https://github.com/bitly/oauth2_proxy/pull/86

[ermik]

@xalexslx Could you update the original issue above with the list of forks to give people a migration path whilst community decides the fate of this?

https://github.com/buzzfeed/sso https://github.com/openshift/oauth-proxy https://github.com/pusher/oauth2_proxy

Possibly going to be on gofrs https://github.com/gofrs/help-requests/issues/32

[alexandre-leites]

@ermik

Original issue updated with the links and official comment of russtacular regarding this project.

[ploxiln]

Just by the way, if anyone needs a recent release while waiting for the pusher fork to be ready, I've incorporated the fsnotify/hmacauth import fixes on top of latest master, merged 8 other PRs from this repo (incl. google/github/gitlab groups enhancements, redirect-domain-whitelist, other bits), and made a couple of releases with decent changelogs and binary builds at my fork: https://github.com/ploxiln/oauth2_proxy/releases

[danihodovic]

Thanks @ploxiln ! Could you push an image to Docker hub?

[ploxiln]

EDITED (I don't want to spam this issue too much)

Fixed link to my fork's docker image info: https://hub.docker.com/r/ploxiln/oauth2_proxy (it's also mentioned in the README at my fork)

Further discussion of my fork should probably go in issues at my fork. Also note that the "pusher" fork will probably soon be the central/community repo, particularly when it transitions to CNCF.