oauth2_proxy: 3.2.0 -> 5.1.0 - #79840
Conversation
133f408 to
6e48a34
Compare
6e48a34 to
ed35189
Compare
|
@GrahamcOfBorg build oauth2_proxy |
|
@ehmry @yorickvP could you please take a look |
ed35189 to
d268d4f
Compare
|
@GrahamcOfBorg build oauth2_proxy |
d268d4f to
c965ff4
Compare
c965ff4 to
cc57c95
Compare
|
@GrahamcOfBorg build oauth2_proxy |
|
Waiting for #83689 to land on master, as it contains a fix for go 1.14 on older kernels (which are the ones used by grahamcofbog builders). |
cc57c95 to
6b19b4c
Compare
|
Looks good to me, please add yourself as maintainer. |
v3.2.0 is 11 months old. v5.1.0 brings new providers and fixes security vulnerabilities. In addition, the project switched to go 1.14 and uses go modules, which is now reflected in the build process. NOTE: There are many breaking changes, which are then reflected in the NixOS services configuration.
d0b6f04 to
7321a24
Compare
Update to match the current flags and apply fixes to all breaking changes.
No NixOS tests yet, but this is better than nothing.
Per request from the current maintainer.
7321a24 to
d31bb1e
Compare
|
@yorickvP Please take another look. |
|
@GrahamcOfBorg build oauth2_proxy |
|
I think we should backport removing OAuth2-proxy completely from NixOS 20.03. Given that the version with the security fix is backwards-incompatible with the version we ship ( i'm kind of uncomfortable that we're shipping a NixOS module that sets people up for open redirect attacks GHSA-qqxw-m5fj-f7gv |
|
@arianvp should we then remove any software from NixOS that has a CVE? |
|
One that defeats the purpose of the package in the first place? yes. Open redirect bypasses the security measures that the package was supposed to fix in the first place. an authentication modules that allows attackers to steal your credentials is not very useful to ship. Im also ok with rewritng the NixOS module to support 5.0 but seems that is a big breaking change. (So is removing but it's less work). I don't know what is wisdom here |
|
I understand your sentiment. But all software has bugs, and we can either just accept there will be a breaking change, or drop it. The former can be handled nicely by documenting the change and the reason for introducing it in the first place (I suspect no one would be happy with running quite an old version of anything). The latter just opens a can of worms -- any CVE in majority of the tools is defeating the purpose of the tool. |
|
Ok so in that case should we create a backport PR for this? |
|
We should check if there's a CVE fix for 3.x versions, and backport this. If there's no such fix, we should just mark it as insecure in 20.03 and 19.09. This will wake people up using it, so they can work on a fix ;-) Edit: It might be just a matter of backporting oauth2-proxy/oauth2-proxy@a316f8a to our 3.2.0. |
|
|
||
| src = fetchFromGitHub { | ||
| repo = pname; | ||
| owner = "pusher"; |
There was a problem hiding this comment.
This has been redirected to oauth2-proxy/oauth2-proxy.
There was a problem hiding this comment.
Yes, it has been, but not official yet. I'd wait for them to make a release and then do the change. That is, Go code still uses pusher/oauth2-proxy, while only the repo is renamed.
|
There is no CVE fix for 3.x |
|
We can backport the fix, it's a single-line patch. |
Motivation for this change
oauth2_proxy is now at version 5.0.0, and it brings support for many new providers, as well as security fixes. This PR updates both the package as well as the NixOS module.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)