TooTallNate / superagent-proxy

`Request#proxy(uri)` superagent extension
154 stars 46 forks source link

Latest versions of proxy-agent upgraded because of vm2 vulnerability are incompatible here #48

Open JasonKleban opened 1 year ago

JasonKleban commented 1 year ago

superagent-proxy v3 cannot be used with proxy-agent v6 because of breaking changes in the exports, at least.

https://github.com/TooTallNate/superagent-proxy/blob/ce624a1d66c0ae5fc9cec1fc48904d3890bedc72/index.js#L6

https://github.com/TooTallNate/proxy-agents/tree/main/packages/proxy-agent

Perhaps that is what has been declared, but I'm not sure how to untangle this from the supposedly necessary proxy-agent upgrades for vm2.

Can there please be a v4 released that correctly imports proxyAgent v6?

lini commented 1 year ago

proxy-agent has now been updated to remove the vm2 dependency. Is a release of superagent-proxy planned to integrate this update?

pwilder-sig commented 1 year ago

@TooTallNate You seem to be listed as the only collaborator in the npm page so I'll direct this at you, any chance of a review of this PR or an independent update? I'm wondering if we should consider this library unsupported at this point.

I suspect I speak for others when we say that we appreciate your other work on the proxy-agent -> .. -> degenerator stack but other dependencies referencing this lib hit kind of a dead end (without more drastic measures like migrating off this lib entirely).

gterras commented 1 year ago

As a workaround you can use the overrides prop of package.json to force an updated version of proxy-agent, nesting your dependencies if needed, in my case :

    "overrides": {
        "@nestjs-modules/mailer": {
            "inline-css": {
                "remote-content": {
                    "superagent-proxy": {
                        "proxy-agent": "^6.3.0"
                    }
                }
            }
        }
    }, 

Seems to work fine for me. You may need to delete your package-lock.json.

pwilder-sig commented 1 year ago

Thanks @gterras but my experience has been that the overrides does not cascade. So if I create a library that points at superagent-proxy using overrides and someone uses my library they will still have the security issue (e.g. other lib -> my lib -> superagent-proxy === audit failure). Telling callers of my lib to apply overrides to their package is an unsatisfying solution.

The package.json docs are fairly vague on this point so it was discovered through trial and error.

gterras commented 1 year ago

Thanks @gterras but my experience has been that the overrides does not cascade. So if I create a library that points at superagent-proxy using overrides and someone uses my library they will still have the security issue (e.g. other lib -> my lib -> superagent-proxy === audit failure). Telling callers of my lib to apply overrides to their package is an unsatisfying solution.

Ha yes it might be more complex or even impossible regarding lib publishing.

robbkidd commented 1 year ago

People Who Know Things, I could use eyes and help on #50 where I think we can see the upgrade blockers more clearly now.

robbkidd commented 1 year ago

My experience with the overrides workaround:

✅ it will install the updated version for proxy-agents to node_modules ✅ it will silence the security audit warning 😭 it will break your intended use of .proxy(proxy_url) in your application

The superagent agent will not be configured to perform comms through a proxy.

mohitbaviskar1999 commented 1 year ago

Hi @TooTallNate, so will there be a newer version for this package or not ? Could you please clarify it ?